Kanban in Practice: using Kanban to drive performance in the public sector

I’ve been using Kanban with my team for 8 months now to track our 19 objectives on this year’s business plan and this is what happened…

(For more on the theory of Kanban, see my previous post: What is Kanban?)

Some practicalities

Firstly, my team is not a software development team with clear processes for product development; most of our projects are flexible and unique. We made alterations to the Kanban system to compensate for our complex, bureaucratic public sector environment. Accountability and scrutiny is thorough, so I demanded evidence before any project can move onto the next development stage. This provided a really useful test of what’s claimed to be an adaptable change management system in a public sector setting.

Secondly, I recommend leaving the jargon out. I never refer to ‘Kanban’ or call it a ‘Kanban Board’ (we call it ‘the project board’). I generally find  most people in the real world have an allergic reaction to theoretical jargon and are likely to vomit on contact with terms like ‘Kanban’, ‘Scrum’, ‘LEAN’, ‘Agile’ or any other academic sounding theory or system. No-one cares what Kanban is; the important thing is that it works, not what it’s called or where it came from.

Assessing our delivery chain and designing the Kanban Board

I broke down our delivery process into 6 stages based on best practice examples that generally fit most of what we do:

1. Pending/Project plan development – each piece of work requires a project implementation document (PID) to explain how it will be completed. The project would be held (‘pending’) until capacity could be released.
2. Development/Review – the creation of a draft product that meets prescribed requirements.
3. Validation/Test – testing the product to make sure it works and is realistic, usually though a stress test or exercise.
4. Update/Holding – updating the product with recommendations from the test and holding the completed draft until it can be approved through the relevant governance body.
5. Approval – getting the draft product signed off by the relevant body.
6. Embedding/Training – embedding the knowledge and skills required to deliver the product in a real life situation into the organisation through training, briefings or other appropriate medium.
7. Complete – damn that feels good.

I’d like to say that I did this in collaboration with my team, but since I knew this was likely to turn into a day long workshop that could end in tears and threats of violence, I did it on my own. Because I’m the boss and I can.

Combining with ‘Huddles’ (or Scrums)

We combined the Project Board with weekly ‘Huddles’ – similar to ‘Scrums’ used in Scrum methodology. These short, <1 hour meetings provide an opportunity for each person to replay where they are with their projects. Each team member is given 6 minutes to answer 5 simple questions:

1. What the project is?
2. What was done over the last week?
3. What you plan to do over the next week?
4. Are you on track?
5. What help do you need from the rest of the team?

We hold the huddles next to the project board allowing us to move items along as we discuss.

What benefits did it bring?

• It clarified our development process into a clearly articulated system, ensuring everyone delivers projects in the same fashion. This picked up the pace of work by streamlining delivery.
• It identified bottlenecks in the system and helped prioritise projects to make sure we could meet appropriate approval windows.
• The increased transparency allowed for a shared understanding of the business plan empowering the team to better manage personal workloads and time.
• It allowed me and others to see who was delivering on the priorities and who was making excuses for failing to deliver.
• Increased transparency and reduced complaints about workload, allowing complaints to be more easily managed – by simply pointing at the board.
• It became a useful tool for deflecting additional work that tended to arrive in our inbox at random. Managers would visit with yet another bright idea for a project that would impact delivery of other priorities. Making sure managers could see the board I would say: “That sounds like a great idea. There’s not much capacity right now but we could re-prioritise one of these pending projects and slip this in ahead…” Quite often these ‘nice-to-have’ ideas suddenly became less of a priority.

Conclusions

Kanban has been a really useful tool but not without limitations.

The way it attempts to manage time was unworkable due to the varied nature of our work and the requirement to co-ordination with a wide range of partners who are perhaps less structured and efficient as us.

Since individual team members are responsible for the entire delivery of their project, the capacity management element only really had an impact in the ‘approval’ stage as the main bottleneck, and for individuals to ensure they weren’t spreading themselves too thin by attempting to work on too many projects at once. It’s made me think about changing the way we work, so perhaps team members becoming responsible for individual stages of the delivery chain such as training or validation; but that would be a long-term change.

The important aspect is that this is a tool that can be used in various ways. You don’t have to use it all, just the bits that you need. This may horrify fundamentalists, but it’s about using the tools to get you to the end product.