Kanban doesn’t prescribe much – if you follow The Kanban Story you already know that. Kanban Board which is a key tool in Kanban isn’t pre-designed or something. You need to tailor your own. That’s how we did with our Kanban Board.
We decided to start with something simple and then adjust things as we go. We redesigned Kanban Board because it is meant to be changed. But even then it wasn’t the final shape.
When we left the board last time it looked like that.
What was the problem?
On a general level we switched to more frequent deployments. At the beginning we didn’t have any system in production but it has changed. Sort of. Anyway our endpoint was no longer “ready to ship” – we wanted to see new features live.
Before the change we were marking MMFs as “in production” by throwing sticky notes out. The problem was there was no limit for “ready to ship” station, so features could wait there on a huge stack waiting for deployment. Something rather opposite to what we’d like to see.
The other thing which pinched me was documentation. We had a stage for this purpose but it appeared we were documenting after we’d pushed feature into production. This was perfectly fine since we don’t sell boxes with up-to-date documentation inside and it was no problem at all to have documentation updated a couple of days after deployment. The problem was our Kanban board didn’t correspond with this.
After playing with some ideas we came with version 3.0 of our Kanban Board.
What has changed?
The left part hasn’t changed at all. We were happy with it.
The first change was merging “test” and “ready to ship” columns into one under the name of the former. What we got was testing stage which was separated into ongoing and completed phases. When a feature was tested it was ready to ship. We no longer expected documentation to be updated before shipping since we weren’t working like this anyway.
Another thing was adding “live” column which means feature was successfully deployed. I didn’t like the idea of adding another “deployment” station since deployment is very fast in our case.
Documentation was left as the last but one column and at the end “done” station emerged. After all it is such a nice name for a column.
Limits
Redesigned part of the Kanban Board reflected our workflow much better but required also limits adjustments. Instead of rethinking whether we should add 1 here and subtract one there I wiped out all limits and rethought them from the beginning.
Limits of 3 for “todo” and 4 for “development” had worked well so they got their way back to the board.
The next one, and the hard part, was limit for “live” station. Remember our pseudo-iterations? Because of this approach we deploy a few features at once. So far there were two or three in each package. However it happened a couple of times that an emergency feature was added during a pseudo-iteration. Since this kind of feature was meant be included in the same deployment package this made a maximum of 4 MMFs possibly being shipped at once. That’s how “live” stage got its limit.
The same reasoning applied to “test” station. Since it was possible to move 4 sticky notes at once to “live” column, they all had to be taken from the previous one, thus we couldn’t set there anything less than 4. We didn’t want to set anything more either, so the lucky number was exactly this: 4.
“Documentation” got a limit of 2 since it’s often convenient to document 2 corresponding features at the same time.
Looks like we get more and more columns over time. I just wonder whether that’s a good thing.
If you liked the post you may want to read the whole Kanban Story.
Subscribe RSS feed
Follow on Twitter
Subscribe by email
9 comments… add one
I like the live and doc columns, with WiP limits because they force you to frequently perform those tasks otherwise the entire value stream gets held up. It makes a lot of sense to impose small WiP limits on these columns. I think a lot of people would be reluctant to implement a WiP limit on a ‘live’ column because they’re scared of deployments – which is indicative of other problems.
This also implies to me that to deliver value its not sufficient to just deploy a feature, but also to document it. This leads me to the question: ‘what else is required to provide value?’
Also, what is your opinion of including the documentation requirement as part of the ‘done is done’ contract for a specific column, perhaps dev or test (I’m not sure). Should certain requirements be part of ‘done’ contracts or have their own columns on the board? How do you distinguish between them?
We haven’t written hard requirements for each column – it’s just more of common knowledge of the team.
Development is completed when:
– code is written
– unit tests for the code are created
– developer performed set of manual tests and in all went good
– if something can’t be easily tested (i.e. integration interface) there is a testing tool (simulator or something) created
Bug is fixed when:
– fix is applied to specified version of the application; if we want to fix a bug in a couple of versions we submit a couple of bugs to our bug tracker
– unit test following reproduction scenario is created
– fix is retested by QA folks in one of official builds; we also have unofficial, quick, dirty builds but they don’t count here
Feature is tested when:
– there’s no known bugs or, in very special cases, we agree that version can be shipped with specific minor bug(s)
– all planned functional tests were performed
– whenever change or bug fix affects any part of the application, the affected part is fully retested
Feature is live when:
– version is deployed
– all sanity-check tests pass; these verify all basic fucntions of the app
– our customers can access the feature
Documentation is done when:
– our maintenance guy is happy with it
It would be hard to have each of these details having its own column on the board. We just collectively worked out the way we do our jobs.
The other thing is I believe the Kanban Board should have as little columns as possible but at the same time the board should reflect real workflow.
If we document our features and we do that after deployment and it takes significant time (up to a couple of days in some cases) there should be a column where a sticky note spends these two days.
If it happens, rarely but it happens, that a feature is at research and design stage for a week we add a column which shows it because that’s not really development since work isn’t progressing here in terms it is while the feature is in development.
But we don’t add deployment stage since it takes on average less than hour to deploy the app. We don’t move a feature between testing and bug fixing stages because these two happen in parallel and even if they didn’t we would need to move a sticky notes up to few times an hour which doesn’t make any sense.
It all depends on how you work. Consider the way of work as a hand and make Kanban Board a glove. It should just fit.
I understand your conditions for moving features into different columns are not explicit but well understood.
My point is, you’ve got documentation as a column on your board. I.e., in your context, you specify documentation as a step in your value stream. I imagine the documentation step could be specified as part of the requirements for moving a card to a column on the right (i.e. a ‘done contract’) instead of as an explicit column. Having it as a column makes sense to me becuase it makes sense in terms of adding value.
This led me to ask the question, do people sometimes have criteria in their ‘done contracts’ that should rather be explicit columns in their board?
I guess this question becomes ‘how well do people understand their value stream?’
If I had to tell you which criteria makes it to the board as explicit column and which does not I’d say it depends on averege time and maximum time a sticky note would spend in the column. If it is at least a day there is a column, otherwise there is not.
But you stressed one crucial thing – it doesn’t really matter whether there is column or not. What is crucial here is how well people understand value stream – you nailed this one.
By the way, on the very beginning we didn’t have documentation as explicit stage in our process – it appeared because team preferred to see it this way.
I understand. I think its a very nice example of what a value stream is, and how the Kanban Board and its evolution can assist and even direct in better understanding your value stream.
I’m not certain but I think its the first time I’ve read about a documentation column on a board.
I’m not sure if I saw documentation anywhere else either, but I’m sure there are teams which have this stage. If you work on a system where documentation is one of key products you need to incorporate it to your workflow. If you happen to work with Kanban it will appear somewhere before ‘done done’.
Yes, but only if you understand it as one of the phases in your value stream :)
Hi again,
I was reading some messages in the kanbandev Yahoo Group and came across this message: http://finance.groups.yahoo.com/group/kanbandev/message/6777 which reminded me of this conversation. In case you can’t access the post, the relevant part is the columns the poster has on his board:
“waiting | analysis | development | testing & doc | done | tag and deploy to stag | deploy to live”
The reason it made me think of this post because considering something like tagging your source to be adding value is interesting to me. I’m not sure if tagging your source adds value or is secondary waste. It may indeed value if part of adding value is being able to track versions etc (typically this would satisfy a system administrator stakeholder).
How do you define value as simply as possible? If you start off with a value statement of ‘deliver software’, do you add terms such as ‘maintainable’ to it?
Actually I don’t really get what they acutally do during this step and why tagging is so important in this case. It is hard to decide whether something adds value if you don’t know context.
I may oversimplify here but the way I look at flow I want to have as few steps as possible but at the same time I want to be able to say what is happening with a feature at every moment. And I mean meaningful parts of process here.
When I look at the board and see a feature at ‘ongoing testing’ station I know:
– testing has been started
– testing hasn’t been finished
– either some parts of feature haven’t yet been tested or there are bugs which haven’t yet been fixed
And yes, it adds value after all because ‘before’ a feature isn’t good, i.e. there are bugs in there, and ‘after’ it is good to deploy.
It is really hard for me to describe that way tagging, but it is easier with pre-production deployment which is a part of discussed stage. When I see a feature at this station I know it is deployed (or under deployment – we have no data whether there are ‘ongoing’ and ‘completed’ sub-columns) in pre-production environment and possibly basic sanity checks have been done.
In terms of adding value pre-production deployment is an ultimate test for production deployment which is crucial in systems which can’t have long outage (or can’t have outage at all). Before you aren’t sure whether deployment will go smooth and after you’re pretty sure it will.
However I could imagine doing test deployment during testing. It all really depends who does this (if these are separate teams it is a good idea to split columns), how much time it takes (if deployment is time-consuming you may want to know whether a team performs functional testing or test deployment) or if this is an important milestone for one of stakeholders (and you want to explicitly show it).
Anyway I wouldn’t tell there is a definition of ‘simple enough’ or ‘as simple as possible’ – it all comes down to team’s judgement in every specific case.