I’m lucky enough to work in an industry in which many participants employ craft, estimates and general guesswork, hoping to turn huge up-front effort in planning and documentation into a good result a year or
two down the road. Of course, this means that there are very few genuine successes. Many projects are delivered late and below spec, if they’re delivered at all.
A natural defense against this is to find a technique or product that has been associated with good results, start using it, and hope the problem goes away. Given the number of enterprises that take the effort to measure their productivity before and after such a change (pick a small number, then say “none”), it shouldn’t be too surprising that the end result of this process is either
- nothing improves, the change is blamed for poor results (even though the poor results were there before the change) and the change is rolled back, or
- nothing improves, but nobody notices and the change is made permanent.
All of this applies to the way some organizations adopt Kanban. And in Kanban’s case, it’s worse, since most attempts are in fact adopting nothing more than Information Radiators in the form of Task Boards. I’m all for Information Radiators. In fact I’m thrilled when I see one being used effectively. But when people rave on about how agile they are because they have this spiffy new Kanban board, I do have to exercise considerable restraint lest I berate them in front of their colleagues. These poor folk don’t even know that they’re not using Kanban because they simply don’t know what Kanban is. And when Kanban ultimately gets blamed for the eventual failure of the project, I despair.
The two most important points about this, and coincidentally the points that I tihnk are most often missed, are
- requirements are fed through the system from finish (right) to start (left), so the backlog is full of unfulfilled deliverables, rather than incomplete tasks; and
- the value stream (the sequence of steps needed to get from an idea to a result, usually represented as the names of columns on the board) is an important element of your information radiator which continually changes as you learn more, and must be periodically re-mapped to remain optimal.
Kanban had already been hugely successful in a myriad of other production industries (and some service industries) when Mary and Tom Poppendieck wrote their book Lean Software Development, applying it to software development. Mary’s blog covers most of the points made in the book; since you’re starting from this article, I suggest her post about bringing lean to software.
A few years later, Corey Ladas described Scrumban, taking his readers from the incumbent Scrum (or more specifically, the Scrum Framework) to leaner alternative. His scrum-ban blog covers al the essentials of the process.
Right, so that’s Kanban, for background. Now back to the topic: what is a Kanban board?
In Kanban, the board describes your flow, not the status of your tasks
Task boards show the state of recent, current and pending tasks. Assuming accurate up-front planning, your product or project will have reached your current goals when all tasks are completed. If all tasks are similarly sized and all completed tasks remain visible, then the task board also presents a rough guide to how close you are to “done”.
Kanban boards, derived from production-line containers and Kanban tickets, show what requests are being worked on, or have been fulfilled and are ready for pulling to the next column. They don’t necessarily give any insight into how close you are to done; you need something else for that (I suggest something that makes generating reports easy, perhaps an issue tracking application). Instead they describe the health of your flow, pointing out wasted time in the form of full columns, where WIP has reached the agreed limit.
It can be very difficult to translate what you do day-to-day into the tickets and containers you need in order to create a real Kanban system. But Kanban is also an emergent process, requiring you to continually improve your flow (and value stream) as new knowledge is acquired. A large part of Ladas’ Scrumban book is about how to learn from what you do in your scrum-based process, in order to build a useful Kanban flow. Coming up with a good value stream and continually refining it can be difficult, but I think it’s probably the most valuable thing Kanban can bring to your work environment, since it requires learning from your current process in order to come up with something better.
That’s very interesting. But is it worth changing when I already have a
Kanban task board?
Probably not, no. Not if you’re going to stop before you get it right, anway. And definitely not if you don’t need to; if it ain’t broke, don’t fix it, even if you originally chose Kanban for the wrong reasons. But if what you’ve got isn’t good enough, then maybe you should consider if it’s worth adopting (ideas from) Kanban.
This is my take on it: the Theory of Constraints (ToC) is a valuable tool to help you identify and resolve flow issues in your software development lifecycle, and Kanban is a valuable tool to help you visualize ToC in your environment. So if you want to improve flow, then it’s good to learn about Kanban. But there is a lot more to it than that. For example, if you haven’t yet realized that your job is not to produce software, but rather to help people do their jobs (of producing value for their customers) better, then Kanban can help you get to that epiphany faster.
Nope. Not convinced. I like Waterfall and I don’t care that it brings to mind images of soon-to-be-ex-loonies in barrels hurtling to their doom.
Good for you. Well-executed V-model (“waterfall”) projects do exist and are successful, and you’ve
been lucky enough to work on both of them. Eventually you’ll change jobs, or your job will change under your feet, and you’ll find yourself working on unsuccessful V-model projects. Then you’ll be looking for any port in a storm. Kanban may be exactly what you need then.
I have plans for more posts, and many of them will bemoan the distance between successful modern manufacturing practices and local software project management practices. This is why I said I was lucky to work in an industry with so many waterfall-following participants: there’s no end of topics to blog about! Before I write those bigger-picture articles, there will probably be a few more articles like this one, striving to bring a little bit of internet research to you, so you don’t have to go get it. I hope that this sort of groundwork will allow me to keep future articles short enough, by referring back to these early ones.
Has your Kanban board been successful despite not being Kanban? Have you tried Kanban or something close to it, and your project still failed? Share your stories below.
Talk to us about creating a
Value Stream Mapping or Kanban Flow for your team
– there is no cost and no obligation for this review!