When you read about Kanban the thing which usually isn’t described in details is what happens with sticky notes which make their way to the right side of the board and are in the last column of your Kanban Board (however you call it).
To be honest I didn’t put much thought in that when we were starting with Kanban. Our sticky notes were just stacking up in ready-to-ship column until we no longer could read them easily. And it was just a matter of time when they were going to come unstuck and fall being trashed by cleaner and forgotten forever.
What we decided to do is to file a sticky note when a feature is actually shipped.
We don’t ship every MMF separately although there are some who do that. We rather look for a complete set of features and ship them in a package. That’s why out “done” column was named “ready to ship” since it is one thing to have some feature ready and completely separated to implement it in production environment. At least it is so in our case.
The key thing for our team is to have feature ready to deploy as soon as possible, not to have it live as soon as possible. It is so because due to a bunch of external dependencies (interoperability) deployment is pretty painful and rather long process which we definitely don’t want to do twice a week.
However when we decide to ship something – there comes everything which is ready at the moment. This is the operation which empties our ready-to-ship column. I take all sticky notes which were in the column and add them to the stack stored in my drawer. After all we need some documentation, don’t we?
Read the whole Kanban Story.
Subscribe RSS feed
Follow on Twitter
Subscribe by email
11 comments… add one
My plan (not yet implemented) is to keep all cards that make it into production (maybe in an envelope, not sure yet), in case there is a production bug. I’d like to keep track of and measure the number of bugs we find once in production. To track, I’d put a post-it (of a specific colour) on the post-it, with a short description.
(This is most likely not going to be a pure Kanban board, which is a bit difficult to achieve in my environment. I’m trying to expose specification and other problems, and want to track the number/ratio of bugs found in production.)
That’s an interesting idea. However you may want to consider two things:
– Effort needed to find the right sticky note and add another one to it every time a bug appears. It will stack up to significant amount of time and the only thing you get is visualizing which feature brought the most problems.
– Problems with connecting specific bugs with specific features (sticky notes). There are some bugs which can be hardly ascribed to a specific functionality.
For bugs we just use bug tracker and even though we don’t chain bugs with MMFs it it clearly seen whenever we happen to have lower-quality feature. The other thing is finding out why it is so which almost always leads to some objective difficulties (e.g. complex design etc).
Those are good pitfalls, thanks for pointing them out.
I think the main reason I want to track this is to prove my suspicion that there’s a lack in the way requirements are formulated/documented/communicated. I.e. to motivate why we should move to some other system (maybe something like BDD or TDD), or to have closer relationships between development and the customer.
I want to make this ‘back-and-forth’ visible and explicit (which is one of the aims of the Kanban board), so that I can point it out.
I plan to implement the same kind of tracking mechanism for cards bouncing back and forth between dev and qa teams, again to make the fact explicit and to measure it (i.e. x ‘bounces’ per card).
That’s another thing we do the other way around. We don’t ‘bounce’ sticky notes between developers and QA. I’d say we have some kind of collective ownership over features. Of course when a feature is tested leading role goes to QA guy but he won’t fix bugs or something. It’s role of everyone to push cards further to the right side of the board.
Bouncing cards between two sub-teams can be a bit counterproductive. I don’t know whether you push cards on the board between testing and fixing stages back and forth but if that is so it can bring some issues with keeping the work under limits.
Having said that I’m aware that introducing ‘collective ownership’ can be damn hard if people aren’t used to work this way and they expect it is clearly stated which tasks are theirs and which are not. Most of the time revolution in this area is way worse idea than evolution.
You describe the ideal situation, i.e. a cross-functional team focused on delivery, not task. As you mention, that would be difficult in my environment, since the teams are quite separate and quite silo’ed.
In my earlier comment, I mentioned that I want to make these bounces explicit, in order to prove something about the system. Maybe the proof I’m seeking will be good motivation to move towards cross-functional teams, i.e. if I can prove that this bouncing is a problem, one of the possible solutions will be cross-functional teams.
Again, in my first comment, I did note that my board won’t be a pure Kanban board. We will not start off with WIP limits. To answer your question, yes, we will push cards backwards in the system.
Again, I’m trying to expose problems such as ‘what is done’, since that concept isn’t really apparent in the environment. Hopefully we can realise the problem by tracking the amount of reword we’re having to do (both pre- and post-production).
Also, when a card bounces back from the QA team, it will interrupt whatever is being worked on right now. I’ve written some thoughts on rework and interruptions in this blog post: http://joshilewis.wordpress.com/2009/11/16/jidoka-and-multi-tasking/
You’re trying to do pretty difficult things. I thing changing people approach from focusing on completing only their part of the task and instantly forgetting about the rest to collective responsibility for delivery is one of the hardest thing in transition to agile approaches.
Anyway, what you think of does make sense when I think about it. It probably won’t do very good job in terms of limiting work in progress but at least there will be big visual showing which team actually owns the task. That should add motivation to push tasks further as soon as possible to avoid big stacks of started work.
On the other hand there’s risk of low-quality work (e.g. let’s just apply dirty fixes and push the task back to tests so we have less tasks here).
Sure, there is that risk.
I think a more fundamental issue exists upstream though, i.e. issues with specifications/requirements.
I think it’ll be easier to change that before trying to change the quality of development work (which will probably be a large and difficult change here).
Most sources I’ve read say structure the board to the process to begin with, not vice versa. Limiting WIP and creating a proper pull system is probably a multi-year goal in this environment, but I’m also trying to find easy wins and start the process with baby steps.
The biggest barrier in my opinion is education and ‘stubbornness’
About the board being adjusted to the process and not vice versa – fully agree.
Write an update from time to time on your blog how things are going, what works and what doesn’t. I’m looking forward to read about that.
Great, I will try.
Unfortunately, I’ve again lost momentum with the blog again, will try get it back on track soon.
Also, the environment is such that it takes a while to implement changes, and I’m planning on limiting my adoption WIP (with a dynamically prioritised backlog ;) ) so feedback might take a while.
Thanks for reading it and commenting.
There is a discussion on ‘status tags’ for cards on a Kanban Board here: http://www.xqa.com.ar/visualmanagement/2010/01/status-tags-revisited/
To Joshua. It is always more effective to ask from people directly what you want instead of making complex systems. Ask to improve requirements when you get them right away. Tell what you need. Remember, that it is not about Them to deliver requirements. It is about Them and _You_ to discover requirements. Most likely you know technical part better than Them, don’t you?
If you want to create multifunctional teams, then sell it to Them (if that’s the problem?). Find Their problem and show how can you solve it with cross-functional team. Ask Them to let experiment or do it yourself, but then remember to sell it to other party :) Now you will need to discover Other Party problems to sell :)