Perfecting your process

“Eliminating delays between what you do gives you a better return than getting better at what you do.” - Alan Shalloway (Dec 2, 2010, twitter).

I was recently introduced to the ball point game as a way to introduce agile concepts. A colleague of mine had decided to try it out for a larger group so I volunteered one of our teams in order to ‘test drive’ the game and the facilitation of that game.

The game itself is pretty straightforward. If you want to read about it, check out Declan’s link above or one of the many other sites describing the game. One of the objectives of the game is to show how teams can dramatically improve their process just by stopping, reflecting, and re-planning.

This particular team improved from a velocity of 28 to 57 in four iterations (see the image). However, if you read about this game from other sources, this kind of improvement is ok, but not great. The team focused their iteration planning efforts on perfecting their style rather than changing their process. They did discuss some alternative processes but ultimately rejected them and decided together that their best course of action was to perfect their current method.

To make matters worse, as facilitators we were terrible project managers as we told them stories of great improvements by other teams (“I bet you can get to 150, I’ve seen other teams do it”) but all this did was make them frustrated as they continued to try and perfect their process with only small gains. Plus, even though they doubled their efficiency in a short period of time, they were frustrated that they couldn’t go faster and started to slow down at the end of iteration 4. They suggested that if an iteration 5 would have been held, they would only have gone slower as the realization sunk in that they would not be able to achieve 150.

The exercise up until this point did not achieve what we had hoped for. We had hoped that they would find huge jumps in productivity each iteration and that they would get more and more excited each iteration. Instead, they only achieved modest gains and got more frustrated each iteration. So, what did we learn from this?

1. As the quote above says, it confirmed that focusing on improving and perfecting your current process is only going to give you modest gains. Practice doesn’t make perfect if your process is flawed. Continually practicing a bad process isn’t going to result in the benefits you are looking for and will likely slow your teams down over time as apathy builds. We need to give teams the lean tools and techniques to help them find their delays. One of the ‘tricks’ to this game is to reduce or eliminate your delays instead of perfecting your throws.

2. We need to give teams enough time to not only re-plan the next iteration, but to ask them to reflect upon and challenge both their process and their assumed constraints.

3. Teams who are pushed to achieve incredible productivity gains by well meaning leaders under the guise of empowerment or encouragement may see short term gains, but in the long term those teams will likely be negatively affected - especially if the teams haven't been given the tools and techniques to achieve those gains.

The team we tried this with did not at first come away with tools that they could use to improve their current project. In fact, we may have scarred them forever ;) We are trying this game again in a few weeks with a different group and we’ve made some changes with the hope of enabling the teams to see the ‘ahah’ moment before the end of the game. I’ll keep you posted.

Agile Retrospectives - a Rising Patton Fusion

The last session of Agile Vancouver 2010 was a unique opportunity to watch Linda Rising conduct a conference retrospective with the Agile Vancouver organizers. It was interesting to watch how she facilitated and I wrote down some of her techniques so that I could try them out. The following day during the tutorials Jeff Patton led us through a mini retrospective with his own interesting twists based on his story mapping experience. What follows is the fusion of their ideas.

Note: This retrospective works nicely using index cards that can easily be sorted and grouped around a common table. If you are using walls and stickies, you can adapt where required.

Step 1 - Set the tone:
Recite Norm Kerth's Prime Directive (Linda was able to recite this by memory):

"Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand."

After reciting, ask each team member one by one if they agree to uphold this statement during the meeting and to avoid blame. A simple verbal "yes" indicates agreement. The verbal agreement is a simple influencing strategy or pattern that helps set the tone for the retrospective.

Step 2 - Framing the Retrospective:
The facilitator tells a story of a co-worker meeting you in the hallway of your company. The co-worker asks: "I know you were on project [X], how was that?". Each person responds with "It was great because...". Instead of speaking the answers out loud, give each person 3 index cards and have them write their answers down in silence. This allows input from each person regardless of personality type and keeps your team member's answers from influencing your own.

When each person has filled out their 3 cards, they read each one out loud and place them on the table. Once all cards are on the table, ask the group to silently group the answers together. Cards that are similar should be close to one another and cards that are different should be farther apart. According to Patton, the simple reason for doing this in silence is because it allows the work to happen quickly and without much discussion. In our exercise, we found this to be true.

Now that the good things are grouped together, take a different coloured index card and have the group summarize each grouping with a new card. For example, summarizing items like "team worked well together", "Bob collaborated to help me with my task", "Team rallied to complete the stories together" might be summarized with a card called "Great team work".

Step 3 - Do Differently:
Now that we have acknowledged the good things about the last period, remind the team that it is only a perfect project if they would do that project or iteration again in exactly the same way. In reality there is always something we would do differently. Ask the team to silently fill out 3 more index cards with what they would do differently. They may not write cards that associate blame, describe what wrong, or try to problem solve. In this part of the retrospective we are only identifying what we would do differently.

Once everyone has completed their cards, we again read them aloud as we place them on the table, group the cards in silence, and summarize with a different coloured index card. As the cards are read or summarized, the facilitator may need to remind the team to refrain from problem solving or directing blame.

Step 4 - Voting:
The next step is for the team to agree on which items on the "Do Differently" list are the most important. To keep the voting impartial and independent, have each team member write their top 3 items on an index card and hand the cards to the facilitator. The facilitator then tallies the votes and records the totals on the summarized cards. An alternative is to use dot voting, but I've found that dot voting can be 'gamed' too easily and that initial dots influence those who vote later (group think).

Step 5 - Experiments:
Using the top 1 or 2 voted items, ask the group to split into groups to discuss them - 1 group per item. Instruct the groups to discuss small experiments or tweaks that the team could try in the next iteration. If you practice frequent retrospectives, this discussion does not need to be about problem solving or even root cause analysis. The goal is to quickly agree on small experiments to try to resolve the issue you are discussing. For those dedicated to root cause analysis this may be a problem, but give it a try and do what works for your team while avoiding blame or delving deep into problem solving. This part should be time boxed to 10 or 15 minutes maximum.

After deciding on the experiments, have one person from each group present the idea to the group. This idea needs to be included in the backlog for the iteration and the team (not an individual) commits to completing the experiment during the iteration and examining the results.

Step 0 - Review Experiments:
At the beginning of the next retrospective, add a new step at the beginning to discuss your experiments to see how effective they were and use this information as input into future experiments.

Other notes:
If you are doing a retrospective for a larger period of time, then consider starting the retrospective by building a timeline of events. For more info, check out this blog: http://www.thekua.com/rant/2006/03/a-retrospective-timeline/

Thanks Linda and Jeff for sharing your methods and ideas.

What is your top 1 agile tip? @AgileVancouver

The agile Vancouver conference wrapped up yesterday - a great Canadian conference if you are wondering where to spend your training budget in 2011. On Wednesday morning we held an open space similar to the agile panel at SDEC. We opened the floor for questions, ranked them, and then spent 10 minutes on each topic. Since the open space was largely filled with speakers and experienced agilists, I asked this question: "What is your top 1 agile tip". Here are our responses with twitter usernames where applicable:

@lucisferre - "Working towards continuous delivery"
@dbelcham - "Be agile w/ agile practices. Adopt what works"
@mikeeedwards - "One step at a time. Find small wins"
unknown - "Adopt pair programming"
Angel from Spain - "Make the change come from them - get them to see the problem and come up with the improvement"
@Ang3lFir3 - "Can't do it without the right people. One bad egg spoils the whole bunch. Get the right people on the bus"
@dwhelan - "Find the bottlneck in your value flow and cut it in half"
@srogalsky - "Uncover better ways. Never stop learning. You are never finished being agile"
@mfeathers - "Don't forget about the code or it will bury you. It will $%#ing bury you"
@robertreppel - "Recognize your knowledge gaps and bring in help if you need it"
@jediwhale - "Pull the caps lock key off your keyboard"

Next time I'm in a panel, the question will be: "I love agile because..." Feel free to comment with your answers.

Why is collective team ownership and commitment better than individual ownership and commitment?

Recently I've been pondering collective vs. individual ownership and commitment, the theories behind it, and how to respond to someone who many not have considered why collective ownership and commitment is important. If you are involved on a team that is assigning responsibility to individuals, you could respond in several ways. My own impulse may be to respond either with frustration or to smile, nod and wink to my more agile-aligned team members. However, I have never found these types of responses to be very productive ;). You could also respond by informing the team that the agile community is full of luminaries who tell us that individual responsibility is not compatible with good results over the long term. However, as you can imagine, it also won't be an effective strategy just to tell your team that Johanna, Brian, Bob, Esther, James, Jeff, Mary, (etc) and you don't think this is an effective way to manage the work. Instead, I suggest that you a attempt a face to face discussion on the pros and cons of assigning the work to the team vs. the individual. Here are a few things you might use in your discussion.

Team ownership reduces the risk of having or creating one 'smart person in the room' (i.e. bottleneck) who does all the work. Even though Jim may be the best person to complete the job, if Tim and Jane work on it together with Jim it will take a little longer initially to complete the task, but those gains will be realized over the long term as the whole team becomes better at accomplishing each task and filling each role. While a cross functional team isn't always easily or immediately created, eventually that team can function effectively to complete any task even if one or more team members are missing.

Collective ownership should result in less items that are in progress. Work in progress tasks have zero realized value to the organization's goals. If we commit to and own items as a team, we should work hard to get them done one at a time so that we can realize the value of those items sooner. Rather than 5 people completing 5 tasks individually that are finished together at the end of the month, task 1 is finished and creating value at the end of week 1, task 2 at the end of week 2, etc.

Quality has a better chance of being built in from the beginning when a team owns and takes responsibility of a task together. As the team works together on a backlog item, we will collectively discover our 'quality blind spots' earlier in the process and adjust accordingly. When I work on an item myself and then present it to the team for review after I'm finished, there will be more re-work required to incorporate the ideas of my team members in order to mark the item as done. It is critical to get feedback early and often in order to 'fail fast' and improve quality. Teamwork is an effective way to accomplish this.

Finally, collective team ownership promotes... teamwork. Individual accountability and responsibility tend to generate selfish behaviour (I'm working on my task that I'll be measured on so I can't help you with yours). Team accountability and responsibility builds a stronger team because if any one task is sub par it reflects on the whole team and not on an individual.

Of course, this doesn't work very well if we don't sit together - which is why we do.

My top 12 agile podcast episodes

When I mentioned at SDEC10 that much of what I know about agile I learned from podcasts, several people expressed interest in my favourites.  Here are my top 12 (now 13) podcast episodes in random order:

1. Hanselminutes 119. What is Done? A conversation with Scrum co-creator Ken Schwaber. An excellent conversation that answered some of my initial questions about Agile like - how do logging, security and other infrastructure tasks fit in the back log, and of course - what is done?

2. AgileToolkit - Allistair Cockburn interview at Agile2006. Allistair talks about his evolution as a Methodologist from a hardware guy, the Crystal family of agile methodologies, his writing and much more.   Crystal recognizes that one agile methodology cannot be used in all companies and tries to identify the core principles and practices that are important for all agile projects.

3. Hanselminutes 145. An overview of the SOLID principles with Robert C. Martin ("Uncle Bob").  Excellent overview with examples.

4. LeanAgileTalk 20070118. Part 1 of a great conversation with Alan Shalloway on how to apply lean principles to agile development.  A good start on how to implement practices - the 'how'.  Some excellent sound bites in here.

5. AgileToolkit - Uncle Bob interview at Agile2005. A brief discussion with Bob Martin on the essential principles of Agile

6. Hanselminutes 23. A short introduction to scrum.

7. Hanselminutes 31.  A good introduction on Test Driven Development and the benefits.  Includes discussion of the pros/cons.

8. AgileToolkit - APLN Panel discussion. Long (2 hours), but good.  Here are some of the highlights:
- Worst agile transition failures? - What is required for transition? Leadership, don't do partial agile, must integrate testers on the team, need to form teams that work effectively together - Self organizing teams - is this possible? The original XP team was full of architects, but our teams may not be - how can we do this? The original backlash against architecture was that architects were responsible to standards, not to the business problem. Also - it is important to move our experts out of the corner office and off the pedestal and on to the teams as active members producing code. - Level of up front architecture required? Depends on problem/project. With a new domain, or a junior team, more architecture guidance is required. With a known domain and an experienced team, less architecture guidance is required. - Is requirements a dirty word? No - signoff is the dirty word. Requirements are good - but waiting months before implementing is not, not accepting change is not. Don't penalize people from finding errors, omissions, changes at any step. - How to do fixed price projects? One suggestion - share the risk (i.e. cost) for the first 6-8 weeks (2 or 3 iterations) to measure your velocity and gain trust. Then if client is happy, you have enough info to fix the price, and you get your "risk" back. - Why is fixed bad? You give them what they asked for, rather than what they need.  Never used + rarely used features = 64% of the code (Standish report)

9. AgileToolkit - Uncle Bob explains the agile manifesto. Robert "Uncle Bob" Martin answers the
question of "What is Agile?" He goes back to the start, to the Snowbird meeting, the formation of the Agile Alliance and the drafting of the Agile Manifesto. He also looks at the core principles and key practices of Agile software development.

10. Agile Toolkit - Poppendiecks at Agile 2006. Tom and Mary discuss several topics including:
- optimize the whole, not the pieces - don't neglect one of the pillars of lean: respect people - queueing theory.  Examples a defect list is a queue that should not exist.  We should be mistake free after each step.  Don't build on top of bad software.  Also, this helps eliminate interim artifacts like 'test strategy document'. - testing phase - this is testing too late - relating lean to cooking by a master chef
- describing how clothing store Zara implemented lean (very interesting)

11. IT Conversations - Ken Schwaber. Ken talks through many of reasons why agile SW development is such a necessary change in the industry.

12. Hanselminutes 169 - TDD with Roy Osherove. Roy Osherove educates Scott on best practices in Unit Testing techniques and the Art of Unit Testing.

13. DotNetRocks show 750 - While at Prairie Dev Con in Calgary, Carl and Richard chatted with Steve Rogalsky about User Story Mapping. Steve explains how User Story Mapping helps to visual your backlog beyond a serial list of features to allow you to improve your project decisions, priorities, plans, and delivery. (Sorry - had to add this one ;)

Hope you enjoy them. Let me know if you have other favourites - I'd love to listen to them.