In their mini-book, Kanban and Scrum - making the most of both, Henrik Kniberg and Mattias Skarin point out that the Kanban Method does not prescribe any roles. Often people ask about roles in Kanban, expecting to be trained to play a specific role. The response is that your role remains the same as it is today. This is a core principle of the Kanban Method - you start with what you do now and you initially respect current roles, responsibilities and job titles.
There is a Role in Kanban
There is one role that helps when using the Kanban Method - the role of Change Agent. I hope to document this role when I get around to writing my book on Advanced Kanban. It is this role that my 3-day Advanced Kanban Masterclass (formerly known as the Coaching and Leadership Workshop) prepares people to play. If you are leading a Kanban change initiative then you might benefit from this advanced class.
A Lack of Roles is a Strength
When you create a change management process, a process that is designed to act on a workflow process and catalyze changes within it, you don’t want that change process to create inertia or increase resistance to change.
As Peter Senge wrote, “People do not resist change, they resist being changed.” A job title and a role played and the practices inherent to that role become part of an individual’s identity. Hence, asking them to adopt a new role, or a new job title, or change the practices performed in the role, is an attack on their identity. They will resist the requested change emotionally.
As Joe Campbell taught us 3 years ago, Kanban is telling you to “be like water.” The Kanban Method is design to go around the rock and the metaphorical rock in change management is emotional resistance. Kanban tries to avoid emotional resistance. Is does this in part by embracing current roles, responsibilities and job titles. Kanban does not prescribe roles in order to reduce resistance to change. A lack of roles is a strength!
Separation of Concerns
I truly believe that to have successful change, your process for change needs to be separate from the workflow process used to deliver customer-valued knowledge work such as software. A process cannot be both a delivery mechanism and a change mechanism. To be a delivery mechanism there is a need to design, define and prescribe roles with titles and practices. To be a successful change mechanism there is a need to avoid doing such things.
Lean has now given us two change process mechanisms - Kanban and A3. I consider A3 an alternative, a rival perhaps, to Kanban. A3 and Kanban are peers. A3 is a change process that acts upon delivery processes and workflows. A3 like Kanban doesn’t prescrive process workflow roles.
First generation Agile methods such as Scrum try to be both a delivery mechanism and a change mechanism. Scrum is challenged as a change method because it prescribes roles for the delivery method - the scrum master and the product owner, explicitly. In doing so, Scrum hits the rock head-on. It creates inertia against change by invoking emotional resistance in those being changed.
Summary
Kanban does not define or prescribe roles for the software development or project management process. It does not change the roles in the workflow for delivering customer-valued work. Kanban is a change management process designed to work upon the delivery process. A3 is a peer of Kanban. A3 uses a different approach but it is designed as a separate change management process. Separating the concerns of delivery from change is strength. It reduces resistance to change. Processes, such as Scrum, that couple delivery with change, struggle because the defined roles create resistance to change. It is, therefore, better to keep the change process separate from the delivery process.
Readers familiar with the Kanban Method as described in my book, Kanban: Successful Evolutionary Change for your Technology Business, or those who read yesterday’s blog post, will know that I identified five core practices associated with successful Kanban implementations. I am now considering extending this list to seven for a second edition of the book and a revision of the standard guidance on Kanban.
Current Practices
The five core practices currently identified are:
Visualize - make the invisible work and its workflow visible;
Limit WIP - implement a virtual kanban system;
Manage Flow;
Make management policies explicit;
and Improve Collaboratively - using models and the scientific method to implement a “guided” approach to evolution. There are no random mutations of the target process with Kanban.
So What Is Missing?
As I’ve identified in presentations and key note speeches I gave in 2010, 2011 and earlier this year, the biggest oversight is leadership. Small acts of leadership from any member of the team need to happen regularly. It is these acts of leadership that make change happen.
So the 6th practice is: Leadership - give permission for ideas and encourage process innovation from any and all team members.
There is also a need for explicit feedback loops. The Kanban book identifies these at two levels:
the daily standup meeting at the team and individual contributor level
and the operations review at the organization and inter-team or across services level
So collaboration to review flow of work and demand versus capability measures, metrics and indicators coupled with anecdotal narrative explaining notable events is vital to enabling evolutionary change. Organizations that have not implemented the second level of feedback - the operations review - have generally not seen process improvements beyond a localized team level. As a result, they have not realized the full benefits of Kanban observed elsewhere.
So the 7th practice is: Implement Organizational Feedback using Quantitative Measures of Demand and Capability
And the question is, “Should these additional two practices be added to the definition of the Kanban Method?
Recently, I hear some people familiar with Scrum compare it with Kanban by saying that “Kanban is also a framework” or that “Kanban offers an alternative framework.”
I know several leaders in the Scrum community promote Scrum as a framework, and while I might debate that appraisal I’m happy to accept it for the purposes of this post.
I do, however, want to take issue with those who propose that “Kanban is a framework.” Kanban is not a framework! It is a process to catalyze evolutionary change! It is a change management process. Arguably, it is currently the _only_ Agile change management process.
Definition of “Framework”
Here is one definition: A structure for supporting or enclosing something else, especially a skeletal support used as the basis for something being constructed. FreeDictionary.com
If Kanban were a framework it would suggest that it gives you the skeleton of a process framework and that you have to enhance and embellish that skeleton in order to have a specific process for a given context. This is clearly not how the Kanban Method works.
Definition of the Kanban Method
The Kanban Method is a change management method. It describes a process for driving change in an organization and that process has sufficient detail as to be repeatable. The context for which the process could be applied started specifically as software maintenance, then expanded to be general software development, and has grown to cover IT operations, IT services and some other areas of knowledge work. There is some belief and hope that Kanban will develop as a general purpose change management approach for knowledge worker industries.
The Kanban Method has three basic principles:
you start with what you do now - regardless of how ugly it is;
you agree to pursue an evolutionary approach to change;
and you initially respect current roles, responsibilities and job titles.
I then identified five core practices that were common to organizations that had success through Kanban. These were:
Visualize - make the invisible work and its workflow visible;
Limit WIP - implement a virtual kanban system;
Manage Flow;
Make management policies explicit;
and Improve Collaboratively - using models and the scientific method to implement a “guided” approach to evolution. There are no random mutations of the target process with Kanban.
As such Kanban is an orthogonal process to the target workflow process. If you are doing software development, the Kanban Method acts upon that process. It is not part of the process - though to be fair implementing a virtual kanban system will require changes to the target process.
Summary
The Kanban Method is a change management process. It is not a software development, project management or IT operations process or framework for such a process. The Kanban Method is a change management process and not a framework for a change management process. The Kanban Method is a specific formula for driving evolutionary and cultural change in an organization. It is designed to be followed and has shown some level or reliability and that outcomes from its use can be predicted within some spectrum of possible outcomes.
Kanban represents pragmatic, actionable advice for leading lasting, effective change in knowledge worker organizations. It is not an abstraction, or a skeleton. Take it, use it, let it help you evolve your existing processes for the better!
Podcasts are a great forum for learning. One can replay the important bits as much as one wants to. This week’s kanban roundup includes two podcasts in addition to thoughtful articles on working with the Feds, variation and standups. Enjoy!
News
A thoughtful blog post titled, “Bringing Kanban to the Federal market space” looks at the challenges kanban practitioners face when working in the federal space and provides suggestions on how to make progress. I found the advice to, “save your political capital for a later day” insightful. http://blog.leankitkanban.com/2012/04/bringing-kanban-to-the-federal-market-space/#more-1315
I’m proud to be the opening key note speaker at the first Lean Kanban Southern Europe Conference in Madrid, Spain next month. This small event is an attempt to emulate the first Lean Kanban conference in Miami in 2009 and catalyze the emergence of a strong community in Spain and Portugal. It’s a 2 day event with a single track of top quality international speakers the first day with 2 tracks on the 2nd day, one offering a full day of Spanish presentations with speakers from Spain, USA, Peru and Argentina. The pricing makes the event accessible for Spanish and Portuguese attendees in these tough economic times and makes this a truly low cost opportunity to learn Kanban and meet some of the leading practitioners from around Europe and further afield. There is still time to register. Pricing starts at 445 euros + VAT. Register now! Come enjoy Madrid and build your network of Limited WIP Society members
I’m particularly proud of the program we’ve put together for a smaller regional event. We’re working with the assumption that much of the audience will be new to Lean thinking in software product development and IT services and learning about Kanban for the first time. The first day is a single track designed to give attendees an overview and basic understanding of Kanban and how and where it is being used. This first day includes a presentation of the award winning Kanban implementation at BBVA by Atos Origin consultants, Oscar Garrido and Erika Weiss that earned them a Brickell Key Award nomination at the Lean Software & Systems Conference in Boston the following week.
The speaker lineup in Madrid is also very impressive as well as the quality of the businesses represented. Brickell Key award winner, David Joyce, on his way from Australia to Boston, will break his travel to give the 2nd key note. David is always an entertaining, informative speaker with beautiful presentations. As well as the BBVA case study from Spain, Angel Diaz, will present his experiences at ING Direct. Sticking with the financial industry, Eileen Shuter will tell the story of Vanguard, an American pensions firm, and their 3 year story of large scale Kanban adoption. From the media industry, we have Leopoldo Simini from Thomson Reuters in Argentina. Kevin Ryan will talk about portfolio level Kanban pioneered with the Financial Times. And at the other end of the scale, Nina Schwab from mobile search app startup, Tupalo in Vienna, will tell their Kanban story.
Explore the whole speaker line up for yourself. This is the truly unique opportunity to meet and share Lean and Kanban experience around Europe this spring. While a regional event, Greenlight PM have put together a high quality program and offer superb value for money. Don’t miss out. Register now! See you in Madrid!
