What if we took that a step further and actually turned it into a real assembly line? Using Kanban, your organization could then easily visualize bottlenecks as a piece of software progresses through the stages of a release.
Having issues with a pre-release step such as integration testing? You'll know because a bunch of releases will be stuck in the Release Backlog.
Is it too tedious to actually push the software to production? You'll know because a bunch of releases will be stuck in the Staging state.
How does this work, exactly?
Let me show you with an example Kanban board designed for releases:
We have a complex environment consisting of four development teams that need to perform releases on their own schedule. The initial layout gives us a Release Backlog and three states in which a release can exist. Pre-release would be performing any configuration prep, QA testing, etc. The other two should be self-explanatory.
Here's where Kanban really shines. Using WIP (Work In Progress) limits, we can enact constraints in specific points of the release process.
The WIP limit depicted above means that only three pieces of software can be in "Staging" at any given point. A team cannot begin staging a fourth release until at least one of the three has begun. A similar limit can and should be implemented in the "Production" state.
If there are issues in the release process, they will cause a backup of items in the prior states and/or backlog itself. Visualizing the states of all current and upcoming releases on the Kanban board will make it more obvious where the bottleneck exists.
One of the great things about Kanban is that it allows a lot of flexibility. You can define a WIP limit to be virtually anything. For instance, you could weight releases based on the length of time they take. Or you could weight them based on the relative impact to your site if that software's release went badly.
There are some Kanban specifics that I didn't detail because they are a bit out of the scope of this blog post. If you find the concept interesting I urge you to look into it.
This doesn't sit well with me.
ReplyDeleteThe Kanban concept, I mean. It does make some sense when described the way you're using it, but the fact remains: kanban is not a savior process nor an ideal solution. Toyota used it to alleviate problem areas. Kanban isn't the solution, it's an elegant way to deal with continuous flow problems (while working to fix the root cause). This is why US automakers largely failed - they tried to apply Toyota's band-aids as the "next generation solution."
Now how that relates to software, I don't know. I think what you described is an interesting way to model - and place limits on - units of outstanding software. Project management tools model this somewhat in critical paths, too.
Thanks for the reply.
ReplyDeleteThe continous flow problem is exactly what this is meant to solve! :) Because it uses a "pull" mechanism, the responsibility of maintaining it is up to the person or group working on the current state.
Teams can then focus on the causes of blockage in the flow. This should create a waterfall effect, enabling people to work on problems they may not have realized or been able to prioritize.
And no, this definitely isn't a proverbial silver bullet.
Another benefit from this is that it can ease you into a paradigm shift from scheduled deployments to continuous releases throughout the [time period] -- barring technical or business restraints, of course.
Agreed :)
ReplyDeleteExcept.. Kanban doesn't solve a continuous flow problem, so your first sentence is misleading. Toyota never applies a Kanban system and stops trying to improve, they put it in place temporarily (it *is* evil inventory, after all) while they work on the root cause.. as you pointed out. Sorry, I get uppity when people say that Kanban solves flow problems. It is an important distinction!
Relating industrial manufacturing techniques to software engineering, though, is something I've been thinking about as well. Bravo for the succinct description you've given here.
-Charlie (@cschluti)
Thanks! Interesting though, w.r.t. how Toyota actually uses it.
ReplyDeleteNobody EVER said Kanban "solves" continuous flow problems. Not even Toyota, and absolutely none of the lean software advocates say this. So where are you getting this from?
ReplyDeleteKanban is a VISUAL TOOL, it's intended to bring TO YOUR ATTENTION continuous flow problems. YOU, then, as a human being ultimately responsible for getting production things done, must read and interpret what the kanban is telling you, and take appropriate actions.
In the field of electronics, these are called "pipelines," and each stage has an enable bit which serves as an "interlock". If this interlock is engaged, the pipe is stalled, as subsequent stages are given more time to complete their tasks.
Likewise, when the WIP limit is reached, you've achieved interlock, and now you can devote more resources as appropriate to resolve the hold-up.
It's really that simple. I genuinely don't understand where people get their crazy mis-interpretations from.
Sorry if I seem pissed, but it irks me to no end when people complain about how "Kanban isn't the silver bullet," only to state the bleeding obvious. Innovations are never silver bullets, but if they improve production quality or time to market, it's well worth publicizing. Settle down, people, and chillax already. Sheesh!!
OK, calming down....breath in....breath out....one...two...three....