“We’re using a modified Kanban process.”
I admit, I cringe when people say things like this. It normally says to me “I haven’t put much thought into my process or my workflow, but we’ve got a board with some columns on it and the work goes there.”
In its simplest form, a Kanban gives you tools for two things:
- visualizing your workflow
- setting limits on each step (column limits) to maximize the completed units of work vs. the appearance of being busy
This all came from the Toyota Production System, though, and they have set a higher standard:
- Customer (downstream) processes withdraw items in the precise amounts specified by the Kanban.
- Supplier (upstream) produces items in the precise amounts and sequences specified by the Kanban.
- No items are made or moved without a Kanban.
- A Kanban should accompany each item, every time.
- Defects and incorrect amounts are never sent to the next downstream process.
- The number of Kanbans is reduced carefully to lower inventories and to reveal problems.
It’s important to note, though, that Toyota has been at this an awfully long time. And the success of the Toyota Production System is not a result of simply having the Kanbans and the processes behind them. Behind it all is a strong supportive culture backed by an alignment on values. I stress this, because it is at least as important to foment the culture you want and aligning on values as it is to “do Kanban” or “do DevOps” (whatever that is supposed to mean).
If you’re in middle management, or higher, you’ve got a lot of work to do. I’ll write some more about fomenting a DevOps Culture in another post. I’ll also write some more about Values, and why they are so important. So hang tight, I’ll get back to you in another post.
If you’re in a development team or an ops team (or, better yet, a cross-functional team) or you’re the direct manager of such a team, this is aimed at you. Let’s get started.
1. Identify the main types of work your team handles. This is a crucial step. Don’t skip it. Common examples include:
- New Feature
- Research Spike
Notice I didn’t put “write tests” or “test feature” or even “document feature”. Is the feature complete without a test or without documentation? I’d argue probably not. These are certainly valid subtasks when breaking down your work, but ultimately that new feature is the end product that your customer is expecting and represents the Story (in Agile terms) or Card (in Kanban terms).
2. Identify the main steps you follow from the point the work enters the team (upstream) to the point it leaves the team (downstream). Make note of each of the milestones along the way and what order they fall in. Don’t forget to include the intake/triage steps, task grooming, pre-scheduling steps, testing, documentation, etc.
3. Create a table of rows & columns for each type of work. You’ll need a column for each of the main steps identified in Step 2. Work will move from left to right across this board. If it ever moves backwards (right-to-left), you’ve probably derped something. It’s not crazy to have 10+ columns for a new software feature!
4. Set column limits on each step. If work sits in one place for too long, that represents one kind of costly waste. It’s best when using a Kanban to set strict limits on each column, even the backlog, and enforce them. If a downstream column is full (has reached its column limit) nothing else can move forward until that column has been drained by advancing its cards forward. This is painful at first, but what you’ll begin to see is less work in flight and more work getting done. The reduced context switching helps with the engagement of your workers, and brings the quality level up. They will soon realize they are getting more work done in less time, and without working any harder than they did before.
Next I’ll talk a little bit about how you measure the success of a Kanban team, what the maturation process looks like, and what not to measure (which is just as important).