Kanban Boards - What Restaurants and Agile Projects Have in Common

I recently finished reading the book "Influencer: The Power to Change Anything." Among other things, the book describes several influence strategies and one of them is to use physical things to promote the desired behaviour. To illustrate their point they provided a simple example that I'll summarize in the next paragraph before drawing similarities to how a kanban system can influence good behaviours for your team.

The 1940s saw an increase in people eating out at restaurants after the end of the war and a surge in growth and prosperity. During this time restaurants struggled to keep up with the demand and tension grew between wait staff and cooks. Orders were late or confused and customers were annoyed. Dr. William Foote Whyte was invited to help. His solution was to install a simple 50 cent order spindle - a basic kanban system that later evolved into the order wheel. Wait staff wrote their detailed orders on paper that were skewered onto the spindle and the cooks would fulfill the orders generally in a first in first out sequence. This simple system worked wonders and still exists today. Cook staff could clearly understand the priorities and requirements for the meals while still being allowed some flexibility to make the meals in an efficient order. Wait staff could detail the order expectations and gain a better understanding of when meals would be completed. For more of the story, you'll need to read the book (Influencer, pages 220-222).

If your organization is experiencing similar issues and frustrations between your customers and your IT staff, then implementing a simple kanban system like the spindle could be a first step to improving your results, communication and behaviour. If your requests are sized appropriately (think meals for individuals vs. meals for everyone in the restaurant), then your customers can decide which stories are important enough to put on the kanban board and put them on in the order they would like them completed. Use index cards or stickies with detailed instructions on them (acceptance tests) as a way of keeping the requests small. Keep the board small enough so that only a limited amount of requests can fit. As one request moves off the board, the customer gets to add another. Measure the average time it takes for a request to enter and exit the board so that your customers can understand how long it will take to complete an average request. Making this process visible in a physical and tangible way can help encourage communication and cooperation between your customers and your IT staff.

For another view of a simple kanban board and how it works, check out Henrik Kniberg's cartoon here: http://blog.crisp.se/henrikkniberg/2009/06/26/1246053060000.html

If you are already doing some agile development but have not yet experimented with kanban, consider using a kanban board within each iteration. Our team had discussions today for how we are going to set up our iteration kanban board for a new project and here is the draft plan with 5 columns left to right:

• Iteration Backlog (limited to the points we think we can achieve in this iteration)
• WIP - Tests Defined (limit of 3)
• WIP - In development (limit of 5)
• WIP - Testing (limit of 3)
• Done (limited to the number of stories we can actually complete in an iteration)

This simple board helps improve communication and expectations between team members and stakeholders. It also encourages behaviours that we value - blurring of specializations, team cooperation, team ownership, and getting things to 'done'. Enforced wip limits will inevitably mean that developers will need to help testers/analysts and vice versa, and that one story has to move to done before a new story can begin. Also, a board that visualizes your process can increase ownership of the process and the results. I expect the columns and wip limits to change as we use our board but we find this mix of scrum and kanban to be valuable.

Want to receive future blog posts in your inbox? Enter your email address here. 

The debate about agile estimating

There has been a lot of noise recently about eliminating estimating for software development projects. I'd like to thank Terry Bunio for putting out his thoughts as a rebuttal here. (Note - Terry sits right beside me so we've had a lot of discussion on this topic recently - especially since we thought someone was wrong on the internet #gasp)

To summarize my understanding of the issue:

• Estimating is a waste because we are going to be wrong anways.
• Estimating is a waste because we could be delivering value instead.

While these two statements have caused a lot of debate, there is a ring of truth in both of them. So, if we are going to do some form of estimating, can it a) help us be more truthful about our estimates and b) increase our ability to deliver value? This is the beauty of relative estimating through planning poker - and here is my main point, bolded and centered for emphasis:

Planning Poker is not just an estimating exercise.

Yes, one of the main outputs of planning poker are points estimates. But it has other results that address the concerns above.

a) It allows us to be more truthful about our estimates:

• Relative estimates in concert with user stories and managing to done enable you to track the velocity of your project so you can predict actuals sooner (i.e. tell the truth about your estimates as soon as possible). In turn, this allows us to make better choices about the future of the project (like helping the marketers decide when to launch a campaign about the project), and measure the results of our continuous improvement experiments.

b) It increases our ability to deliver value:

• Planning Poker is also a scope discovery tool (see my thoughts here). After a planning poker session our team will have a much better understanding of what the client wants and expects - therefore enabling us to deliver it to them sooner and with less misunderstanding and frustration.
• Planning Poker creates team ownership of your estimates - including joint ownership with the client.
• Planning Poker allows your client and users to have a much better understanding of what it takes to build what they are asking for and informs their choices when prioritizing.

In closing, so far all of our clients have required us to create estimates and we'll continue to do that. But, we like to start with points through planning poker because of the value added as above and then take a few stories and extrapolate to hours. After that, we ignore the hours and focus on velocity. This feels like a balanced and professional approach.

**************

Some additional reading on this issue if you choose. The last one contains some ideas that I strongly disagree with and that Terry responded to in the post above (despite his affection for TargetProcess in general).

• http://blog.mountaingoatsoftware.com/how-do-story-points-relate-to-hours
• http://the-tread-way.blogspot.com/2011/04/how-many-hours-are-in-story-point.html
• http://www.sdtimes.com/link/35401
• http://www.targetprocess.com/blog/2011/04/5-reasons-why-you-should-stop-estimating-user-stories.html

Agile as a risk mitigation technique

When I first started using and investigating agile principles and practices, I didn't immediately realize how well these techniques worked in order to reduce project risk. As I talk with others about adopting agile, many fear the 'risk' of moving to agile techniques. Here are a few thoughts on how agile practices reduce risk on your projects (I'm sure I've missed a few):

Project Risk	Agile Practice
Addressing schedule and estimate risks	Manage to done, Velocity, Relative estimating, User stories
Addressing the risk of building the wrong thing	Deliver early and often in small increments, Iteration demos
Addressing the risk of validating your architecture	Steel thread, Iterative development
Identifying risks and issues as soon as possible	Daily stand-ups, Frequent retrospectives, Iterative Development, Manage to done
Addressing scope risks	Iterative development, User stories, User story slicing, Relative Estimating, User story mapping, Trim the tail
Addressing people risks	Paired programming, Team ownership practices
Addressing quality risks	TDD, BDD, ATDD

This list doesn't address the risks that accompany any change initiative, but it does underline that many agile techniques are directly targetted at averting project risk. Agile practices help us shorten the distance between guessing (planning, designing, estimating, etc) and knowing.

See also - Chris Matts wrote about this topic recently and gave some nice examples of how he talked about risk during a methodology audit.

http://theitriskmanager.wordpress.com/2011/12/12/the-language-of-risk/

Team Ownership through the UX Design Studio Approach

A few weeks ago I was added to a new team that had already spent some time working on the technical challenges for the project but had yet to do much UX work. One of the first things the team asked me to help with was to create the User Interface design. I think what they expected was for me to ask some probing questions, go draw some pretty pictures in Visio or some other tool and then present (and dictate) the results. I've certainly taken this approach on previous projects. However, in this case I went to my agile improvement backlog and decided to try the Design Studio approach I had learned at Agile 2010 in a session by Todd Zaki Warfel.

The Design Studio approach is a team approach to UX design. When I first asked the team if they would consider doing the UX design as a team, they were surprised and delighted to be asked (cool!). I had high hopes for this approach because I was excited to see the results of using the collective imagination of the team to create a cohesive and well thought out design. Before I share the results, here are the details of this technique:

Prerequisites: You should have already created your initial backlog of user stories. Creating other artifacts like personas and user scenarios first would also be useful. In our case we had the stories and some scenarios, but no personas yet. You will also need to print out several 8up sheets like the one in the image below and bring along several pencils. You can download the 8Up here or create your own in Excel. 

Steps:

1. Gather team members for the exercise. Not everyone needs to participate, but you should have willing participants from each role including developers and client.
2. Decide on a focus for your UX design. This could be a specific release, user scenario, or some grouping of user stories.
3. Hand out 8up papers and pencils to everyone on the team.
4. Ask everyone to create 6-8 sketches of the different pages/screens in the app (see tips below).
5. Once you start, tell them they only have 5 minutes to complete their 6-8 sketches.
   • You could tell them this before, but it seems to help crystalize their thoughts when they hear this.
6. After 5 minutes, review each set of drawings:
   • Each person has 3 minutes to pitch their drawings to the team.
   • The team then has 2 minutes to identify 3 things that worked and 2 things to change.
7. Repeat steps 3-6 until the team reaches a consensus on the design.
8. Once your design is complete, keep the final sheets as your UI reference model.
   • You won't likely need to transfer this to Visio or any other tool. The model should contain enough information and brief notes so that you can develop straight from the paper and make final adjustments in your development tool while having a conversation.

Some tips:

• Gloss over details in your drawings. You need just enough detail to communicate your design.
• Aim for quantity not quality.
• When doing this for the first time, don't tell your team they only have five minutes until after they start.
• Do steal ideas from each other.
• As always, include your client in these sessions.

Results

Four of us met in a conference room to try out this new approach. For a user scenario that included about 10 stories, we executed three rounds. As a team, we were very pleased with the results and how quickly the final design emerged. Despite starting with very different ideas, we discovered that by the third round our drawings were nearly identical and represented the best work of the team. Using this approach helped generate ideas none of us would have thought of individually and resulted in team ownership of the design. We also found that we identified a few new 'excitement' user stories to add to and enhance our existing backlog. Additionally, as we walked through each other's drawings we discovered one or two basic stories that we had missed while generating our initial backlog. Time will tell if the resulting UX design will be successful, but as a whole the team is confident in both the approach and the result.

In summary, this approach was fast, promoted team ownership, and produced a great result. You can learn more about the Design Studio approach here: http://unify.eightshapes.com/page-pattern/sketching-design-studio-page-patterns/

I thought the success of this team approach was appropriate to write about on a day where this quote was found in @ThisIsSethsBlog - "I'm not going to believe that only a few people are permitted to be gatekeepers or creators or generous leaders". Indeed.

Update April 1, 2011: I introduced this approach to a larger group of my fellow employees this week. Someone asked "why we should continue with round 2, 3 etc - why not just have the group consolidate the good ideas and produce one design together after round 1?" 

My answer: If you consolidate your ideas after round one then you are risking two things: 1) That the 'loud' voices will be the one driving the ideas and design. The practice of having everyone re-drawing the design allows each person's ideas to be incorporated. 2) As you repeat the process of re-drawing your design, the ideas from your team members will seep into your ideas and birth new ones. If you consolidate your design too early, you risk losing those new ideas that can only form in the act of putting your ideas down with paper and pencil.

Agile Winnipeg Inaugural Event - "Shorten the Distance"

It was pretty exciting for myself and the other organizers to see a packed room of over 60 people attend the first Winnipeg Agile User Group event on Thursday, March 10, 2011. After a quick meal from Homers and some furniture re-organization, we kicked off the event with a word from several of our sponsors. Wadood Ibrahim spoke on behalf of Protegra and recalled giving a presentation to the local PMI group 10 years ago about agile techniques that was not well received and was delighted by the turnaround of opinions and interest 10 years later.

For the main presentation, Doug Kok and I split the attendees into groups of about 15 people and led them through the ball point game. The ball point game is a simple and fun exercise that allows teams to think about process * people through team decision making and the power of reducing hand-offs. Here are a few images from the event:

Team 1 Discussing their strategy



The scores of the game. Notice the significant improvements from most teams. Team 3 forgot to count during the last iteration, but based upon the process they were using, I think they would have surpassed their estimate of 160



And, thanks to Doug - here is a brief video summary of the teams playing the game: 


So how does the ball point game relate to agile? In both the ball point game and in software development, improvements in speed can be gained in similar ways:

• Focus on reducing hand-offs by having face-to-face conversations, dedicated teams, shortening the distance between a requirement and its implementation, a question and its answer, etc.
• Stop frequently to determine how to go faster.
• Measure your experiments through velocity and frequent feedback.
• Value and encourage cross-functional, de-centralized, self-organizing teams.

Homework: To take this further, read the 12 principles in the Agile Manifesto and think about how each of the 12 could be re-stated as a way to reduce handoffs, or as shortening the distance between [A] and [B]. Also, to see how these ideas can work in the 'wild', read this case study on facebook.

To close the event, we held a short open Q&A session. Some of the questions we discussed were:
 1. Can you do agile without TDD (Test Driven Development)
 2. When/how do you do requirements?
 3. How do you control scope creep when you aren't defining the requirements up front?
Lively discussion continued over drinks at Triple Bs on Scurfield.

Based on the survey responses, the top 3 categories for future event topics were Agile Testing, Agile Adoption, and Agile Estimating.

Finally, on behalf of the organizers I would like to thank you for participating and thank the sponsors for allowing this event to occur. To register for future event notification, please click here.