Wednesday, April 27, 2011

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:

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

Wednesday, April 13, 2011

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

Tuesday, April 5, 2011

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 RiskAgile Practice
Addressing schedule and estimate risksManage to done, Velocity, Relative estimating, User stories
Addressing the risk of building the wrong thingDeliver early and often in small increments, Iteration demos
Addressing the risk of validating your architectureSteel thread, Iterative development
Identifying risks and issues as soon as possibleDaily stand-ups, Frequent retrospectives, Iterative Development, Manage to done
Addressing scope risksIterative development, User stories, User story slicing, Relative Estimating, User story mapping, Trim the tail
Addressing people risksPaired programming, Team ownership practices
Addressing quality risksTDD, 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.