Why I Teach Kanban

By James Steele

A Dream Come True

For 25 years I helped organizations build enterprise software. A few years into my professional journey I made the decision that I would pursue a professional dream of mine and that the pinnacle of my career would be achieved once I had become the Chief Technology Officer (CTO) of an influential software company.  Boy was I wrong!

After more than two decades working as an independent consultant and coach, I was presented with an opportunity that would bring my dream within reach. I joined a global e-learning company that was developing enterprise software to help educate millions of people across the globe. I accepted the position of V.P. of Software Development, and after several months of success in that position I was promoted to CTO.

I had arrived!!! A dream come true! Over 20 years of hard work had paid-off.

Then something happened, and I decided to throw it all away.

This is the story of why I gave up the C-Suite to teach Kanban.

Going Agile!

As CTO I had complete influence on the direction the company would take in it’s approach to software development. We were struggling to make deadlines, our predictability was poor, quality was not acceptable, and people were overburdened. From my new perch I could change all of this!

Similar to the decisions that most leaders in my position were making at that time (and continue to make until today), I decided we were “going agile”! Our teams would start using the Scrum framework and in no-time we would be reaping the benefits of business agility.

Hither to, our software development process had been chaotic. I’d go as far as to say that we really didn’t have one. We trained staff on the Scrum framework, we certified some people to be Scrum Masters and Product Owners, and we put together cross-functional Scrum teams that were self-organizing. We also hired a Scrum coach who would help us with our transformation.

Adopting Scrum brought immediate structure to the way we were working. For several months we saw improvements at the team level, but we slowly started to lose momentum, and after the initial honeymoon of having structure to the way we were working, we started struggling.

Sure, things had improved, but we plateaued very quickly.

Shifting Gears

After 2 years of using Scrum, we found ourselves still failing to meet customer delivery expectations, unable to get a handle on being predictable, and people were frustrated working within the ceremonies, roles, and cadences of the Scrum framework.

Equally disappointing was the failure to see improvements in our ability to respond quickly to shifting customer priorities and capitalize on emerging market opportunities. Our pursuit of business agility was evading us.

It was around this time that I was introduced to the Kanban Method. I was intrigued by an approach to improvement that was evolutionary in nature and was particularly sensitive to respecting professional roles and identifies.

The simplicity (and as I would soon learn, POWER) of the method, coupled with the fact that it did not prescribe HOW we should work, was something that really resonated with me (and I suspected would resonate with our teams).

I met with our teams. We talked about the Principles and Practices of the Kanban Method, and together we decided we would give them a try in an effort to improve the situation we found ourselves in.

Discovering Kanban

Starting Kanban was not disruptive for us. We started from a very simple standpoint – we were going to continue working exactly the way we were, except that:

• we would visualize the work we were doing
• we would limit the amount of work we were doing
• we would make policies explicit
• we would focus on identifying why the flow of work was interrupted and adjust policies to try and avoid future interruptions of that nature

We did this for several months and here is a summary of the results:

• We quickly discovered that many of the Scrum ceremonies and elements of the framework were getting in the way of doing our work (we abandoned many of them).
• People experienced relief from having too much work in progress.
• We discovered that many of the interruptions to the flow of work stemmed from dependencies on other teams,  having to redo work that was not correctly done the first time, and dealing with ad-hoc interruptions for unplanned work.
  
  
  
  

  ---

   

  If you find this useful, please consider contributing with our
  “Value for Value” model.

   

  ---