Agile2010 part 6: Bloody Stupid Johnson
Topic: General

One of the highlights of the conference was the session presented by Arlo Belshee and James Shore, "Bloody Stupid Johnson Teaches Agile." The presenters acted out a play they had written that poked fun at every agile stereotype you've probably heard of. By popular demand they repeated it later in the week. It was recorded and I hope to see it appear online soon.

Using a variety of hats and props, Arlo and James played the roles of several stereotyped characters from the agile world that were easy to recognize: The Consultant, The Salesman, The Bishop, The Champion, The Wizard, The Jester. Their goal: To craft the Perfect Agile Process (PAP).

In a hilarious and beautifully performed play, they called out many commonly-heard criticisms (both valid and otherwise) about agile itself and about those who promote it. I can't even begin to list the jabs at agile thought-leaders and well-known speakers and writers in the community, including the presenters themselves.

We in the audience were advised to call out "PAP! PAP! PAP! PAP!" whenever we heard pap from the stage. To help us understand all about agile, we were given Instructions (cans of Bud Light). The Instructions were warm, but much appreciated.

There were some very useful audience participation activities, too. In one, the group was divided into two teams. The Waterfall team received a set of instructions, and the Agile team received a different set. The Waterfall team was assigned to tear paper into as many small pieces as they possibly could in the time allotted. Meanwhile, the Agile team was assigned to fold as many paper airplanes as possible in the same amount of time. Then, the two teams threw their results at one another. The team whose products flew better was the winner. Agile was clearly more effective than Waterfall.

In another exercise, the two teams are lined up in single-file along opposing walls. The Waterfall team has to organize into functional silos and take a set of instructions through a series of handoffs with quality gates. The Agile team has to repeat the phrase "Yay Agile!" to one another down the line. By the end of the time period, the Agile team has delivered its message to the facilitators, while the Waterfall team is still in the Design Phase. Agile wins again! And it's scientific-like, too.

According to the session proposal, the presenters' goals were to highlight mistakes we often make in implementing agile methods:

• Giving in instead of removing impediments
• Focusing on planning practices to the exclusion of delivery practices
• "One True Way"ism
• Ignoring high-bandwidth communication
• Leaving out the customer
• Not integrating testers
• Process navel gazing
• Directive leadership

I would say they achieved those goals.

 

After the play, they iterated through the characters and polled the audience, asking how many of us had seen the character in our work, and then how many of us had been the character in our work. Then they led a discussion of which characteristics of each character we would want to keep, and which we would want to eliminate. For example, The Bishop keeps us on track by reminding us of fundamentals, but can be dogmatic and lose sight of practical matters. The Wizard answers every question by saying, "It depends." When asked On what? he replies, "It depends on the context." And that's all anyone can get out of him. On the plus side: He recognizes that we can't just drop a cookie-cutter agile process on top of every situation. On the minus side: He can't bring himself to take any action; he's stuck in analysis paralysis. There is a similar dichotomy in each stereotyped character.

One of the best things about the session was that The Salesman teamed up with Bloody Stupid Johnson to create an official certification program. We received printed certificates attesting to our status as Agile Software Specialists. I'm going to frame mine.

Agile 2010 part 5: Writing code, refactoring, and debugging legacy code
Topic: General

For fun and relaxation, I attended a few sessions devoted to hands-on programming...or at least sessions that sounded as if they would involve hands-on programming.

Pairing games as intentional practice (Moss Collum and Laura Dean)

I expected the session to be about games designed to bring out good and bad practices in pairing, and I expected to be able to play the games to hone my pairing skills. It started out well, with the facilitators asking participants for their good and bad experiences with pairing. There were some high performers in the room, including Corey Haines and J.B. Rainsberger, and many others who had interesting experiences to share. I expected we would then simulate some of these problems and apply some new techniques to solve them.

No such luck. The entire presentation consisted of the two facilitators talking. There was no hands-on exercise and no "games" as such. The games were simply different approaches or styles of pairing. Even so, some of them look pretty useful as "shovels" we can use to dig ourselves out of particular types of problems, when a pair may be stalled for one reason or another.

They discussed four such "games." Ping Pong is simply the basic ping pong pairing style, in which partner A writes a failing unit test, partner B writes the code to make it pass and writes the next failing unit test, and partner B makes that test pass and writes the third test, etc.

Farsighted Navigator uses the basic driver-navigator style with a twist: The navigator can't speak about anything of larger scope than a single method, and the driver can't write anything other than what the navigator talks about. It may be useful when a pair is unsure what to do next and keeps changing direction, or remains at too high a level of abstraction to get any actual code done.

Socrates is another variation on the driver-navigator style. In this case, the driver is not allowed to respond verbally to anything the navigator says, but can only "answer" by writing code. It's a bit harder to see the value of this, unless perhaps the pair has fallen into a pattern of talking too much about what they should write, instead of just writing something and letting the code tell them what the design should be.

In the No Talking game, neither partner speaks, and they try to maintain a good flow of development while passing the keyboard back and forth quickly. They might use a chess timer to create a sense of urgency about keeping the micro-coding sessions very short. I'm somewhat at a loss to understand what problem this solves. I can see that it might shake things up a bit if team members are getting bored with the routine of work.

I think Moss and Laura have a lot of useful information and experiences to share, and I hope they will consider restructuring this session to make it a bit more engaging. One possibility might be to blend the "games" content with the presentation approach we used in "Effective Pairing: The Good, the Bad, and the Ugly" at Agile 2008 (with Brett Schuchert, Lasse Koskela, and Ryan Hoegg), Agile 2009 (with Brett Schuchert, Lasse Koskela, and George Dinwiddie), and Devoxx 2009. We acted out specific anti-patterns in pairing, and then asked the audience to identify the problems with the interaction and suggest corrective action. The "games" Moss and Laura came up with could be used as specific suggestions to overcome the anti-patterns.

The worst of legacy code: Forensic development (Jason Kerney and Llewellen Falco)

This session wasn't about "agile," but it was still very interesting and practical. Each of the presenters has had the privilege of working in a production support role and dealing with extremely difficult legacy code. When you have to fix a bug in production, you don't have the luxury of time to study and understand the application fully. You need techniques that help you isolate the source of the bug quickly. In this session, the presenters introduced us to two specific techniques: The Peel and The Slice.

The presenters themselves can explain what the session was all about better than I can. They prepared a video and posted it to YouTube, here: http://www.youtube.com/watch?v=yAKL6rlEF_s. The video goes through basically the same presentation as they made in person to introduce the two techniques during the session.

The debugging exercise was based on a snippet of legacy code that one of the presenters actually had to support in a past job (I don't recall which one). The code is available online here: http://pastie.org/843507. The bug report stated that when three of the loans is associated with "Tom," then two records are written to the database for "Tom" instead of one.

The fact the code is in Russian is amusing, but not really relevant to the exercise except that it illustrates an interesting fact about finding production bugs: You don't need to know what the application is supposed to be all about. You just need to find the bit of code that isn't behaving properly, according to the bug report. With that in mind, it can be misleading to read comments, method names, and class names that do not accurately reflect the behavior of the application. If you can't read these things, then they can't mislead you. There's nothing you can do other than run the code and make it reproduce the reported behavior.

The basic idea is to get the code to run so that you can isolate the cause of the error. A chunk of code out of context won't run, of course, because there's no database, no framework, no container, no nothin'. In a time-critical debugging situation, you don't have time to set up a test environment with all the bells and whistles. As the video demonstrates, you can peel away unnecessary code to get at the code you need to run, and/or slice out the code you need to run and omit deeply-buried "pits" that prevent you running it.

To help you, you might use a coverage tool to tell you when you have successfully set up the code to run completely, and a mocking library to help you fake out external dependencies so you can focus on the problematic code. Although mocking libraries are often associated with agile-style development, this is not really a development exercise and has nothing to do with "agile" as such.

The presenters used EasyMock to help them fake out dependencies. When they did so, a "Boo!" was heard from the back of the room, followed by laughter from the group. EasyMock seems to have a bad rep these days. As I watched the presenters step through the exercise, I realized that an advantage of EasyMock in this situation is that it is "strict" by default, but not nearly as cumbersome to set up as JMock2. While most of us would prefer JMock2 when we need a strict mocking framework for new development, the relatively simple EasyMock is a good fit for a debugging situation. We want the strict behavior by default to expose hidden method calls when we are exploring the code (by executing it).

The process consists of getting the code to run somehow, usually by creating a class with a main method and bringing in just enough of the production code to get it running. We expect to get a number of stack traces along the way. That is how we learn about hidden method calls we need to mock. To keep the stack trace relatively free of clutter, it's just as well to run with a main method and dispense with test runners. It's interesting that you can get into a pretty good flow using the Slice and the Peel, and isolate the true cause of the bug in far less time than it would take to try and learn the code base "properly." The code you write for exploration purposes is throw-away code.

Check out the video and the code snippet. If you ever have to debug a production problem, you might find the techniques useful. The examples were done in Java, but the Slice and Peel are techniques and are not language-dependent.

Large-scale refactoring using the Mikado Method (Ola Ellnestam and Daniel Brolund)

In this session, we learned about another useful technique for working with legacy code, and it, too, is not specific to "agile." The Mikado Method is named for a pick-up-sticks game called Mikado. In Mikado, one of the sticks is substantially more valuable than the others. It rarely happens to wind up on top of the pile when you drop the sticks, so you have to work carefully and in a step-by-step manner to reach it. Similarly, when you have to refactor a legacy code base to add a feature, the bits you need to cull out of the Big Ball of Mud are rarely obvious or easy to access.

Mikado takes the approach of beginning with the end in mind. You begin by creating a dependency graph starting with the end goal. Then you identify the immediate prerequisites to reaching the goal, and continue identifying dependencies in that way until you reach a reasonable starting point. What is a reasonable starting point? That will be a judgment call and context-dependent. In any case, once you've got the dependency graph, you start working your way back from the leaves toward the goal, step by step.

Despite the session title, this isn't really a technique for large-scale refactoring. Indeed, you perform only the minimum amount of refactoring necessary to achieve the goal. The problem space for the Mikado Method is the addition of a new feature to an existing code base, especially when the existing code base is not already well-factored.

Here are some online resources about the Mikado Method, mostly written by Ola and Daniel:

• http://mikadomethod.wordpress.com/ — Blog and PDF book
• http://github.com/brolund/mikadomethod — Examples

 

Doing agile right using the right tools (Hadi Hariri)

This was not a programmed session, but a vendor demonstration on behalf of JetBrains. Hadi demonstrated BDD development in .NET using MSpec and Resharper. MSpec is short for "Machine Specifications."

Oddly, I was the only attendee until about halfway through, when we were joined by a second. Not really sure how that happened, except that the demo took place during a lunch break. Lunch breaks were 90 minutes, so there was plenty of time for people to do other things. The Open Jam areas were always busy, anyway.

MSpec is an interesting tool and a useful addition to the .NET toolkit. As Microsoft winds down the IronRuby project, MSpec may become more important since it is unclear how we will be able to use Cucumber for BDD in the .NET environment. The tool looks good, and Hadi's skills as a presenter and demonstrator are excellent. Time well spent. Here are some online resources:

• Article by Aaron Jensen on CodeBetter.com
• machine.specifications on github

 

Nano-incremental development: Elephant carpaccio (Andrew Shafer and Alistair Cockburn)

This was a hands-on coding session in which we practiced breaking requirements down into the thinnest possible slices and delivering them in very short iterations of 9 minutes. We were divided into teams of two or three.

This is an exercise Alistair devised to help programmers understand that it is actually possible to build solutions in very small increments, and then to help them understand how to do so. Alistair describes the exercise in detail on his website, and he encourages people who have gone through it under his guidance to use it in their own organizations.

Given an assignment that was pretty small to begin with, we had to build and demonstrate very small increments of the solution. One member of each team functioned as the customer, and could clarify the requirements in any way he/she saw fit so that the team would understand the relative value of each nano-feature.

Our team consisted of three people. We managed to get through the complete assignment on time, although we might have done a bit more refactoring of the "production" code if we had had the time.

In the debrief, Alistair asked for a show of hands to see how many teams had completed all the requirements. About half the teams raised their hands. He then asked how many teams had used a rigorous test-driven development process, including incremental refactoring of both the production code and the tests, to build the solution. Several teams raised their hands. The intersection of the two groups comprised one member: Our team.

Alistair apparently had expected that no one would complete the full assignment using rigorous TDD, since the assignment was so small that the overhead of the TDD cycle could easily overwhelm a team's ability to deliver anything in just 9 minutes. He also suggested that because of time pressure, agile methods tend to encourage sloppy code. He ignored the fact our team's hands were raised, maybe because it was statistically insignificant, maybe because he just didn't notice, or maybe because we didn't have much time left for discussion.

In any case, I disagree with the idea that agile methods (or any other methods) particularly encourage or discourage sloppy code. I think it's a question of self-discipline and attention to craftsmanship. Our team of three consisted of people who had never met, who represented three different age cohorts, who came from different countries, who represented different genders (only two of those, of course), spoke different languages, had different levels of formal education, and had different professional backgrounds. We collaborated at all times and discussed different alternatives at each step in the exercise. This diverse team was able to apply strict TDD to the problem and complete everything within the short time frame allowed, while maintaining discipline in TDD and code craftsmanship. Even with the very short timeframes used in the exercise, there was time to do all these things properly.

Agile 2010 part 4: Effective coaching and how to grow as a coach
Topic: General

I spent quite a bit of my time during the week in this area. I attended four sessions that directly or indirectly addressed the topic, and participated in two informal group discussions about how to improve the state of the art of coaching in the agile space. The coaching-related sessions I attended were very different from one another, and all were presented by people who do this sort of coaching for a living: David Draper, Arto Eskelinen, Sami Honkonen, Rachel Davies, Gino Marckx, and Michael Sahota. It's worth noting that there were many more sessions on the topic of coaching; it was a strong focus of the conference program.

Retrospective for an agile coach (David Draper)

David shared three past experiences in coaching agile teams. He set out a timeline for each, consisting of a horizontal line representing time and a series of boxes highlighting key events in the project. The timeline was general and did not represent absolute increments of time. Each box contained a small smiling or frowning face icon, and some boxes contained one of each.

David summarized the course of events in each case and described what had happened at each of the key points in the timeline. Then, working in small groups, we talked about what had happened and how a coach might have approached each situation differently.

The value of the session was that each of us gained new insights and ideas from our peers that can help us handle similar situations in our own work.

At one point, David described an incident in which the team presented a project roadmap to the business stakeholders that demonstrated the team would have to increase its velocity exponentially (and here I do not use the word in its loose sense) in order to meet the prescribed deadline. The stakeholders did not understand the implication, and told the team to proceed with the plan. David wrapped up the story with a quotable quote: "When you tell people what they desperately want to hear, they don't necessarily detect the fact you're saying it tongue-in-cheeck."

That's a very valuable lesson to take from the story. All too often, we who understand how agile works assume it's perfectly obvious one cannot play games with velocity and force a given scope to fit into a given schedule. It's not so obvious to others, especially when an on-time delivery of the full scope is in their vested interest. We have to lead them by the nose toward understanding.

Effective questions for an agile coach (Arto Eskelinen and Sami Honkonen)

This session was very different in content and in presentation style from David's. In a very well-structured series of short explanations and short workshop activities, Arto and Sami introduced us to a coaching model called GROW: Goal, Reality, Options, and What To Do. They reinforced a concept we should all know, but that we can forget in the heat of the moment: Our role as coaches is to create awareness and a sense of responsibility, and not merely to hand people instant solutions to their problems.

A key point was that the way in which we formulate questions has a great deal to do with whether we will receive meaningful and actionable responses. They pointed out that a good coaching question has the following characteristics:

• It leads to exploration
• It aims for a descriptive answer
• It avoids judgment
• It avoids unproductive states of mind

Generally, these will be What? When? How many? How much? questions. Who? and Why? questions can easily lead to defensiveness and blame-shifting.

 

Arto and Sami suggest that unproductive states of mind can be created by asking questions that cause:

• Laying blame
• Justification
• Denial
• Guilt
• Shame
• Obligation

It's hard not to notice the similarity between this list and the levels of personal responsibility defined in Christopher Avery's Responsibility Process (short of the final level, Responsibility):

• Denial
• Lay Blame
• Justify
• Shame
• Obligation

So, if we can keep in mind basic principles of personal responsibility, we won't go far wrong in formulating constructive questions with coachees.

 

In discussing the session with Arto and Sami before we began, I offered the following negative example: "Did you write that code on purpose, or did you just let your cat walk across the keyboard?" They agreed that this was indeed a negative example. It in no way leads to exploration; it does not guide the person toward a descriptive answer; it is highly judgmental; it creates a defensive state of mind.

I must admit it was not a random example. Not so long ago, I was sitting with a programmer on a team I was coaching and reviewing some of her code. I asked, "Have you heard of the Single Responsibility Principle?" She cheerfully recited a textbook definition of SRP. The code itself did not bespeak a profound understanding of SRP, but at least I had dodged the sarcasm bullet. It was sheer dumb luck that she took the question so literally. In any case, the question did not lead to any improvement of awareness or responsibility.

In the real case, I found that in subsequent interactions with that team member I was able to help her see potential improvements in her code by asking more specific questions about particular sections of the code, and by focusing on questions about how the structure of the code might affect future modification and support of the application. It would have saved us both some time had I participated in this session first.

The coachee might not realize there is a problem at all. In that case, we need questions with the characteristics listed above to help him/her reach an understanding that there is something to be done. In the personal example, the team member did not perceive any problems with her code. A few exploratory questions could have set the stage for a constructive working session.

In the Goal phase, we are trying to find out what problem the coachee wants to solve, and how he/she will recognize success when it happens. We want to help identify a goal that is:

• high enough
• positive
• meaningful
• specific

In applying this advice to the personal case, I find myself at a loss to define a good goal prior to working through at least the Reality and Options portions of the GROW model. A preliminary goal statement might be:

• Carry out a refactoring that takes the class closer to a clean design.

There's no assumption that we can completely refactor the class in one fell swoop, so at least it isn't unrealistic. It sounds positive. On the other hand, it isn't really meaningful, and definitely not specific. We don't have enough information yet to know which of the several responsibilities the class supports would be the best choice for the initial refactoring exercise.

 

At this point, I'm thinking the GROW model doesn't necessarily have to be applied sequentially, although that's the way the workshop exercises introduced it. In retrospecting the real case, I thought that maybe the Reality phase would enable us to craft a better goal statement.

According to the GROW model, good Reality questions are designed to explore the coachee's view on the current state. We want to find questions that:

• test assumptions
• explore different angles
• expose feelings

Relating this to my personal example, it was clear that the team member needed guidance to discover the problems in the structure of her code. I did get around to this, despite my poor opening question. Feelings exposed: Pride of workmanship. Assumptions tested: What does SRP actually look like in real life? Different angles explored: What sorts of changes would improve this code? What sorts of changes are possible? New feelings exposed: Desire for greater pride of workmanship. No feeling of blame, judgment, or obligation. So far, so good; but we still don't have a good goal statement.

 

The Options phase of the GROW model looks for alternate paths to the desired state. To that end, questions should:

• state existing ideas
• challenge limitations
• include discussion of "stupid" ideas
• bring out at least 3 alternatives

I have to pare down the details of the real case considerably in the interest of space. Suffice it to say the class in question was to be part of a webapp generated by a relatively rigid framework. The framework would call methods in this class to execute custom code as part of its built-in request/response cycle. The obvious and crude implementation (and the one recommended in the product tutorial) was to jam all the custom code directly into the callback methods. The problem in real life is this approach results in a bloated class that performs several distinct functions.

 

Relating the Options phase of GROW to the personal case, I could have used well-crafted questions to help expose the team member's existing assumptions about the structure of the class and the possibility of refactoring the code, to challenge the apparent limitations imposed by the rigid framework, explore a few "stupid" approaches in hopes this might spark some out-of-the-box thinking, and bring out 3 or more alternative approaches to improved design.

At this point, we could have returned to the Goal step armed with information obtained from the Reality and Options steps. We would have enough information to craft a goal for a first pass at refactoring the class that was high enough (it wouldn't be easy in any case), positive (it would extract the largest chunk of secondary functionality), meaningful (it would clearly improve the readability of the code, if nothing else), and specific (it would address one particular secondary responsibility).

That takes us to the What To Do step, the W in GROW. Arto and Sami described this as "agreement to walk the path." In the case of my personal example, we could define a specific refactoring that had a clear definition of done, an observable outcome, and a target date. The session was about coaching in general, and not all coaching has anything to do with technical issues. Agreement to walk a path of improvement in mindset, process, or principles may mean that the coachee agrees to begin walking the path, or to resume walking a path from which he/she has strayed. In the more general case, the What? questions should examine:

• What to do?
• When to do it?
• Observable outcome?
• Obstacles removed?
• Uncertainty cleared?

You might think that the GROW model applies best in general coaching situations, and may have less to offer in a technical coaching situation. In fact, technical professionals have very sensitive emotions, especially with respect to their own code. There are a lot of programmers out there who perceive themselves as very advanced, very "senior" professionals who already have a long track record of success. Yet, most of them have no inkling of Software Craftsmanship. We have to be able to explore relevant information and bring out unpleasant facts without touching the wrong buttons. Otherwise, we won't get anywhere.

This was a truly excellent session. If you have a chance to see it on another occasion, don't miss it. For more information, download http://sami.honkonen.fi/checklists.pdf.

Agile Coaching Dojo (Rachel Davies)

Rachel was intrigued by the coding dojo concept and wanted to see whether it could be used to improve coaching skills. This session was a run-through of a dojo structure she created for coaches.

Working in groups of six or seven, we took the roles of seeker, coach, observer, and facilitator. The seeker was the person seeking help. The seeker is a coach who has a challenging coaching situation and seeks advice from his/her peers. Each group had one of these. The coach is just what the name implies. Each group had 2 or 3 coaches, who interacted with the seeker one at a time for five minutes each. The observer did not speak, but observed the nature of the interaction between each coach and the seeker, and provided feedback after all the coaches had taken a turn. The observer's feedback was not coaching advice, but was limited to comments on the interaction itself. The facilitator kept time and kept everyone within the boundaries of their roles.

Everyone chose the role they wanted to play. The first step was for the seekers to choose a coaching problem from their own experience. They discussed it in roundtable fashion with their group. Then, each seeker left their original group and joined a different group, where no one had heard about the problem. Then the kata began. Each coach interviewed the seeker for five minutes, one at a time. Other group members did not speak during the interviews. Observers observed, and made notes if they wished. After the interviews, the observers discussed their observations of the style of interaction with the rest of the group. At the conference, there was insufficient time for multiple rounds, but in an actual dojo everyone would have a chance to play each of the roles at least once.

It seemed a worthwhile exercise to me. The seeker at our table said he came away with some concrete ideas about how to coach the people in his organization through the problem he was having. It reminded me somewhat of a session at Agile 2007 along the same lines. In Coaching 101: A Role-Playing Session, Jeff Nielsen and Dave McMunn led us through contrived coaching situations in groups of three: Coach, coachee, and observer. The session leaders and some of their colleagues acted as facilitators, to answer questions about the process and to keep time. In that session, the facilitators created contrived situations; coaches could just as well use real scenarios. The three-person format may allow for more-focused interaction and faster role changes than the seven-person format.

Another possible advantage of the three-person format is that there may not be enough coaches in any given local area to form even a single group of seven for regular practice. For example, David Draper was in our group, and he mentioned that a coaching dojo would be a great thing for his company, but they have only five agile coaches in the London area. Using the three-person format, his company could organize an internal coaching dojo with the five coaches plus another employee in a role that calls for coaching skills, such as a project manager or Scrum Master. The six could have a very productive 90-minute dojo session with ample opportunity to act in all three roles, and to explore several coaching scenarios from their various clients. Coaches who work in the same general area, but who work for different companies or independently, could also organize their own dojos.

Regardless of the format, repeated practice of the basics is as important for honing coaching skills as it is for honing programming skills. I hope Rachel will continue to refine the idea and move it forward.

Quadrants of Effectiveness Game (Gino Marckx and Michael Sahota)

This is a board game for five participants designed to illustrate strategies for maximizing the effectiveness of a team. It's described on Gino's blog and in this set of presentation slides. After the session, I asked Gino if the game materials were available for purchase, because I want to use the game with my own clients. He said the materials would be available sometime soon.

I won't go into details about game play. The basic idea is that each group of players makes moves based on cards, as in trading card games. Players move markers around a board. Each player has two markers — one that tracks the urgency of the current move, and one that keeps track of the number of points the player has accumulated.

The point of the game is to demonstrate the effect of different strategies for maximizing value. Certain aspects of the scoring are not explained at the outset, so that players will craft individual strategies. At some point, the facilitator explains that the real goal is for each team to maximize its points. The five players at each table constitute a single team, not five individual competitors.

At our table, people played competitively at first. Once the team scoring aspect was explained, the team's dynamic changed to a collaborative style. Using the collaborative strategy, we finished the session with the second-highest score. The highest-scoring team had also changed to a collaborative strategy early in the game.

The results also brought out another aspect of team dynamics: The speed with which decisions are made. We did not count the number of rounds played at each table, but we speculated that the speed of game play may have accounted for the difference in scores between the top two teams. Our team was very slow to make each move. The team members discussed options and possible moves for some time before reaching a decision. We wondered whether this caused us to play fewer rounds in the allotted time, and therefore to accumulate fewer points than the top-scoring team.

The relevance to real team dynamics is that we cannot take too long to make decisions in our projects, because events will overtake us. We have to be able to make decisions quickly based on limited information. That is not an explicit part of the Quadrants of Effectiveness Game; it is simply an observation based on the outcome we obtained in the session.

In general, games are a great way to bring out important points we want our clients to understand so that they can make well-informed decisions during the agile transformation. This particular game is especially powerful and simple enough to learn quickly. I relate this session to the theme of improving coaching skills because I like to use games in my coaching of non-technical people and non-technical practices.

Informal discussions of coaching in the agile space

On Tuesday morning, I stumbled into a great conversation. In search of breakfast in the hotel restaurant, I encountered a group of people waiting for a table. I knew some of them, so I asked if I could join them for breakfast. They warned me they were going to have a breakfast meeting, so I could sit with them as long as I kept my head down and my mouth shut. I had planned to keep my head down anyway so that I could shovel food into my mouth, so I agreed.

This was no random assortment of breakfast-seekers. The instigator was Rachel Weston, Director of Services at Rally Software Development, and the group comprised Lyssa Adkins, author of Coaching Agile Teams: A Companion for ScrumMasters, Agile Coaches, and Project Managers in Transition; Rachel Davies, author of Agile Coaching; Alan Atlas; David Chilcott; Julie Chickering; and Mark Kilby — all agile coaches.

What brought these big brains together was the growing need for coaches in the agile community, and the lack of support for coaches who want to improve their skills or exchange ideas with peers. These individuals, who are leaders within the agile community in the area of coaching coaches, are not necessarily leaders in the broader field of coaching. They were full of ideas, and Rachel Davies agreed to set up a forum on the Agile Alliance website to serve as a collection point for links, contacts, and other information relevant to coaching the coaches.

Unfortunately, I have been unable to access that forum. I had a series of problems getting logged into the site at all, and ultimately gave up. I'm very interested in being part of the coaching-the-coaches initiative, but not interested in websites that prevent people from getting in. I expect eventually there will be another entry point for internet access to these resources. Rachel made it clear that she was willing to get things started by creating the forum, but that she would not be able to carry the load of volunteer work to keep the thing going. I think we will need a user-friendly site that doesn't ask for passwords and annual membership fees.

The group agreed to host a discussion in the Open Space area later in the week. I attended that, and was pleased to see at least twenty professional agile coaches in attendance. The group generated even more good ideas, which were noted on flip chart sheets. I think this initiative will result in a higher level of coaching skill throughout the community.

Agile 2010 part 3: How agile adoption can affect people in different roles

I attended a couple of sessions aimed at people who usually work in roles different from my own. I wanted to gain a better understanding of how they perceive agile methods and how they see themselves participating in agile projects.

Dance of the Tester (Janet Gregory)

I came to the agile community from the standpoint of a programmer. I had been working in the role of Enterprise Architect at the time our company embarked on an agile journey. I dropped the title to join an XP team in the role of Team Member, and learned a lot about how different types of work are performed in an agile workflow. Although I perform the work of other roles, including tester, analyst, project manager, Scrum Master, technical lead, and team coach, it was informative to learn how an agile implementation looks and feels from a perspective other than that of a programmer.

Janet Gregory's intent was not to provide me with insight into the perspective of a software tester. Dance of the Tester is an introductory overview of the role of tester on an agile project. Although it is an introductory session, I learned a lot from it because it looks at agile work from a perspective other than my own. I filled the back of an evaluation form with specific praise for the session, and could have filled another sheet.

She emphasized certain aspects of agile thinking, including whole team, fast feedback, verbal communication, automation, retrospectives, and (interestingly) discipline. In describing the difference in mindset between a traditional tester and an agile tester, she used a phrase that struck home and that I intend to borrow: constructive skepticism. The tester's goal is to contribute to the whole team's effort to deliver high-quality software, and not merely to look for bugs in the code. A mindset of constructive skepticism keeps the tester's role positive and collaborative. It's a powerful concept.

To help explain how different types of testing occur on an agile project, who typically performs them, and why they are done, Janet used the canonical agile testing quadrants diagram to frame this part of her presentation:

Janet described a comprehensive roadmap for testing activities in an agile context. It spanned project planning, release planning, iteration pre-planning and planning, testers' direct contributions during iterations, system testing, and support for deployment and releasing. It was clear throughout that the information was based on direct, practical experience and any discussion of theory was pinned to field experience.

If you want more from Janet Gregory, check out her website at http://janetgregory.ca/ and her book (with Lisa Crispin), Agile Testing: A Practical Guide for Testers and Agile Teams.

Beyond Staggered Sprints: Agile user experience design teams in the real world (Jeff Gothelf)

Another session that provided great insights into non-programmer perspectives was Jeff Gothelf's "Beyond staggered sprints: Agile user experience design teams in the real world." I was especially interested in this because I'm currently working on a project that is heavily driven by the user experience design, at a client that is implementing agile methods for the first time. Jeff described the experience of the UX design team at his company after the software development group decided to implement agile methods — without consulting his team or anyone else in the company. It was a classic bottom-up agile adoption (and still ongoing).

There was good attendance at the session. I didn't count, but I think there must have been at least 40 people in the room. I didn't recognize anyone at all. That was my first indication that I was in the right place to learn about an unfamiliar perspective.

Jeff described each of four "attempts" to align the UX design team with the agile processes the software group wanted to use. At the outset, the UX team operated as an internal service that did work for several projects concurrently on behalf of four lines of business. This structure posed no problems in the context of the waterfall process they had been using at the company. When the software group suddenly and unexpectedly (from the point of view of the UX team) introduced "agile" methods, the UX team had to adapt without having any previous experience or knowledge of agile, and without the benefit of any training or coaching. Jeff scoured the internet to find that there was a dearth of information focusing on UX designers. He found some value in Jeff Patton's work, and engaged Alistair Cockburn to have a look at the process, but on the whole the UX team was on its own.

First attempt. The software group adopted a two-week iteration length. So, the UX team's first attempt to align with this model was to squeeze the waterfall process into two weeks, complete with all the handoffs, reviews, and quality gates. I trust I need not tell you how well that worked. They also mimicked the software team's use of whiteboards. They put 14 rolling whiteboards in the UX design work space. Jeff used internal surveys to gauge people's response to the changes. One respondent to a survey during this phase of their transition wrote, "The whiteboards do not help organize the UX team's work at all. Instead, they block out natural light from the windows and create a harsh and uncreative visual environment."

The UX team also stopped doing functional specs in advance. They did not understand how to compensate for this in an agile process, so they began to use the cards on the whiteboards to capture the functional specs. The boards had multiple purposes and were cluttered with all kinds of information. The information that was no longer being provided by functional specs also bled over into the wireframes. They came to be heavily annotated with all sorts of details that normally are not included in wireframes. This was a direct consequence of their being told that functional specs aren't "agile," while no alternative was offered.

The UX design team produced a large chart to explain how they felt about the whole thing. Their perspective was aptly summarized by a box on the chart labeled, "Agile = project never complete." As far as they could tell, agile work amounted to an endless series of small tasks. There was no endpoint, no celebrations, no larger context. Some of the other boxes on the chart (and there were many) read as follows:

• Negative environment that fosters failure and generates low morale
• Best experience never gets built
• Deadlines before information
• Conjured sense of urgency
• No insight into larger goals
• No ideation time - skills not being used fully
• Minimum viable product (?)
• "Going for the bronze!"

My main take-away from this is that all those who will be affected by a change of process have to be engaged during the planning stages for implementing the new process. All these problems occurred because the UX design team was blind-sided by the sudden shift to agile methods. Under the heading of Misery Loves Company, I can say that people in other roles also experience these feelings during the first few months of agile adoption.

 

Second attempt. The UX design team crafted a Style Guide to provide people with standard information about design elements, so that every project would have have to start from Square One. It contains color palettes, font standards, HTML forms standards, and many other details. They also started to build a library of reusable UI assets; widgets already customized according to the Style Guide. These innovations drastically reduced the amount of time needed to generate UI elements for projects. It also opened the door for people other than UX designers to pick up design tasks, depending on how the workload looked at any given time.

And the downside...

• "Everybody's a designer" — zombies?
• Cycles valued over creativity

That's a much shorter list of downsides than we saw from the first attempt, but these are qualitatively serious downsides. Why would a designer continue to work in such an environment at all?

 

Looking at it from a programmer's perspective, I can say that we like to abstract the mundane, repetitive stuff out of our way so that we can focus on the more-interesting problem solving aspects of our work. We use reference architectures, design patterns, third-party libraries, frameworks, templates, UX Style Guides, and anything else that helps us avoid repeatedly creating the same code over and over again. What is left over is the real brainwork — the reason we entered the field in the first place.

When we do the same thing with UX design work, what is left over after everything has been abstracted away? UX designers want to create the first design of a New Thing. They want to create an experience, not just another cookie-cutter website. When all they have to do is make selections from a predefined library of assets, where's the creativity? What's the point?

Third attempt. The UX design team was feeling disconnected from the whole process. They put everything in-line; that is, the UX designers are now part of specific cross-functional Scrum teams, each dedicated to one line of business. They carry out usability testing every other week; they bring in real (external) customers for this. The UX team incorporates feedback from these sessions into their current and future projects. Things got better.

Fourth attempt (ongoing). Jeff described this as bringing everyone together and then pulling everyone apart. Before starting the routine iterations of a new project, everyone involved — not only the UX design team — participates in a design session. They do collaborative sketching in which they generate 6 ideas in 5 minutes. They then take 5 minutes to boil it down to 3 or 4 ideas. Another session results in a single idea. They keep all the sketches for future reference.

Jeff showed us examples of sketches that were created during these sessions. He asked the group to identify the primary role of the person who drew each sketch. It was easy to see which were created by programmers, managers, and so forth as opposed to "real" designers. They are finding value in this deep level of collaboration, even if most people aren't trained artists.

This is where the company stands as of the day of the presentation. It has taken them over a year to get to a place where the UX design team does not feel excluded and discouraged. Jeff said that the programmers are now asking the UX team to size their tasks in terms of story points. They will try that very soon. Personally, I'm not too enthusiastic about that. The nature of the work is very different. There is no reason to assume both should use the same techniques to manage their tasks. But time will tell.

Personally, I wanted to ask Jeff what the original business drivers had been to try agile methods in the first place. Had it been a response to business problems that had been measured and assessed, or had it just been something the technical staff was keen to try? I didn't get a chance to ask him directly. What raises the question in my mind is the fact the UX design team had no idea such a profound change was about to happen in the company.

Agile 2010 part 2: Perspectives about current state and future direction of agile

Needless to say, every session and every conversation throughout the week added to my understanding of how people perceive agile these days, and where they think we should be going. There were quite a few informal discussions of the topic every day. For me, the following contributed strongly to this area of learning:

• Alistair Cockburn's Oath of Non-Allegiance
• A new certification program, the International Consortium for Agile
• Session: Whither Agile? A participant-driven round table (me)
• Session: Today's best practice is tomorrow's process smell (me)

The Oath is simply a statement that we will consider any idea regardless of its source, rather than limiting ourselves to some predefined and branded package of ideas. It came about as a reaction to all the pointless bickering in the community the past few months, and to the tendency for agile proponents to judge everything according to whether it fits a predefined model of "agile" regardless of whether it adds value in a given situation.

 

The ICA is a community response to the circular debate about certification, and about who gets to decide how to certify people, and so forth. Companies can join the ICA, but it is not controlled by any one corporation or organization. It is a work in progress, but already has a pretty well-designed framework for a certification program.

The two sessions listed were both mine, so I can safely summarize their intent. I had hoped the round table discussion would help us come around to a consistent view of where "agile" stands as of today and in which direction we, as a community, want to take it next. The best practice/process smell session was meant to help us identify cases when we have become stuck using a suboptimal process because we've had to work around a tactical issue, and then never got around to solving the root cause. Neither session turned out as I had expected.

Let me review the round table session first. If we take the goals of agreement on a common vision and selection of a clear direction as the acceptance criteria for the session, then it failed. Fortunately, the unexpected (to me, anyway) outcome of the discussion provided valuable learnings (to me, anyway).

The discussion was very open-ended and was largely participant-driven, and yet I did have a few ideas I wanted to float to the group. I tried to relate the present state of agile to the canonical innovation adoption curve and to map out a continuum from "heavyweight" to "lightweight" processes. I was prepared to introduce a few other angles on the topic, too, but these two along with ideas the participants brought with them were more than enough to fill the three-hour time slot. Several people stayed afterwards to continue the discussion on their own.

I wrote "2000" and "2010" on two sticky index cards, and applied them to a large drawing of the innovation adoption curve. I placed the 2000 card at the edge of the Chasm, and the 2010 card near the end of the Early Adoption phase. This represented my concept of the penetration of "agile" at those points in time. After a moment of silence (one of the few, I'm happy to say), one of the participants walked up to the wall and repositioned the 2010 card at the top of the curve, mid-way through the Early Adoption phase. Heads nodded in agreement.

I talked through an analogy I had intended to demonstrate, but I never purchased the food coloring. Picture a large container of clear water. That's the IT industry circa 2000. Now picture a small vial of dark blue fluid (it was to be water with blue food coloring). The agile movement introduced the dark blue water into the IT industry — pour the contents of the small vial into the larger container. Ten years later, the IT industry is pale blue. It will never be dark blue, as the proponents of agile envision success, but it is definitely more blue than it was before. This is a sort of success. The question is, where do we go from here? We aren't at the same state we were in 2000, so the same solutions probably won't work. How do things differ today?

Some participants related to the analogy, but most disagreed with the premise. They felt it was possible to make the water darker, and we should not accept poor implementations of agile as "successes;" not even partial ones. One participant took the idea in a different direction. Laurent Bossavit noted that if we began with milk and added a drop of something, that a living culture would begin to grow in the milk and the result would be cheese. One does not debate cheese with a Frenchman. Beyond that, I found his analogy powerful. The colored water is the result of planting seeds that never grow; the cheese is the result of beginning a process that takes hold and moves forward on its own. (I also like the play on the word "culture," but that's neither here nor there.)

Laurent's take on the growth process provided a segue to another notion I wanted to explore with the group. My understanding is that the people who wrote the Agile Manifesto originally called their meeting the lightweight process summit. They were interested in removing waste from IT processes, to transform them from "heavyweight" to "lightweight." Apparently, some members of that group feared that people would misunderstand "lightweight" to mean "not robust." They decided to look for another word. They found one.

I wanted to get back to the fundamental idea of making our processes lighter. The agile community has benefited from an infusion of ideas from Lean Thinking in the past few years. Key lean ideas pertaining to the idea of lighter processes include:

• Perfection — always keep perfection in mind as a target, even though we understand perfection is not actually achievable;
• Continuous improvement — use the Five Focusing Steps from the Theory of Constraints as a framework for improving our processes, moving them closer to perfection; and
• Focus first on value, second on continuous flow, and third on removing waste from our processes.

To start this part of the discussion, I posted a large drawing of a horizontal line labeled "heavyweight" on the left and "lightweight" on the right. I had prepared several index cards with the names of various approaches, models, or practices in the areas of organizational structure, process framework, and development practices. I held up each card, the group reached enough of a consensus about word meanings to prevent the discussion from stalling, and we collectively decided where on the spectrum the item belonged.

 

These were, for example, things like "Linear SDLC process," "Time-boxed iterative process," and "Flow-based process," in the category of process frameworks, along with things like "Time-based task estimation," "Relative sizing of work items," and "Single-piece pull w/o task estimation" in the category of practices. There were other categories, too. We laid these things out along the line and associated items that were prerequisite to others.

The idea was to map out a continuum of agile practice from heavy to light, with the assumption that our target is to make things as light as possible. At first, the group bunched most of the items in the middle of the spectrum. They protested that "we can't do away with practice ABC because of constraint XYZ." True. They protested that a linear process can be lightweight and an "agile" process can be heavyweight, depending on how one does things. True. One participant pointed out that single-piece pull may simply be inappropriate in the context of software development. Possibly true, especially in the absence of a long list of prerequisites that are barely even on the horizon of general management and IT practice today. They were focusing on the as possible part instead of on the as light part of the statement.

These are present-day-reality truths; they are not inherent attributes of the models and practices on the chart. I tried to guide the discussion toward distinguishing between the inherent "lightness" of each item on the one hand, and the practical reality of implementing that item in participants' current circumstances. In that light, the group gradually agreed to spread the cards out a little more, so that we could see a sort of progression from heavy to light. My goal in this was to get us a little closer to an idea of "perfection" (in the lean sense) that we could use as a reference for deciding whether an opportunity for improvement exists in our work environment. Without that sort of reference, how can we know whether improvement is possible or what sort of change would be helpful?

This seemed to open the sluices for fresh ideas. Everyone in the room had been thinking about this issue for some time already, and they all had great ideas. We brought up some of the better-known emerging ideas such as Capabilities-Based Planning, Real Options, Beyond Budgeting, and restructuring organizations such that application development and support functions reside directly in the business units they serve. We also questioned some of the Lean concepts that are being talked about in agile circles these days. In particular, the whole concept of the value stream was questioned; another notion, the value network, was proposed by one participant. The same participant questioned whether Throughput Accounting was a good fit for software development. (Sorry, I've forgotten his name; if you know who it was, please post a comment or send me an email. He works for Emergn, if that helps jog the memory.)

My second session was entitled, "Today's best practice is tomorrow's process smell." I made some foolish assumptions in preparing this session. The first was that I assumed an "expert" level session would draw participants who were already applying agile principles and practices very well, and who had reached an impasse or a challenge of some sort in moving ahead with continuous improvement. That assumption led to other assumptions about how much context the participants would need in order to contribute to the discussion. I prepared insufficient physical tokens of the content, such as charts, cards, handouts, or slides, and provided insufficient introduction to provide context for the discussion.

I had hoped participants would bring examples of work-arounds or "painkillers" they had implemented in their own organizations, and that had become institutionalized, thus preventing them from removing the root cause problems that had led to the work-arounds in the first place. I had provided a few examples in the session proposal as well as on my blog to give people a sense of what I had in mind. It wasn't sufficient to set expectations for the session. To distinguish between a "good idea" and a "work-around," a person has to have a concept about heavy-to-light process improvement similar to what I introduced in my first session.

I learned that the majority of people who believe they are already practicing "agile" do not have a deep understanding of agile values and principles, and simply cannot judge how effective their current practices are. They can see that whatever they are doing today in the name of "agile" is working much better than whatever they were doing before, but they don't really understand why. They are simply following a defined process that was taught them by a consultant or that they read about in a book. They cannot tell whether anything they are doing on their projects is a work-around as opposed to a good practice; their assessment of any given practice is not based on whether it adds value or incurs overhead, but merely on whether it matches the defined process.

Rather than painkillers or work-arounds, participants described issues with agile implementation that are common in the early months of an organization's initial experiments with agile methods, when only a few people in the organization are interested in change, and the change agents have no past experience with the new methods. Most of their problems are organizational impediments, and not problems with agile methods as such. In describing their problems, participants did not explain how they had crafted a work-around to a specific problem, and how the work-around had become institutionalized. Instead, they simply stated a problem and waited for me to hand them a solution; and the problems were of massive scope. This sort of thing was far afield of the intent of the session.

I'm afraid these participants did not come away from the session with much useful information. I can say that I learned from them, though. I gained a clearer idea of how agile is being implemented in the industry, and how well-understood the concepts really are. Going back to the blue water analogy, I would say the water is very, very pale blue. Agile penetration is wide, but not deep.

Another informative angle for me was that a few participants believed (and still believe, I guess) that what they are currently doing in their organizations represents not just a "good" agile environment, but an exemplary one that requires no improvement at all. Usually, their descriptions of the current state in their organizations is horrifying.

In one case, a participant who holds a Ph.D. in agile methods described a nightmarish 1980s-style dysfunctional organization that uses a pseudo-RUP process in a heavily-siloed organizational structure, decorated with every sort of high-ceremony, high-overhead gates and checks and controls you can imagine. This in itself is not a problem, provided the current state is recognized as a problem and the change agents in the organization are working toward continuous improvement. In this case, if I take his description literally, then the organization settled into this mode of work some six years ago, and has not changed anything since. The most puzzling bit was that he seemed to be proud of it all. I must say I admire his perseverance, at least. In his place, I think I would have long since traded my laptop for a push-cart, and turned to selling popcorn on the street.

Since these were my sessions, I'll review the feedback I received, and how I intend to use the feedback. Feedback often falls into one of two patterns: Reviews are bunched in the middle, or reviews are bunched on each end (U-shaped reviews). Both these sessions garnered U-shaped reviews. For the round table, all the formal review forms that were submitted were strongly positive. However, about half the people who started the session decided not to return after the break. I take that as a negative review (they voted with their feet), although it does not offer me any information to improve the session in future. For the process smells session, the formal reviews included both very positive feedback and very negative feedback that included concrete recommendations for improvement, and nothing in the middle. Thanks to everyone who took the time to provide the latter. I think the process smells topic deserves more attention, and I will revise this presentation to include better contextual information.