The Definitive Guide! KANBAN, Successful Evolutionary Change For Your Technology Business.
The Kanban Method will improve your existing development process. This book explains why and shows you how to get started using it right now. Case studies and illustrations make it easy to adopt the improvements you need for your unique situation. More...
$35.00 incl US shipping
New! QUOTABLE KANBAN
Pick up this FREE ebook filled with provocative thoughts from some of the leading kanban change agents around the world. More...
“Make the need for change visible, obvious and undeniable.”
—Joshua Bloom, from Quotable Kanban
Channel Kanban
Wednesday, May 16, 2012
Kanban Weekly Roundup - May 16, 2012
By Dominica DeGrandis
A collection of incredibly impressive thinkers and leaders from around the world has converged in Boston for the Lean Software & Systems Conference. This issue covers some of the many takeaways ….
News
Sunday’s Lean Camp (facilitated by Jim Benson) provided some amazing eye openers. First, an opportunity to study two large Kanban implementations and discuss why one saw viral spread and the other didn’t. Next, we played Russell Healy’s new Kanban system design game for Operations teams. Lastly, Jason Yip facilitated a well attended session on learning. Takeaway - put yourself in uncomfortable settings to learn - else you risk falling back into your comfort zone.
Day 1
The opening keynote with Steven Spear focused on achieving greatness through learning.
Spear suggests, “Find out what’s wrong with what you are doing and go tell a friend.” An appealing storyteller, he demonstrates the need for senior leaders to demonstrate their need for more knowledge to motivate people to learn.
David Joyce kicked off the Kanban track Monday morning with a talk on moving beyond the traditional PMO to 21st century portfolio management. Takeaway – Include a “Study” column at the beginning of the board.
Lightening and Ignite talks enlightened us all quickly! Simon Marcus, @lycaonmarcus voiced his concern on the current trend of management bashing. Between @stevenspear’s keynote and Simon’s lightening talk, my interpretation is the following if then statement:
if management is asking why
and not dictating
then don’t bash
Videos from talks will be available through lssc. In the meantime, slides from some talks have been posted on slideshare
Day 2 Troy Magennis incited discussions on how teams can work with upper management to get reliable estimates using the monte carlo simulation. Takeaway – The average is the worst value to use.
Mary Poppendieck’s talk on continuous feedback included an engaging and interactive discussion followed on set-based decision making versus Multiple Viable Product and a/b experiments.
Takeaway – These are not mutually exclusive, we just know when to do one or the other.
Day 3 Don Reinertsen rocked the main stage with his talk on decentralizing control. Taking examples from the US military and the forest fire service, there are too many takeaways to list, but here are my top three:
The important communication is lateral, and not from the top.
You have a duty to disagree if you believe otherwise.
If you think you can eliminate uncertainty, you’re delusional.
Next week the Lean Software and Systems conference in Boston will undoubtedly supply a plethora of buzz. Until then, here’s a series of blog posts from some prolific writers.
Four, yes that’s 4, new blog posts by David J Anderson on topics ranging from extending core Kanban practices to lack of roles to “certifying” trainers. Check them out. http://agilemanagement.net/index.php
When we announced the Accredited Kanban Training program in Lean Kanban University in February some people initially believed we were announcing a certification scheme for individuals taking Kanban training. We were not! Instead we were introducing standards into Kanban training by introducing a defined curriculum and accredited training material against that curriculum. We were also providing a professional designation of Accredited Kanban Trainer (AKT) to those individuals that we believed to be qualified to teach the curriculum adequately. We were “certifying” trainers.
Certification of a Role
Certification schemes tend to attach to roles played by individuals. Certified Scrummaster is an acknowledgement of some level of knowledge for playing the role of Scrummaster. Scrum has two roles, Scrummaster and Product Owner and two widely offered certifications - Certified Scrummaster and Certified Scrum Product Owner. There are also Certified Scrum Coach and Certified Scrum Trainer. I’m picking on Scrum as an example but many other methods and professions certify roles played at some level of proficiency or capability.
Certification in Kanban
There are members of LKU who wanted to introduce a certification scheme for individuals. In the current economy, all of our businesses need something to make it a little easier. Certifications do attract customers. People like to have professional recognition and a certification and some letters to put after your name, is one way of achieving such recognition. Under pressure in the meeting at the Hilton Royal Parc in Netherlands, I simply replied, “What are we certifying?” And that was the end of the discussion. Kanban defines and prescribes no roles. As I explained last week, this lack of roles is a strength. So, I will not be adding roles for the convenience of creating a certification scheme to make training companies money. Without roles, how do you create a certification scheme for individuals taking Kanban training?
As I stated last week, there is a role to played in the change management approach called the Kanban Method - the role of change agent - the person who leads the Kanban initiative and either facilitates or takes responsibility for the kanban system design. Might we be able to certify change agents who use the Kanban Method? Food for thought!
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?
