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
- “IT ALL HAS TO GET DONE….AHHHHH!!!”
- 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.