Exploring WIP limits

A few months back I was involved in a highly developer centric project (very unlike my current project). Non-developers were basically only involved and available upon request, so most of the time the team was not very cross-functional.

The team was using Scrum at the time, but the flow obviously had a few glitches and user stories had a tendency to pile in the test column, until very late in the sprint. A huge team effort at the end of the sprint made us finish most of the user stories just in time for demo, but the hurry was at the expense of quality.

It seems to me that most developers prefer starting on a new user story, rather than truly test and complete the ongoing user story. There’s really nothing strange about this, because often the fun part is gone as soon as the problem is solved. In the good old waterfall days, as a consequence to this “law of nature”, none of the features in an entire release might have been tested properly until very late in the project. Needless to say, this didn’t work out very well, and agile emerged to address these problems.

To fully complete ongoing tasks faster, we need to build in mechanisms in the process that enforces us to finish tasks before starting new ones. Iterations (sprints) do this by limiting the number of tasks we can have ongoing during a shorter period of time.

In our case, this didn’t do the trick alone. We shortened the sprints to only one week, and admittedly things got better, but the symptoms were still present. We decided to apply Kanban. First we put a WIP limit of 3 in the test column, later we added WIP limits to other columns as well, to be able to regulate the flow better. To improve the quality on the deliverables, we introduced a rule stating that the person testing a feature must be different from the person developing a feature.

In the beginning, the limits worked more as a guidance than actual rules – just to start changing the mindset from “push” to “pull”. After a while we paid more attention to the WIP limits, and lowered the limit in the test column even more (WIP = 2) to amplify the importance of finishing tasks. This turned out to be artificially low, but it was a great “pull” lesson for the team.

After a while the flow improved and the team effort was more evenly distributed over time. Initially, I thought we might have to “force” people into testing, but our board made it clear what had to be done, and the developers were eager to contribute wherever necessary (an indication of the power of visualization). As a bonus, the number problems we had earlier in the demos went down.

I should probably add that some of the developers took more than their fair share of testing. Over time that could have been an issue we might have had to deal with, but for the short period of time the project was ongoing, it didn’t turn into a problem.

Still, these small changes made a huge difference to us. We no longer had to rush into demos with poorly tested features, and the “boring” parts of process were no longer only at the end of a sprint.

A simple tip for more efficient standups

A while ago, I was asked for advice on how a team could improve efficiency on standup meetings. The team was growing, and their standups were taking an increasingly amount of time. I didn’t have much time looking into why this happened, so I simply suggested they could try walk the board instead of using the traditional Scrum meeting.

As it turned out, it didn’t have much effect. People on this team are usually responsible for one ticket (user story) each, so they all end up speaking anyway. I took a closer look, and realized their great team spirit might be of the reasons why their standups takes too much time. They like working together, there are many outgoing personalities, and they like solving issues directly in standups. In addition to sharing information and solving problems right away, the standup meetings function as a social meeting place.

This is all fine with me, actually I would even encourage it, as long as the discussions are relevant for most people, and they finish up within 15 minutes. As soon as the team grows, however, not all discussions are relevant for everyone. So, the question is, how to improve the efficiency without killing creativity and good team spirit?

In similar situations, we have had to establish some ground rules to add some discipline and structure in the standup meeting. One way of doing this is by establishing a “parking lot” next to the board.

Whenever a discussion starts, we take a collective responsibility to end it gracefully and note the topic down in the “parking lot”, so that the discussion can continue after the standup meeting. Putting names of whom should participate in each discussion, can help determine the most efficient order of dealing with the topics afterwards. Here’s an example:

This usually works quite well. It helps us focus on the meaning of standups, which is sharing status and relevant information – and it shortens them down. You should try to identify problems in the standup meetings, but you don’t need to solve them all right away. To make this work, you need to add some amount of disciplin, but only with rules the team have agreed upon.

If the team is involved in creating the rules, then you have made the first step building a collective responsibility within the team. I believe there’s subtle, but important, difference by how individuals interpret “ending a discussion” vs. “postponing a discussion and create a new arena for discussing the topic”. We don’t want strict rules to get in the way of good team spirit, do we?

Please share your tips for efficient standups!

Kanban and Scrum after 500 tweets

I joined Twitter June 22, 2010, so, needless to say, I was not an early adaptor. Nevertheless, I just passed 500 tweets, and most of my tweets are somehow related to agile development, so did I come across something useful? The answer is yes, and I believe it’s an appropriate time to reflect – focusing on Kanban and Scrum this time.

During this period I’ve learned to enjoy Lean thinking, and Kanban in particular. The difference, you may ask? David Anderson puts it well:
“People ask me what is the diff between Lean & Kanban? Answer: Lean is a destination, Kanban is a means to get there.”

If you don’t know Kanban, here is a clean and to the point overview:
http://reaktor.fi/en/our_expertise/kanban/

And here is a first hand experience on what you can expect if you introduce it:
http://www.agilecoach.ca/2011/07/07/kanban-reboot-pt1

It’s not always easy to map a process to the Kanban board, so you might need some tips when you are stuck: http://blog.brodzinski.com/2011/08/map-process-to-kanban-board.html

After a while, you will know that keeping an inventory is not free of charge, and there might be an upside if you manage to keep it down:
”In 1987, while GM held 2 weeks of parts in inventory, Toyota held 2 hours.” (Jeremy Lightsmith)

By then you should know that you need to pull work items, not push them. This strategy, if you see the analogy, might even affect your leadership:
“Management is push, leadership is pull.” (Jim Benson)
…and what’s really the difference between a project leader and a project manager?
http://www.projectsmart.co.uk/project-leader-or-project-manager.html

Kanban takes an evolutionary approach, so big changes won’t happen overnight, but you should still be prepared for resistance in the organization. Here are 5 arguments against Kanban – and how to respond to them:
http://noostvog.wordpress.com/2011/06/29/5-arguments-against-kanban/

Even though I find Kanban very appealing, I still like Scrum. Recently, Scrum even got a major update to the Scrum guide! I found it really interesting that they now had removed release planning, cause it might compensate for poor development practices:
http://www.scrum.org/scrum-guide-updates
This doesn’t mean you have to stop all release planning, it’s just not mandatory anymore, and you should use it with care. This is an example of one small step you can take to improve the quality.

And quality, that’s what you need to focus on, no matter what agile process you are using. If you shorten down the feedback cycles, that would help you on the way. To get fast feedback, there’s a number of things you might consider:
…shorten the iterations:
http://www.itjoblog.co.uk/2011/06/the-iteration-is-too-long.html
…keep the releases small and deploy to production often.
http://kenschwaber.wordpress.com/2011/03/23/major-releases-are-a-failure/
…but maybe not 50 times per day?
http://www.thehackerchickblog.com/2011/02/continuous-deployment-for-continuous-learning.html

If you want to go fast, you need to move with a sustainable pace. You need to stay clean so you can keep going fast:
http://www.scrumalliance.org/articles/300-the-land-that-scrum-forgot

So, to be able to shorten the feedback cycles, you need to focus on getting working software at the end of each sprint. And if you don’t, you’re definitely not alone. Over 50% of Scrum teams can’t get shippable code at the end of each sprint. Research shows that this will slow you down between 2 and 24 times:
http://scrum.jeffsutherland.com/2011/01/optimized-scrum-getting-to-done-done.html

There are many topics I didn’t cover this time, so maybe there is room for another post?