This fall, we are introducing a new curriculum to our class offerings - Project Management with Kanban. Note the subtle choice of title - "Project Management with Kanban!" It isn't "Kanban for Project Managers." Kanban for Project Managers makes as much sense to me as "Kanban for Refuse Collectors" Why would such a class be different from say, "Kanban for Grandmas"? It's all just Kanban! Perhaps the case studies and examples might be different but the curriculum would be the same. On the other hand, Project Management with Kanban" offers us the chance to provide a new curriculum, specifically targeted at managing project where kanban systems are in use and the Kanban Method is part of the organization's management approach.

Over the years, there has been a commonly recurring question, "Are we doing Kanban or not?" I've always answered that the answer isn't based in practice adoption but is rather a question of intent. Do you have the intent to pursue evoutionary improvement of service delivery using the Kanban Method? If so then you are doing Kanban and if not then you are not.

This spring I noticed [1] that the rather clunky name we give to the implementation process for Kanban that we teach in our classes and private workshops has a catchy acronym, STATIK. Just as we hoped, this is turning out to be much "stickier" than the systems thinking approach to introducing Kanban; we find that not only do we refer to it a lot, so do our clients.

I've listed a whole series of Kanban Coaching Professional (KCP) Masterclasses for the 2nd half of 2012. These classes are typically residential and can be consumed as 2 x 3-days or in a single 5-day week long intensive class. Typically 4 out of 5 people are choosing the 5-day version of the class since we introduced it at the beginning of 2014. These classes are a big commitment in time and money and we often get asked where the value is? I'd like to explain.

Success has many fathers! Recently, there has been some content published elsewhere on the web that seeks to re-write the history of the adaptation of kanban systems into the field of creative knowledge work. The individuals publishing these alternative versions of history are generally doing it for self-serving reasons or in some cases as deliberate misinformation to try and undermine my business. To put the record straight, I've compiled this definitive history...

A History of Kanban for Creative Knowledge Work

October 2004

Dragos Dumitriu, manager XIT Sustaining Engineering at Microsoft, asks me to help him. I design a pull system for Dragos' group and coach him on how to introduce it. He "sells' the idea to his bosses and his 4 product managers who act as his customers. The pull system was implemented on Microsoft Product Studio (a forerunner of Team Foundation Server). There was no physical board. The engineering team was offshore in Hyderabad, India. The system implemented was inspired by Theory of Constraints Drum-Buffer-Rope and worked on the assumption that Test was the bottleneck.

Every business or every unit of a business should know and understand its purpose. Sometimes businesses have lost sight of this and there is scope for a workshop exercise amongst senior leaders and business owners to define that purpose. What exactly are they in business to do? And it isn't simply to make money. If they simply wanted to make money they'd be investors and not business owners. They would spend their time managing investment portfolios and not leading a small tribe of believers who want to make something or serve someone. So why does the firm or business unit exist? If we know that we can start to explore what represents "fitness for purpose."

Our firm doesn't sell process improvement or provide consulting services in defined or designed processes. I'm often asked, as a I travel around the world, "What does you firm do?" The answer to this is simple! "We are a management training business." "We also have event management and publishing businesses."

Recently, we've seen a lot of activity in the marketplace focused on "scaling Agile." It seems after a decade or so, people have been willing to admit the "Scrum of Scrums" concept just wasn't cutting it. There is now sufficient evidence of large scale failed Agile transition initiatives to know that previous decade's hypothesis about delivering large scale Agile adoption hasn't worked. Now we have a new wave. IBM has DAD (Disciplined Agile Delivery) and Dean Leffingwell and Rally Software Development have SAFe (Scaled Agile Framework). Other tool vendors in the market are encouraging emergence of "me too" scaled Agile solutions.