Starting with Kanban Q&A

OK, I admit it. I have played on the Dark Side, and can confirm they have some damned good cookies. Yes, I introduced kanban to the Scrum process being used by my customer.....

I know there are many people interested in this technique, so here are some key questions (and answers!) that you will come across during rollout. It's not exhaustive, but hopefully it will provide a practical starting point from which you can experiment. I have assumed some knowledge of what kanban is - limited work in progress, not timeboxed etc etc.

Firstly, some background. The project I was coaching consisted of three cooperating but independent teams consisting of 4-6 devs and 1 QA. There is just one Business Analyst acting as Customer for the project - Product Owner by proxy. The project used fairly standard Scrum techniques to manage progress - stories on cards, on a board, estimated using planning poker. The board consisted of swim lanes Not Started, In Progress, QA and Done. Standard stuff.

However they were suffering from problems associated with the abstract nature of story points - are they really days or fluffy bunnies? And how many Gummi Bears make a Mars Bar? So I was looking for a way to simplify planning further but without losing the ability to plan ahead.

So what happened when we rolled out a kanban system into the first team and limited their work in progress? They had to address certain key questions:


Q. "How many columns should we have?"

A. The first team initially stuck with the old trusty "Not Started, In Dev, QA, Done" pattern. But they put a work in progress (WIP) limit across both In Dev and QA columns. Later teams simply didn't bother differentiating, and simply have an "In Progress" column, forcing developers to actually talk to QAs when a card is finished (a radical idea at the time!).


Q. "What are our WIP limits?"

A. There was some interesting discussion around this, especially since all the teams were starting to actively encourage pair programming. They quickly realised that the WIP limit can be used to enforce pairing, but also allow a degree of solo development.

Remembering we have a team of 6 developers, initially they went for 3 in the 'Not Started' and 4 for 'In Dev/QA'. Considering the latter first, a limit of 4 allows 2 developers to work independently without pairing, the rest are forced to pair up.

The team quickly found that the 3 card 'Not Started' WIP limit was too small. It was running out too quickly, and it did not allow enough focus on what comes next (eg stories that naturally group together). It currently stands at 6, which definitely seems to be better without changing the cycle time too much.

The team is operating with no slack in their In Dev/QA queue. It's always full. This appears to be working so far, but there have been no "urgent, do now" stories yet.


Q. "How do we stop blowing our WIP limit?"

A. A problem quickly arose from the particular flavour of storycard discipline I teach. I ask people to start with a simple story, and write decisions and agreed requirements on the back to capture them as they are discovered - hence it's often useful to take it with you when working on the card. An avatar is used as the placeholder on the board to show what's missing.

It quickly became apparent that stories were being sucked into empty WIP spaces because the card was on someone's desk, even though an avatar was there; the WIP space wasn't "real". This meant the agreed WIP limit was being exceeded. This was the case even though the team only had enough magnets for the limit (magnets stay on the board, but were being reused).

They solved this initially by having 'placeholder' cards - generic cards that were swapped with real story cards. This carried on until the team had the discipline to only pull in cards when the magnets were in an "available" area on the board. (Photos to follow!)


Q. "How do we track our cycle time?"

A. Cycle time is the time from a story being pulled out of the backlog to be done to actually reaching "Done" - a critical measurement for planning. The solution for tracking this was elegantly simple - the Customer has a date stamp. When a card gets pulled in to 'Not Started', it gets stamped. When the Customer sees the story has been finished to his satisfaction, it gets stamped. No-one else is allowed to use the stamp, so the Customer has to see the story demonstrated. Simple.

Q. "I can't line up cards that follow a natural order"

A. This was a Big Issue for some of the team. Limiting the incoming work had an interesting effect - it forced people to talk to each other more! Especially the developer-customer conversations. Rigidly limiting the number of cards in 'Not Started' encouraged the Customer and Developers to work out what really needed to be there. An unexpected but valuable effect.


Q. "What about blocked stories?"

A. Many of the stories in the project are dependent on 3rd party software. So if that software is not working, the story cannot progress to "Done". It is blocked. There is no point in a blocked story blocking a WIP slot, so the team introduced the idea of a "Sin Bin" - stories that are blocked beyond the team's control. Stories in the Bin are monitored for progress, and when they become unblocked they are re-added to the backlog for prioritisation as normal. The Sin Bin also provided a useful visual indication of just how much work was being blocked by the 3rd party.

Q. "How do we show burndown/progress?"

A. This is the one issue that I am not yet happy with. How to estimate a finish date for a given amount of work.

On the one hand, there is the cycle time. No problem there. A story card start-to-finish is taking 3 days or so. But the problem is the extensive backlog. There is no guarantee that the stories are correctly sized, so either the team needs to go through every single story to make sure it is roughly the right size (or is an 'epic' equivalent to 2, or 3, or however many real stories), or to increase the size of a story to a "Minimum Marketable Feature" and track those.

I admit I don't like the idea of MMFs - in this context they would be too big a slice through the system and remove the benefits of iterative development. Currently the teams are taking the first approach - estimating epics as stories.

Another issue around planning is the external business. Like many companies, they are addicted to Gantt charts and are nervous about not having a definite statement that "this story will take x days". Story points and burndown graphs showing the real situation were not always well received because they didn't fit the "plan". Switching to counting cards is having similar problems, and is seen by many as an oversimplification.


Q. "We don't have timeboxes any more, so do we still need regular demonstrations? Retrospectives?"

A. YES! The teams demonstrate their progress to a wider audience of stakeholders every week. Everything demonstrated is truly "Done" - it is ready to ship. No smoke and mirrors, no mock layers, and everything running on the real product. This approach has been hugely successful in motivating the team, and ensuring the stakeholders know exactly where the issues are. By using a weekly heartbeat like this, any problems and decisions can be identified and addressed quickly.

Teams are still retrospecting every week too. However the next logical step would be to change this to ad hoc kaizen events as problems are found, and maybe holding a larger, formal retrospective less frequently.

Planning Games are held when required - i.e. when the 'Not Started' column is nearly empty. And because they only need to pick a maximum of 6 cards they tend to be brief.

So overall, how has the change been received? The main feedback from the people actively involved with the project has been almost entirely positive. Everyone feels that it feels like it is a more natural way to work.

From a coach's point of view, the change to "Scrumban" was far easier than I imagined. Why did I wait so long?