• Who:         Panel Discussion
• What:        “Will Any Letters Get Me The Job?”
• When:       Thursday, April 22, 2010 at 6 PM CST
• Where:      Omicron-USA, 8725 W. Higgins, Suite 450   Chicago, IL (near O’Hare) (map)

Featured Topic:

What is true certification?  *  The difference between certifications and certificates  *  How does the IT world perceive certification?  *  What certifications you should be pursuing  *  How experience comes into play  *  Can you advance your career without certification acceptance from your peers?

Lead-in Activity:

As always, the first half-hour of the event is reserved for networking and food. Pizza and pop will be provided, so come hungry, grab a couple slices of pizza, and get to know the other attendees who are making Agile Leadership happen in Chicago.

Follow-Up Activity:

Following the talk, attendees will take part in an OpenSpace discussion forum. An OpenSpace session is a high-energy experience: if you’ve never participated, be prepared to be surprised! For more about Open Space, see the original definition at AgileOpen.net. At least one topic will focus on the theme, but attendees are free to propose any topic for discussion. We always post the results of OpenSpace sessions.

Event Registration:

Please register at www.aplnchicago.org for this event, and to receive email updates and more details about this and other events as they become available.

I didn’t want to just post my fond memories — if you didn’t go to the beach, do you want to look at someone else’s vacation photos?  What I want to do here is  to dump my experiences into your brain. I recognize that you aren’t me, so if you had been there you would have had a different experience than I did.

But if you were me (or are someone who shares certain similarities with me) and you simply didn’t get to attend, here’s a brain dump for you (the session or person I learned each item from are listed at the bottom):

Self-Organization:

1. B = f(P,E) Behavior is a function of the Person and their Environment; you can change behavior by changing their environment – CSelf
2. We often mis-label things as self-organization. An example is self-assembly, such as how people board an elevator. True self-organization has a nontrivial definition, and is worth learning and remembering. – CSelf
3. The “best friend, worst enemy” game, and how working to protect yourself results in team fragmentation (posted previously) – CSelf
4. People are self-organizing systems. Naturally. As a species, we have over 13 billion years of experience with this, and only recently have we tried to manage people as things. — HOwen
5. The “inventor” of OpenSpace Technology synthesized the genesis of OpenSpace after having a martini. He leaped into brilliance and realized that it would only work if there were minimal rules after his second martini. We underestimate the negative impact our everyday rational minds have on our ability to innovate — HOwen
6. Many of the major catastrophes we’ve created come as result of trying to organize self-organizing systems — HOwen

Leadership:

1. People’s emotional response to a situation depends on how much it challenges them, and also how much ability they have to handle it. You can change their response by changing either of these. – CSelf
2. Three words you need to remember to help grow self-organizing teams: “LEAVE THEM ALONE” – CSelf
3. Powerful questions are those which invite a transformative experience in the person being asked. They tend to be context-free, and totally open-ended — CCoach
4. There are still plenty of “leaders” who blatantly destroy the elements critical to good teams (by moving members around between teams, for example) and yet are okay with paying to send someone to ScrumGathering. — Recep
5. Team performance, production velocity, process effectiveness, and personal feelings can all spiral upward or downward. This fits in with my model of positive and negative feedback loops, and has been proven in empirical studies. Yet many people reject the concepts as “fluffy.” — Positive

Coaching and Training :

1. A great way to ask for silence in a class is to have an agreement where, when you hold up your hand, everyone else goes silent and holds theirs up too. The class self-assembles into silence because they receive the visible signal from everyone else. — CCoach
2. Being an independent coach/consultant can be isolating, but there are ways to keep in touch with the community. I hope to join in with growing this community — Recep, GK
3. “Super Pecha Kucha” (a slide every 5 seconds) seems to be the up-and-coming presentation trick. Jurgen Appelo’s audience exploded when he finished his presentation like this. — DoltGuide
4. Scrum people can be nakedly honest, and yet completely kind about it. I watched an interaction between Joseph Pelrine and Jurgen Appelo that was so gratifying it caused me to laugh in delight. — DoltGuide
5. Pecha Kucha is completely doable with two people. — OurTalk
6. Given enough practice, explicit signals between co-presenters are unneccessary. Don’t plan, iterate, even in your interactions. This takes the the meta-level conversations (e.g. “your turn”) and “bakes them in” to the presentation itself. — OurTalk
7. If you are doing a dense PechaKucha talk, consider either paring it down still more, or warning people how dense it will be. — OurTalk
8. Be prepared to see your own images turn up in other peoples’ presentations. Work hard to ensure that someone else’s don’t turn up in yours. Give credit where credit is due. Fix the problem when it is discovered (Jean, your image is now attributed correctly :) — convo, JT

Relating to People:

1. Social media can be used bi-directionally, to truly connect people. Social media can be used unidirectionally for selfish reasons. I prefer the former. – Convo, SB
2. As @ccarfi says, people can engage in “hunting” (one-off transactions) or “gardening” (long-term relationships). Watching Twitter posts clearly showed who was doing what at #sgus — Twitter
3. Coaches and trainers can be one-sided in their conversation; talking but not really listening. Does this come as a result of being the “center of attention” in class all the time? Or are people like this attracted to training? Either way, I resolve to pay real attention and listen more. — convo, SB
4. ScrumGathering this year seemed so much more focused on people, collaboration, and teams; less focused on process and mechanics. This was in large part due to my choices of interaction, but also on the overall content. I am grateful to the conference organizers. — convo, SB
5. Conference energy can be addictive. Receiving attention, engaging in interactions, discovering new things. Leaving is actually like a physical and emotional crash. It reminds me of closing night with a theatre troupe. I was not the only person to have this reaction. — Twitter
6. Being positive is not an attitude, it is a practice. — Positive

Meta:

1. I was recognized publicly for my assistance to Luke Hohmann in helping the ScrumAlliance set new direction for 2010. Gratitude, humility, joy. — Convo, LH
2. The “Castillo Fort” room at the Gaylord Palms is a gorgeous place considering it’s entirely man-made. Like an open-air cave. — Recep
3. You can get a cool thing that fits around the iPhone to turn it into a near-professional camcorder — Recep, GK
4. The Twitter fountain was extremely cool. Google it. It was a large screen showing a constant feed of attendee posts over an ever-changing background of pictures posted — Twitter

The Sessions and Conversations:

• CSelfOrg — Joseph Pelrine, Coaching Self-Organizing Teams
• CCoach — Lyssa Adkins, Coaching the Coaches
• Recep — reception
• DoltGuide — Jurgen Appelo, “The Dolt’s Guide to Self-Organization”
• OurTalk — myself and Scott Barnes, “What Is Scrum? Changing How You Think About What You Do”
• HOwen — lunch keynote, “All Systems Are Self-Organizing” with Harrison Owen, known as the inventor of Open Space Technology
• Positive — Lyssa Adkins, “Positive Psychology and Team Performance”
• Twitter — staying involved “remotely” via the #SGUS Twitter stream, after I had left the conference
• Convo — misc conversation. If initials are given, the conversation involved:
  • SB – Scott Barnes, @cryofx
  • LA – Lyssa Adkins, @lyssaadkins
  • GK – Gerry Kirk, @gerrykirk
  • JT – Jean Tabeka, @jeantabeka
  • LH – Luke Hohmann of InnovationGames

Exercise at ScrumGathering 2010: how simple internal models (”rules”) can have very different effects on team behavior.

In the first situation, each person has to use their “best friend” to protect themselves from their own “worst enemy.” (In this case, you “protect” yourself by moving so that your “friend” is between you and your “enemy.”)

Notice how the group fragments and disperses.

In the second situation, there’s one little change: each person has to protect their “friend” from their “enemy.”

Bit of a difference! The overall behavior is toward cohesion.

P.S. “Kids, don’t try this at home!” This exercise works because the participants agree to the rules. It does NOT imply that you can simply give people rules to follow and expect to get the desired behavior. Why not? Because people aren’t machines, that’s why not! :) The art of the team is, of course, in coaching and coaxing the teams such that the individuals experience a shift in their own “internal rules.”

But the discussion in the comments is just one variant of the many similar conversations I’ve heard about Scrum.  It goes something like this:

• Neo: “Scrum is great, but we have to adapt it to fit our organization.”
• Morpheus: “You must not adapt the Scrum framework.”
• Neo: “Whoa.  Now you’re getting all religious on me.”

The whole point of “getting religious” about the Scrum framework is to detect when you are, ah, let me find the right extension to the metaphor here, drugging the mother-in-law rather than dealing with what she exposes.

If we can prematurely adapt Scrum to our situation, we have the freedom to adapt it such that we are comfortable within our dysfunction, rather than improving our dysfunction.*

Ken harps on 2 things to keep us from this pitfall:

1. keep Scrum simple – 3 roles, 3 artifacts, 3 meetings, associated rules for each; and
2. don’t adapt the Scrum framework (although adapting the process which you evolve around the framework is not only allowed, it is a must!)

By keeping Scrum simple, we reduce the temptation to tinker with it, and we reduce the amount we have to “interpret” it.  By keeping the framework constant, it gives us the same benefit as keeping rulers constant:  we get to adapt our behavior to improve rather than adapting the thing which exposes our behavior.  It would be some odd clothing made by a tailor who adjusted his measuring tape just to make me feel better about my 44″ waist.

But excuse me, I must be getting religious. :)

A frequently-underestimated benefit of the team “war room” is how it enables emergent knowledge. If I mumble to myself (as I frequently do) “now why is Apache redirecting us there…?” someone is likely to mumble back “checked the root htaccess lately?” and perhaps my problem is solved. Great fun. Great help. But hard to achieve on a distributed/virtual team.

I’ve enabled this sort of behavior in virtual teams via wiki, and also via Twitter (thanks to Chris Spagnuolo for the idea). But Twitter doesn’t have the concept of a “room,” so setting one up for everyone on your team — and keeping it private — is a bit of a pain. And Twitter’s one-username-per-email means some annoying collisions.

Campfire and IRC also have their uses, but cost and security respectively might be a blocker for you. Skype’s “conference” is nice, with the added benefit that you can start a voice call/conference whenever you want. But everyone’s updates live in the Skype app, not on a web page. So if someone new joins the team, they don’t get benefit of reading the team’s history.

I think Prologue is just what I’ve been looking for:

• installable on your own server
• your updates to your team are saved on a web page (you could even incorporate the RSS into your team wiki somewhere)
• flexible permission controls
• familiar blogging-style interface

Check out the live demo or have a download.

It’s a bit long at 9 minutes, but you’ll get the gist if you skim a bit.

Now, is this just a technology demonstration, or it this really coming to a hotel near you? This concept was part of the 2007 Philips “Sense and Simplicity” concept demonstrations, so it may not actually manifest. It all depends on demand, of course.

What it interesting about this is what we can infer from the intent of the concept: the value of design and human interaction in the technological product market.

20 years ago, “design” and “technology” went together like “polka” and “music.” But product managers (product owners) of tomorrow must incorporate design and human interaction into their plans (backlogs), or risk this sort of market response.

Strange, Charm, Truth, Beauty, and your old favorites Up and Down, now in Fat-Free versions.

Over the past few weeks, I’ve been digging into links, blogs, forums using this term (Post-Agile)… Have you seen this term? Followed it’s discussions? Any comments?

…Pliant Software is another term that seems to be associating itself with Post-Agile…

I think the software world is sort of like a customer who has an idea of what they want or need, but can’t put it into words. But, and after several iterations of “Requirements Gathering”, has come out of the room with more terms and an RD that is better than it was at the start — but not perfect, yet!

(italics mine)

Yes, I have comments!

1. I agree that the newness of agile has worn off, and the immediate benefits from it have been tapped dry by many.
2. I’m annoyed at the PliantAlliance site’s claim for “a new way of thinking about developing software” — pliant sounds like adaptive to me, and Scrum has been saying this for a while.
3. While the immediate benefits of agile have been tapped, the deeper benefits that can be realized by changing the way we collaboratively build product — not just the way developers write code — have a long way to go. Before we decide that “agile didn’t work,” I’d like to see more organizations actually practicing basic agile behaviour, and I’d like to see actual practices in use catch up to the huge body of literature describing deeper agile practices.

Good Software is a craft, like smithing or theatre. There was never a school that turned out expert blacksmiths; novices had to progress from apprentice to journeyman to master. The “Fame” school doesn’t promise its graduates fame, they have to go out and earn it through experience.

Good Software is the result of human thought — not just human labor — and is highly resistant to being made into a detailed process/algorithm, or body of knowledge.

Good Software is the result of collaboration. Social Science and more enlightened ways of interacting can help, but trying to describe them is missing the point.

I understand that post-Agilists see themselves as giving a name to an existing movement, rather than trying to create a new movement. But it smacks of picking a new name for your club because one member of your club is acting silly, and people are now making fun of you: you fragment the group, you tacitly approve of the bad behavior by distancing yourself from it rather than correcting it, and you spend too much time and energy on labels rather than action.

My friend’s point is right on: the SD world is like a user with a poor Requirements Doc, who “knows what they want, they just can’t describe it yet.” Trying to describe it, trying to codify it, is ulitimately a losing game and a waste of time — just like writing big RDs is a waste of time.

Build successful, adaptive teams who can make good, useful software, point to them and say “THAT is what Agile is.”

I’ve been writing quite a lot already, what with obituaries and funeral programs, so for now I’ll let the feature article in our local paper do the talking for me:

Local historian, intellectual Wyn Wade dies at age 62
(South Bend Tribune)