Kanban isn’t the Point

I was Kanban-a-lizing an existing process with HR today. As we are making software delivery processes visible with Kanban, HR decided they wanted to give it a shot and visualize their work. This particular department has about 30 people and their responsibilities range from HR to Learning and Performance to Change Managment, Talent Aquisiton and more.

As we talked about the work, it was clear the work was highly variable, somewhat unpredictable and subject to big batching.  For example, they could start a nine month project and get no ‘customer’ (read: employees) feedback until its too late.

We struggled for a bit trying to define work types, process flow and how the sub-departments connect with each other. I started asking questions like:

– who’s going to be looking at this board?
– how often does new work come in?
– does each department get involved in every project or chunk of work?
– what problems do see as a result of how you work now?

I asked many more questions and the interesting response at one point was:

We really want to make our work visible so all the sub-departments know roughly what other sub-departments are working on because we want HR as a whole to communicate a unified message to the rest of the organization

It was interesting to me that the person I was working with was focused on ‘getting the board right‘ and I’ve noticed that symptom numerous times.  Whether it’s comments like “we can’t put stickies on the wall, what happens if they fall off?” or “see, I told you so, that sticky was on the floor when I came in this morning!!“,  sometimes people get caught up on the tool rather than the meaning and purpose behind the tool.

“Kanban” isn’t the point.

I’m sure this sounds bluntly obvious to many of you.

I like to use the competence/consciousness model to describe what I see when any new process or change is introduced.

As people progress through the stages in this particular model, the maturity of the thoughts, comments and questions rise:

Unconscious Incompetence – You have no idea Kanban exists

  • Insert other randomly chaotic comments here

Conscious Incompetence – You’ve done a training session or read a book

  • “hey, we can’t use stickies, they’ll fall off the wall”
  • “this is dumb, can’t we have an electronic tool?”
  • “we can’t limit our WIP, this HAS to get done”
  • “let’s setup our new Kanban board, we don’t know why we want to use it but everyone else has one and I feel left out”
  • “hey, that policy says we can’t go to the next phase until the story map is done.  I know we don’t need one for this, but the process says we can’t proceed to GO or collect our $200″
  • “I know we can only do 5 projects per month but these other 4 have to get done so I’ll put them in the queue”

Conscious Competence – you’ve used Kanban for a few months and still sorta ‘follow the process’

  • “I need to get this project in, where is there capacity and how can I re-allocate people”
  • “wow, we’re spending a lot of time on maintenance, there’s way more green maintenance stickies than yellow project ones”
  • “wait a minute, I thought that project was cancelled?”
  • “wait a minute, if our throughput is X and our cycle time is Y, I can’t commit to doing this project by Z”
  • “that policy doesn’t make sense anymore, let’s change it.”

Unconscious Competence – You’ve realized “Kanban” isn’t the point and stop talking about Kanban and start talking about the actual work.

  • “let’s do a root cause on those blocker stickies, there have been 4 in DEV column over the last week, something is going on”
  • “time to tear it down and start over, this process flow doesn’t make sense anymore”
  • “if we had a DBA on the team this handoff would go away and prevent downstream and late defects”

The important point of all this is that it’s natural to progress through these stages as you learn anything new.  When I first got started with Scrum I remember emailing my CSM instructor asking him if we were supposed to estimate defects.  After I gained more experience I realized I was asking the wrong question.  The right ones were:

  • why do we have defects in the first place? bad requirements? poor technical practices? “a team of individuals” syndrome?
  • are there patterns in the incoming defects?
  • what are customers calling about the most?  let’s fix those areas first.
  • what is a defect, really? It’s just work that needs to get done, let’s stop tracking in-process defects.

My point is, learning new processes takes time before you see better outcomes.  You’ve got to learn the process, follow it (to an extent), get experience with experimenting with the new process, actually understand the reasons behind using the process and then customize it to your environment.

This takes months, or years, depending on your environment.  No amount of “no no no, we NEED to do it faster and change NOW” is going to help and in some cases that type of thinking can do more harm than good because you’ll give up too soon and sink back into old habits.

  • Petri Heiramo

    Hi Jason, I like the diagram, haven’t seen that before. And it’s so easy, and kind of unfortunate, for me as more advanced to expect beginners to progress through the stages, or skip the first two entirely, just by having me tell them (or show them). And how easy it is to write an almost unintelligible statement by adding all kinds of “clarifications” to it :).

  • Anonymous

    Nice post Jason.  Sounds very similar to the Shu-Ha-Ri model.  I see many companies wanting to customize a process, be it Kanban, Scrum, or anything else, before they even try, let alone understand, the process.

  • Pingback: Kanban isn’t the Point | Jason Little | Development Block()

  • Dave Nicolette

    Good info based on experience. Thanks for sharing.

    Sometimes it helps to start by mapping the value stream. That way everyone is talking just about how the work flows, and aren’t worried about any sort of board. Later, the board becomes a representation of the work flow, and people are less susceptible to get hung up on the tool. This approach has worked for me on several occasions. No magic bullet, of course. You have to read/listen to the people in situ to perceive an approach that will work in context.

    I’ve seen the conscious competence model presented as a “ladder” before, but not as a quadrant diagram. Could be useful.

  • http://www.agilecoach.ca Jason Little

    Thanks Dave, I used the ladder representation in a session today based on seeing your comment.  I like representing it that way.

  • http://www.agilecoach.ca Jason Little

    yes, very similar.  I like using different models from time to time to get multiple perspectives.  I agree with your statement about the desire to customize a process before true understanding it.

  • http://www.agilecoach.ca Jason Little

    I think people need to progress through the stages in order to really understand it.  I remember working with a guy who was a self-proclaimed expert in just about anything.  His stance on “Kanban” was “it’s all bullshit, you just keep working and never release”.  He was too ignorant to even understand what he was talking about.  I find those people tend to stay in unconscious incompetence longer because they, for whatever reason, can’t get past basic surface knowledge and then consider themselves and expert.

  • Pingback: Playing Get Kanban with an Experienced TeamJason Little | Jason Little()