I’ve written about it below, but I’m a visual person so I’ve added a lot of captioned pictures if you want the gist, and the how-to “recipe” for doing this mindset-shift yourself is at the end.

"As-is"

Becoming Agile is an Agile Process

We can’t solve problems by using the same kind of thinking we used when we created them. –Einstein

A few months back I had a conversation with Esther Derby about an organization which we both knew was trying to adopt Agile.  The problem was that they were trying to adopt Agile in a deterministic way:

"To-Be"

1. Map the “as-is” process
2. Design the “to-be” process
3. Determine the steps necessary to go from “as-is” to “to-be”
4. Execute the steps and control for variation from the steps

Hmm.  Didn’t seem too Agile to me, and it didn’t to Esther, either.  I run into this problem with organizations quite often, and I’ve found that talking about it doesn’t cause the necessary mental shift. Rather than focus on always doing what can be done to get better (“Evolving”), people often get hung up on all the barriers to being perfect (“Solving”).

Learning: a Change of Behavior as a Result of Experience

I was asked to facilitate a day-long planning meeting for an Agile Leadership Group.  The team had identified many barriers to adopting Agile at their org, and the sheer number and scope of the barriers were starting to make some of the leadership team uneasy.  They didn’t have enough experience in working any way other than as described above, and the energy of Solving was high.

I’m a lazy sort, and I hope also a compassionate sort, so rather than debate with the team about their objections or tell them that their fears were silly I thought I’d help them gain some experience… and most importantly, the change of behavior that comes from processing that experience.

Here’s how the day went.

First I spent 5 minutes reviewing the problem of using deterministic methods to manage complex change:

How to go from "as-is" to "to-be?" It's tempting to treat the transformation as a project and manage it like you manage all your projects: plan well, then execute.

Then I spent another 5 showing how an adaptive transition to Agile might work.  The “Agile Working Group” (AWG) here is a Scrum team charged with iteratively evolving the current processes, people, procedures, and corporate policies from “Waterfall” to “Agile.”  This is the same as evolving a software product from “what it is now” to “what our stakeholders really want.”

Then the questions started coming. “But what if our tests aren’t automated? But what about managers who manage functional silos? But what if…?”  At this point we could have spent several hours in Q&A, and most of my answers would have been variants on “let’s look at your specific concern and determine how to make the situation better than it is now.”

Instead, it was time to give the leadership some experience in the difference between adaptive/agile work and predictive/deterministic work.  I had them break into several teams, handed out sheets of newsprint, and set them a problem.

Experience

The learning objectives here were for leadership to internalize and be able to apply:

• the value of evolved vs. designed solutions when dealing with a complex domain (one near the upper-right of the Stacey Diagram) such as process change
• the necessity of an extant process to improve upon
• the power of repeated implement-inspect-adapt cycles over plan-once-then-execute when adopting Agile

So we got right to it.  The teams got a “process” and “requirements” shown below:

"Process:" The teams had 3 rounds to "build a bridge." Each round included both development (building) and inspection/adaptation.

"Requirements:" The teams were asked to "maximize the 4 constraints."

Notice the “process:”  no roles, no boss, no Agile terms.  Just cycles of build-inspect-adapt.  No hard and fast requirements, just a vision for “a bridge that has qualities of load-bearing, length, height, and aesthetics.”

And vicious time-boxes, of course.  Right out of the gate, the teams went to town:

A different team starts on their product.

Team 1 starts on their outcome.

We saw all the hallmarks of Agile work:  good-enough design, simultaneous work, prototyping, learning by doing and experimentation, rich collaboration, the need for visibility, making the bridge itself part of the team, innovation and adaptation beyond mere requirements… by the wrap-up iteration the teams had created very impressive bridges:

A different team opted also built a sturdy, aesthetic bridge and overcame the "impediment" of "no more paper" by incorporating the cardboard backing into the structure.

One team made a suspension-type bridge, continuously tested its load with cell-phones, and incorporated elements from the environment.

The teams demonstrated their final outcomes to each other, shared a bit of their challenges and successes, and admired each others’ adaptability.  Then we sat down for the real mindset-shift.

Reflection (Debriefing)

I led the teams through a structured debriefing.  This is the part of experiential learning or “games” that is most often neglected, and as a result people have fun but they don’t make the necessary mental shift to enable different behavior.  With 3 teams, we handled each step first in small groups, and then each team shared their findings with the rest of the group before moving on to the next step.

The teams discussed each step in their groups, and then shared their findings with the other groups.

We started with Step 1, Feelings and Facts:  let people vent their feelings (e.g. “the time intervals made me panic!” and “this was fun but I’m not sure what it has to do with real life”) and review what observable facts happened in the exercise.  No interpretation yet — just facts like “we started with a sketch,” or “we all worked at the same time,” or “we didn’t notice the pylons were mismatched until we lined them up.”

Each team wrote their findings on a flip chart and then shared them with the rest of the group.

Step 2, Interpretation, allowed the teams to think about the implications of their work on the bridge.  Here we shifted from purely observable facts to insights and evaluations: “I noticed that even though we didn’t have a leader, we figured out what to do” and “its funny how those requirements were really open-ended and yet we hesitated about not getting them right.” Most interesting to me were “I think we did poorly because our bridge didn’t match our initial sketch” from one team and “our bridge is different than I imagined it, but it’s actually better” from another.

Each team wrote their findings on their flip chart page, posted it next to their “Feelings and Facts” page, and then shared highlights with the rest of the group.

In Step 3, Generalization of the experience to Agile concepts, I provided some key ideas I wanted leadership to consider — chosen especially for this organization and what they were trying to achieve — and asked them to find instances of how they showed up when the teams were building the bridge.  This did two things:

First, it helped fix the concepts in everyone’s minds with concrete examples, both as individuals and as a group.  Weeks later I heard one person from the group say to another “we don’t know what’s best yet — remember how our bridge design changed only after we created the first iteration of it?  We need to get SOMETHING running NOW.”

But more importantly, it helped make the concepts understandable via a concrete, emotional experience.

Debrief Step 3 - Generalization: "How did these concepts show up when you did the exercise?"

It would have been one thing to try to get concept #2 across by telling the team “inspecting and adapting on an actual product is better than over-refining a plan” and then tell some stories from my own experiences.  But by finding instances of this idea at play in their exercises, the teams were able to discover for themselves the truths they wrote on their flip charts.  Truths like “adapting our bridge was easy because we were only making small changes at a time;” and “being able to see each other work reduced communication overhead;” and “having both a mostly-built bridge and general goals actually gave us very clear direction — it was easy to see the next step forward.”

Once again I had the teams share highlights of their findings with the group, then we moved to the final step: applying these Agile concepts to their work of process change.

In Step 4, Application to real life, we tied the learnings from the experience and debrief thus far back to my initial 10-minute presentation about Continuous Improvement vs. needing to solve all barriers up front.  I asked everyone to consider what their principles from Step 3 meant to them for how they would evolve Agile at their organization.  Each team then picked their top 3 items and posted them on a common piece of paper (shown above).

Outcome: a Change of Behavior

The outcome of all this was that a leadership team which in the morning had been feeling paralyzed by all their perceived barriers to adopting Agile, had a shared understanding and motivation to move forward by lunchtime.  They spent the rest of the afternoon choosing their first pilot teams and projects, and identifying which barriers they were going to tackle first.

Wrap-up: The top actions from each of the 3 teams... based on experience.

They were able to do this because they learned a set of key Agile concepts directly relevant to their situation, rooted in a shared experience, which they themselves uncovered.

This whole process took about 2-1/2 hours with breaks:

• 10m – Agile adoption as an Agile process (whiteboard presentation)
• 40m – Agile experience: 10m for Objectives and instructions, 25m for Teams to build a product, 5m for Teams to show off product
• 60m – Structured debrief (~15m / step, with each step being done first at individual teams then whole group)

Debrief has 4 steps:

• Feelings/observable facts from the experience
• Implications of the observed facts
• Generalization of the experience to concepts
• Application of the concepts to real life

I was really pleased to have the opportunity to have this session with the leadership team.  They didn’t just demand that the “expert consultant” tell them what to do, they were willing to start off their Agile adoption by finding their own way with a little guidance. (That’s the difference between an organizational consultant and a organizational coach, by the way.)

So after a day, leadership was ready to rock and we all had a great time. How was YOUR last leadership kickoff about Agile adoption?

I’ve noticed a disturbing trend at a few different clients now as far as how UX folk and Agile folk get along.  It put me in mind of a song from Rodgers & Hammerstein’s Oklahoma, barely-recalled from my high-school musical days.  Let me explain by way of example:

Steve is a User Experience (UX) expert on an Agile/Scrum team working on the new HipStartup.com website.  He’s excited because he recently returned from an Agile conference and got a lot of great ideas from Jeff Patton’s session about User-Centered Design.  John is the Product Owner (PO) for the site and is juggling multiple voices and requests, but knows that each day without a new site feature delivered is another day that Venture Capital money is burned with no return on investment.  Geri is the ScrumMaster (SM) for the team and she wants everyone to follow the Scrum process because she knows it’s the best way to deliver value incrementally.

Three weeks ago at the meeting with the VC folks, John heard that they would really love to see HipStartup.com do single-sign-on integration with Facebook, Twitter, NetFlix, and the FAA.gov websites — with a unified look and feel.  This morning during the sprint planning meeting, developer Brian cautiously raises the issue of design: does Steve have any wireframes or web composites done for Brian to use in his estimation of story size?  Steve replies that he’s still testing the wireframes with their user focus group and wants to make sure the design for the new single-sign-on will work for them before he releases them to the rest of the team.

John explodes. “What? It’s been three weeks! You’re telling me we still don’t have a thing to demo yet?”  Steve looks helplessly at Geri — surely she will understand the need for a good design?  ”John has a point,” Geri says.  ”All this user testing you keep talking about smells a lot like Big Up-Front Effort to me.  Can’t you get some wires to Brian ASAP, even if its just for a few stories?”  Steve is appalled.  Wires for just a portion of the site, when the VC folks clearly wanted a unified look and feel?  ”Well, sure,” he huffs, “I can give you what I’ve got so far, and you can get right to work on it… if you don’t mind the users thinking it’s crap!“

Let us let the curtain of imagination close over this scene for now.

I’d like to say a word fer the farmer
He come out west and made a lot of changes –
That’s right! He come out west and built a lot of fences,
And built ‘em right across our cattle ranges!

Just like the farmer and the cowman, User Experience folk and Agilistas/ScrumMasters each provide value in ways that can inherently interfere with each other.  The UX person wants a good experience, and so needs to engage in some sort of holistic design.  This doesn’t have to mean Big Up-Front Effort, but it can look that way to the Agilista who has been fighting waterfall for much of her professional life.

They also each work in ways which tend to stir up the fears of the other.  The Agilista wants a continuous flow of bite-sized chunks of value, with frequent opportunities for inspection and adaptation.  This doesn’t have to mean a Frankenstein’s monster of cobbled-together parts, but to the UX person, even the possibility of creating such a monster is, pardon the phrase, horrifying.

I’d like to teach you all a little sayin’
And learn the words by heart the way you should
I don’t say I’m no better than anybody else,
But I’ll be damned if I ain’t jist as good!

So at the #womeninagile booth at Agile 2010, I had the great fortune to start a conversation with @carologic of Ask a User.  Carol is a UX expert and works through a variety of methods to incorporate actual user research and experience into the design of her client’s products.  While as an Agile coach and empiricism fanatic, I’m always espousing the “ready-fire-aim” and “fail fast” schools of adaptive outcome development.  Cage-match waiting to happen, right?

Wrong.  In 20 minutes of conversation at the booth, we were able to express our respective concerns with each others’ practices and how they are misapplied, and brainstorm at least three harmonious solutions integrating the best of Agile/Scrum and UX, in very specific ways.  Not to tease, but over the next few months, Carol and I will share those ideas with you in our respective blogs.  We will explore:

• why we shouldn’t call the end-of-iteration demonstration of incremental functionality a “demo”
• where to integrate user research into the Agile iteration cycle
• the use of Boundary Objects as discussed in Israel Gat’s Agile 2010 talk

and more.  How did we come to this resolution so quickly?  Simple:  we both approached each others’ domains from a perspective of curiosity and interest — rather than from one of defensiveness.

And when this territory is a state
An’ joins the Union jus’ like all the others
The farmer, and cowman and the merchant
Mus’ all behave theirselves and act like brothers!

I believe that diversity does not mean “tolerance of differences.”  Rather, diversity means “our differences make us collectively stronger.”  This isn’t compromise, this is learning from each other’s talents.  As Karl Weick said, ”fight as if you are right and listen as if you are wrong.”

Let’s us UX and Agilista people listen to one another.  We’re not truly in competition, we both want the same things.  We just have different ideas of how to go about it.  And it’s in the union of the two that true value will be created.

As Oklahoma‘s Aunt Eller says, “ain’t nobody gonna slug out anything – this here’s a party.“

(cue laugh track)

In all seriousness, it depends on what you mean by “work.”  I personally have very high standards for “working” Agile.  Agile isn’t a way of doing, it’s a way of being.  So do I believe Agile can work in the spirit of its greatest potential, as a means to enable the shift from an deterministic organization to a learning organization (a la Senge), in a culture of single point accountability?

Can a possum stop a car?

Accountability When Agile is a Process

Sure, Agile can work as a process for incrementally creating quality software product when we insist on maintaining single-point accountability, exactly as Rebecca successfully implemented in her project.  You can “wrap” the Delivery Team in Agile and use the Product Owner and ScrumMaster as the “interfaces” for the team.  You can even promote individual accountability in such a scenario:

• Product Owner (PO) — on the hook for the health of the (software) product
• Team Coach/ScrumMaster (SM) — on the hook for the health of the Team and their adoption/adaptation of the process
• Delivery Team — on the hook for demonstrating a working product increment at the end of each iteration

“Hey Derek, not too fast! That last one is team accountability!  So there isn’t individual accountability at the team level!”

Uh, no.  There certainly is.  In the context of the entire Agile Team (e.g. a Scrum Team consisting of a SM, PO, and Folks Who Make the Software Product Exist) the Delivery Team is accountable only so far as they collectively build working product.  Individually, however:

• Delivery Team Member — on the hook to the rest of their Team for whatever commitments they make each day at standup; for asking for help when needed; and for swarming and providing help as needed.

See ?  If we are talking about a culture of accountability, then accountability depends in what context you view it.  Each person both has individual accountability and also is part of a Team that has team accountability.  In the context of the Delivery Team, Brian the Developer is accountable for the tasks he signs up for and tells his team “by tomorrow I will complete…”  In the context of accountability to the rest of the organization, however, there is no individual accountability at the Team level lest we promote siloed work and blame-shifting and all the other joys of WaterGile.  But in the same context of the rest of the organization, Geri the PO is the single-point of accountability for the “health of the (software) product (that the team delivers every increment).”

But can Geri truly be single-point accountable for the R-O-I of the product?  Because she is also part of the larger team of Product Management, which is team-accountable for making that R-O-I manifest and be something the organization can use.  In the context of the total utility of the software product, one must also consider the teams of marketing, sales, support, training, etc. to extract and deliver full value on the potential of the software product.

So it’s both.  In a single-point accountability culture, the successful Agilist who wishes to use Agile as a process for creating potentially useful software products needs to promote team accountability and individual accountability as appropriate for the context.  Asking which is more important is like asking whether “3″ or “blind mice” is more important.

Lowest Common Denominator

Now, this will work for churning out product at a reasonable rate, and Fred Winslow Taylor and members of his Fan Club can clap and sing that Agile will work in a culture of single-point responsibility.  Assuming that your organization has little commitment to the change necessary to achieve the hyper-productivity promises of Agile, assuming you don’t mind flat or near-flat velocity gains, flat team morale, and assuming you are okay with the criminal waste of human potential of churning out product with no real Awesomeness in it — please, be my guest.  Don’t look back, some other companies might be gaining on you.

But if this doesn’t seem to align with your organization’s values, if you actually want people to work better together, to develop their full potential as a team, to realize the power of their diversity and make some truly creative and useful things… you may wish to be cautious with single-point accountability and Agile.

Because you’re robbing people of responsibility.

Responsibility — being a source or cause for results — depends on having the opportunity to be the source for those results.  When you make one person (e.g. the PO, or the SM) on the hook for delivery of the product, people who don’t have the ability to deliver that product, you steal that opportunity away from the Delivery Team.  And that’s the greatest paradox of how I so often see Agile being implemented.

Trying to realize these kinds of gains while preserving single-point accountability for delivery will be about as successful as the possum trying to stop the car.

No, I explained, I just noticed he was being visible and wanted to encourage him to keep it up.  ”Consider that email a round of applause,” I said.  Brian (another developer on the team) overheard this and then told us of his “Praises and Curses” email folder.

Pardon?

As it turns out, Brian collects emails from people when they thank him for doing a good job, or when they are upset and wish he had done something differently.

But he doesn’t just collect them — he reviews them.  At least once a year prior to performance reviews.  And sometimes more frequently.

Now, just to put this in context, Brian also uses the Pomodoro Technique in his daily work.  So what we have here is an individual — a so-called “technical” person, no less – who:

1. works in discrete intervals, identifying interruptions and tracking velocity
2. inspects the feedback received as a result of his work

I gaped.  What an incredibly good idea: building in the means for self-improvement that just sort of “happens.”  No need to depend on the performance review as the only means of formal retrospection, simply collect the information as it comes in, and review at your leisure.

How many of us set up these kinds of mechanisms in our lives — feedback mechanisms which help provide awareness?  What would life be like if more of us did this?

I have a bubbling head full of ideas to share there, and as a collaboration junkie, I’m making them visible for comment.  Suggestions? Criticisms?  Want to join me in Phoenix and collaborate?  Leave a comment!

Topic 1 — Science: A Framework to Aid Scientific Research Teams

Scrum is, at its heart, a simple empirical framework for learning and discovery.  Often it’s used to “discover” the unbuilt-but-needed features of a software product, and so people confuse it with a product development methodology.  But it’s more than that — Scrum is also useful for process improvement or organizational change.  Scrum is even self-modifying: it can be used to “discover” the best way to shape the framework itself to help make the team using it more effective.

When you generalize Scrum this way, it seems pretty obvious to try to apply it to how teams “do science”:

• backlogs as analogs of hypotheses
• swarming as part of research
• team-synchronization via standups and lo-fi tools rather than long publishing processes
• scrum of scrums to synchronize multiple teams
• demos and retrospectives as analogs of findings and conclusions

These are fairly naive mappings; I hope to make richer ones in Phoenix.

Topic 2 — Healthcare: A Framework for Training Medical Teams

I first mentioned this in a Twitter post inspired by discussion at the 2010 Conference of the International Association of Medical Education.

It seems to me that much of the thought in medical education views education as a rather linear, deterministic process, using what Bob Marshall calls “analytical models,” as contrasted to empirical, stochastic or even chaordic models.  Example:  a “learning process” depends on:

• a set of initial “learning outcomes”
• guided “deliberate practice” where students work either on medical tasks, or simulated scenarios (as a team, no less!)
• “reflective learning” where students debrief and self-assess.

To a Scrummer like me, this just screams “backlog, whole-team execution/delivery, retrospection, REPEAT” and also embracing student/team learning as a chaordic rather than deterministic process.  Unfortunately I see some of the literature and discussion in the medical education world take a rather “one-shot” approach to training:  Students come in, execute, and now they are “trained.”

Some topics and questions I’d like to raise in Phoenix:

• How might we frame learning in the context of Scrum?  By individual lesson (sprint), and as an entire curriculum (release)?
• Comments from people in the medical training/simulation field? How have you used something similar to Scrum?
• What are the problems with taking an approach driven by feedback loops rather than a stepwise process?

Topic 3 — Healthcare: Patient-Centered Treatment

Inspired by Compassion as a Golden Rule for Healthcare and Real Participatory Healthcare Starts With Assigning the Patient to Your Team (same author)

I need to give more thought on this — or ideally jam with another collaboration junkie — but the nebulous ideas here are:

• Linda Rising’s talk at Agile 2009 about how people who solve problems together, despite their backgrounds or knowledge, feel more empathy and understanding for each other
• How this effect brings diverse skillsets on an expert team together, despite egos and fears, and makes the team more effective at problem-solving
• Mapping the patient, and patient’s family into the role of “user”; mapping the medical staff into the role of “team”, and then:
• Using the Scrum framework as a structure in which to allow these roles to interact.
• How this is very different from the standard model of “lead physician interacts with patient/family, and specialists mostly  interact with lead physician”
• Who should be the ScrumMaster and Product Owner?

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.”

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.”

You have a nice four-hour block for your working requirements / product planning / process re-engineering / whatever meeting. You allot a “generous” 30-minute chunk near the beginning for the definition of terms. You put a few domain-specific words up on a flipchart to get ideas flowing, point to the first term, and prompt the team:

“So, everybody, what is the definition of _______ ?”

(Two hours later…)

One phrase is detailed to a precision that would satisfy most German engineers, the total number of terms to define has tripled — but none of them have been defined — and you have had to break up three near fist-fights.

A common vocabulary is important, but does it have to be this hard? I recently had a delightful experience which suggests that it does not.

If the team goal is a body of work which must be as clear and precise as possible, then perhaps you have some collaborative writing ahead… it’s time to scrap the original agenda and buckle down to it.

However, if all you are trying to do is “get all on the same page” — ack, sorry about that, I mean “develop a common vocabulary such that each word or phrase maps to the same concepts for each member of the team,” then you might benefit from what I’m calling the Affinity Definition Game. To play:

First, generate your list of terms in the usual groupthink team way (seed list, brainstorming, group writing, etc.)

Second, have the “is the pope a bachelor” discussion:

1. Ask, “is the pope a bachelor?”
2. For people who say he isn’t, ask what they think a bachelor is.
3. You’ll probably get some concepts like “single, bar-hopping, swank apartment, expensive stereo equipment, sports car,” etc.
4. Point out the concept of affinity: a young single man with a sports car has more “bachelor-ness” than an older unmarried man, who has more bachelorness than the pope.

Third, give out the instructions for the game:

1. The team is looking for nearby concepts. These are concepts with strong affinity to the term in the way that “swank apartment” has strong affinity to “bachelor.”
2. The nearby concepts should not contain any words which appear in the term itself. Synonyms should probably be avoided. Think of the board game Tabooâ„¢.
3. No wordsmithing.
4. Don’t get sidetracked by the words in the term, focus on the associations. Remember the “is the pope a bachelor?” discussion.

Game on! Collect concepts with strong affinity to the term in the participants’ minds:

1. Ask “what do you most strongly associate with ____?” Write down key adjectives or descriptive phrases from the responses.
2. Filter or correct the suggestion only if words in the term (or synonyms) are appearing.
3. Highlight any associations with especially strong emotional agreement; shouts of “oh yeah!” or loud groans could both mean that something has really hit the mark.
4. When the flow of associated words/phrases seems to be winding down, move on. Be patient, but don’t try to pump the well dry. If a strong association pops up later, you can record it later.
5. Did I mention no wordsmithing?

When you are done, you will not have a list of terms and their definitions. You will have a list of terms and the nearby concepts which the group most strongly associates with the terms. To abuse the Tao Te Ching a bit, the term will be “defined” by the nearby concepts just as a wheel’s hub is defined at the point where a spokes meet.

How is this useful? If, for “engineering design review” the team generated

• validation
• technical details, blueprints
• mindless tedium
• approval of plans (group decided it was a synonym)
• correction
• stamp-of-approval document

then what you have is a set of qualities which can be used to test the “engineering design review-ness” of something. You also have a shared understanding of an engineering design review, even if the term has not been detailed to a dictionary-like level of precision.

If you can get the team to generate an entire vocabulary with that level of shared understanding in less time than it takes to create full definitions for three words, then you have that much more time to get on with accomplishing your goal together.

And that’s what it’s all about.

• the spontaneous co-invention by Brian Marick, Jason Huggins, and myself of “the affinity definition game” as an alternative way to capture team vocabulary
• the lunch-table conversation about dev team members, Maslow’s Hierarchy, and the dangers of labelling non-conformist developers as “cowboys”
• Jeffery Fredrick’s talk about training and education in agile methods, and the dissatisfaction expressed both by recent university graduates and by hiring managers at the poor emphasis on agile techniques in the academic world
• the whole OpenSpaces format, and how asking a question could turn into the opportunity for a talk of my own

The one thing about the conference that really stood out for me, though, was the amount of — well, not exactly surprise at — but interest in the social aspect of software teams. Or, as expressed by one participant at the final wrap-up session: “I never realized how much psychology is involved in making software.”

I was both dismayed and gratified to hear this. Dismayed because as we like to say at 3Back, “software is product and product is produced by people,” so it makes sense to us that hardest remaining problems in software are about people.

But such talk was pretty New-Agey less than five years ago, so I’m gratified to see these topics getting more attention these days.

“a leader has to have the courage to say ‘this far, no further’ and be willing to act when the cause is just and it is the right thing to do.”

Well, of course a leader has to have courage, of course a leader has to be willing to act. We can take that as a given. I think the point that’s missing here is the distinction between two meanings of “leader.” It’s an important distinction and the second meaning is usually forgotten.

In one sense (and the most popular sense) the “leader” is at best:

• the person “at the front,”
• the role who takes action,
• the one who takes the ideas of the group and makes them happen.

At its worst, this kind of leadership is:

• the person “on top,”
• the role in control,
• the one who decides what to do and then does it (or tells everyone what to do)

In another sense (and the meaning that many miss) a “leader” is, at their best:

• the coordinator, the one who brings dissenting voices together fairly,
• the one who enables the group to achieve their own goals through their own efforts,
• the one who brings the people together and makes them far stronger than any individual could ever be.

…and at their worst:

• the bureaucrat,
• the endless debater,
• the do-nothing.

If you focus only on the worst ways that people can exercise these two types of leadership, you’ll hear a lot of what the two factions are shouting at each other. Those who are afraid of a domineering dictator will talk about “fairness” and “not limiting options.” Those who don’t want a do-nothing bureaucrat will talk about “action” and “courage to make tough choices.”Many people forget about these two meanings of “leadership” and focus only on the first meaning, the Person In Charge. If he’s a good leader, he’ll be at the front of the action, he’ll make things happen, he’ll take our ideas and see them through. And why not think this way? We have our lives to live, our jobs to do, we’re busy… we want the Guy In Charge to take care of it so we don’t have to worry about it. That’s why he’s the leader and we’re not, right?

Here’s the problem: a leader cannot do it all on their own. The quarterback cannot win the big game without his teammates. The CEO can’t produce her company’s widgets without the folks on the factory floor. The General cannot fight the war without the troops.

The “Guy In Charge” is an illusion.

There cannot really be a Guy in Charge unless everyone under him gives up their own free will. Unless the rest of the football team blindly does whatever the quarterback says. Unless the workers decide they don’t care about their home lives and work whenever the CEO tells them to. Unless the platoons stop reporting enemy positions and go wherever the General tells them, even if it’s to attack a lump of rock. Unless the Guy In Charge is in charge of a bunch of puppets.

We want to believe in the Guy In Charge because we don’t take responsibility for the results ourselves. We don’t want to be responsible if we lose the big game, don’t sell enough widgets, don’t win the battle. Let the Guy In Charge be responsible for that!

And that brings us to the second meaning of leadership — the person who brings the group together, who overcomes that fear of responsibility. Who gets the rest of the football team to work together. Who gives her employees what they need in order to do their best work in the factory. Who coordinates all the intel and recon reports from the troops, and ensures that they can all cover each other.

The first kind of leader wants to limit options, in order to achieve more control, because they think that will enable them to “get the job done” all by themselves.
The second kind of leader wants to find more options, in order to make their group as effective as possible, because the leader realizes that they could never have enough control to be able “get the job done” by themselves.

I’ve played on teams with a star player who did all the work. Sometimes we won a game or two when our star player carried the game. And I’ve played on teams where our leader worked for us. When our leader gave us what we needed in order to be an effective team. We won a lot — and we were proud of ourselves.

Which kind of leader do you want?