I Kanban. So Kanyou.


“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:

  1. visualizing your workflow
  2. 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:

  1. Customer (downstream) processes withdraw items in the precise amounts specified by the Kanban.
  2. Supplier (upstream) produces items in the precise amounts and sequences specified by the Kanban.
  3. No items are made or moved without a Kanban.
  4. A Kanban should accompany each item, every time.
  5. Defects and incorrect amounts are never sent to the next downstream process.
  6. 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).

Begin Here

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
  • Defect

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 up?

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).

 

Advertisements

3 comments

    1. Yes, Gene. We’re just getting started here. Set up the Kanban, start measuring your baseline… Observe->Plan->Do->Check->Act. We’re going to talk about all of these things.

      Also, please come see me give a talk for Triangle DevOps at Bronto Software on 9/17 at 7PM. They haven’t put up the meeting announcement yet but the date is firm. I’m going to be speaking to the DevOps Year One plan, including implementing a Kanban workflow. Deming & Jacques will both get props. 😉 If you can’t make it, I believe we’re going to be live streaming via Google Hangout and then sharing the video to YouTube afterwards.

    2. Learn How To Get Started With DevOps

      Wednesday, Sep 17, 2014, 7:00 PM

      Bronto Software Inc.
      Suite 410, 324 Blackwell Street Durham, NC

      8 Members Attending

      This month Magnus, one of our co-organizers, is going to speak to us. Here are the details of his talk, in his own words.OK, I’m ready to DevOp. Now what?We’ve heard a lot about the technologies behind DevOps, and even a bit on the processes that some DevOps shops employ. What we haven’t heard too much about directly is a fundamental matter of bo…

      Check out this Meetup →

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s