mikkeman.nl

Last Thursday we had the last planning meeting of this year. In three weeks time, we will deliver the last release of 2009, ready to be put in production on January 1st, 2010 (this 6 week gap is something for another blog).

It feels kind of awkward, to be planning the final set of user stories. Is this really everything? Can we really miss all that other stuff on the product backlog? Everybody is quite confident that we produced good results.

Nonetheless there are some oddities. While things are being tested continuously, any issues uncovered normally entered the product backlog. In this last iteration, if an issue turns out to be more important than stories already planned, we (team + product owner) agreed to reprioritize during the sprint.

This also means that the team is now even more disciplined about how many user stories to develop concurrently, because we don’t want the PO to drop a user story we’ve just started working on.

But… as the number of user stories decreases and the PO is allowed to reprioritize all work that hasn’t started yet, we might as well say that we’re doing Kanban!

As I said in my previous post, “Kanban, Lean and Scrum Are Not Religions…”, it depends on your situation what tool suits you best. For almost a year, we used Scrum. For the end game, Kanban seems like a better tool. Just do what works.

Being a Product Owner (PO) is not the most easy role on a (Scrum) project. In fact, it might be the hardest role. POs are easily faced with months and months of requirements in the backlog. They are supposed to prioritize this huge list (“is requirement XYZ more or less important than requirement ABC?”), making sure that the needs of stakeholders are met.

And please make sure there is enough ROI, dear Product Owner!

And attend the daily scrum to clarify any issues the development team has within the current iteration!

And prepare the next set of requirements for planning.

And… And… And so on.

Jeff Patton wrote an excellent article about the assumption that the Product Owner must possess super powers: The product owner and the product-shaped hole. Unfortunately, most Product Owners do not possess super powers. I might even say that not a single PO has them (since they are still exclusively used in comics and the like).

This post deals with one of the challenges a PO has: how to prioritize my backlog?

When asked to prioritize every requirement on a scale of 1 to 3, the following usually happens:

• 80% will end up as priority 1
• 10-15% as a priority 2
• the rest (if any) is priority 3.

That is not very helpful to determine what requirement(s) to work on next.

A useful approach in this situation is to limit the number of requirements that are allowed in priority 1 and 2. For example:

• 10 requirements are allowed priority 1
• 20 requirements are allowed priority 2
• the rest is priority 3

All priority 1 requirements must be ready for immediate scheduling in the next planning meeting. Suppose that 8 requirements fit for the next iteration, then all you have to do is:

• promote 8 requirements from priority 2 to 1 and;
• promote another 8 requirements from priority 3 to 2.

That is just a minor task compared to the task “rank every requirement against all others”. When you put the priority 1/2/3 boards on the wall with brown paper and postits, it provides visual focus as to what to work on next as well as a transparent overview of “what’s next” and “what’s almost next”.

Try it, you might like it!

photo credit: criggle1

…but some people tend to treat them that way.

Lately, a lot of agilists are discussing differences, similarities and (in)compatibilities between Kanban, Lean and Scrum. Google is your friend here, search for “scrum vs kanban“, “scrum vs lean” and “lean vs kanban” to get you started. In this post I’ll add my opinion to the discussion.

Scrum is a very popular framework for managing the software development process. It has a small number of roles, artifacts and meetings, which makes it easy to grasp. Scrum gives you some guidance when starting out with an agile development process. It is based on multidisciplinary teams that are authorized to do whatever is necessary to deliver working software to their customer, working in short iterations to enable fast feedback and delivery, regularly inspecting and adapting their process for improvements.

More about Scrum can be read here, here and here.

Lean is a mindset. It is used for production environments (e.g. the Toyota Production System) as well as product development environments. Depending on who you ask or what you read, there are several principles you should adhere to. To quote Womack and Jones, these principles are:

• Identify value
• Map the value stream
• Create flow
• Establish pull
• Strive for perfection

The Poppendiecks have translated these principles to software development in their book “Lean Software Development” and added twenty-something tools you can use to create and support a lean software development process. Their book is recommended reading (if you haven’t already).

More on lean can be read here, here and here.

Kanban is very closely related to Lean. When people use the term Kanban, they mostly mean “kanban system”. A kanban is literally a “signal” that can be used to trigger activities in your value chain. In fact, a kanban is a tool to implement lean principles like flow and pull. Every piece of work needs to flow through all activities to create value for the customer. Kanbans are used to make sure that there is not too much work-in-progress and everybody in the value chain focuses on the work at hand. A kanban also points out bottlenecks in your value chain if a certain activity takes unusually long and redirects all efforts in the value chain to elevate the bottleneck.

More on Kanban can be read here and here.

To me, Lean and Kanban are synonymous with respect to software development. The Kanban movement promotes a lean process to deliver software. It lets you think about your value stream, gives you tools to make work flow and lets the customer pull that work. Combined with a regular reflection on process improvement, Kanban equals Lean.

Scrum and Lean are not synonymous. However, they do share common ground in their principles. Scrum has a strong focus on value creation (just as Lean), limits work-in-progress to a “sensible” amount each iteration, puts the customer in control (pull, which is controlled by Sprint Planning) and has regular process improvement meetings (Sprint Retrospective). They mostly differ in how they apply practices and tools to the situation at hand.

Scrum and Kanban are also not synonymous (which follows logically from the previous two paragraphs ). To me, the biggest difference is whether to use iterations or not. The Kanban movement eliminates the need for iterations, while Scrum makes extensive use of iterations.

The real question is of course not what differences, similarities and compatibilities exist, but what method/framework/mindset to use? The consultant answer here is, “it depends”. Every project, team or organisation has its own context where one or the other may be a better fit. There is no “single best answer”. Generally, I would advise Kanban in a context where priorities tend to change much quicker than the length of an iteration, while Scrum is a better fit if priorities are usually stable throughout the length of an iteration. And I would advise everybody to use lean principles in every problem at hand, no matter what tool you will use to solve it .