Kanban Coaching Insights

Every year, I invest in my personal development by taking classes and participating in conferences to grow my skills (see "Growing You" chapter in my Agile Coaching book). I chose David Anderson's  "Kanban Coaching Skills" workshop because I appreciate that Kanban is more than limiting Work-In-Progress (WIP) with colored cards on a board. As an agile coach, I want to understand more about the human aspect and how to introduce a team to Kanban.

David emphasizes that Kanban makes it easy for a team to get started. His mantra is "Always say 'Yes' we can do something." This can-do mentality is reflected in the "Yes We Kanban" strap line on the limitedwipsociety.org T-shirts.

He explains that the prime directive for getting started with Kanban is "Optimize existing processes through changes introduced with minimal resistance." When you bring in a Kanban system, it's important to avoid changes that affect self-esteem and social capital. That's why, when you introduce Kanban, roles, responsibilities, and job titles remain the same. The work that people do also remains the same, you don't question the competence of the team. Instead, you start Kanban by gaining agreement from all stakeholders to make the existing workflow transparent and set a WIP limit.

 Unlike other Agile approaches, there's no training period where the team must slow down to learn "best practice" and take on new roles. When Kanban is introduced, nothing is taken away. The only changes are additive. Some minimal new activities are introduced, such as a visual board with WIP limits. Also some working agreements are introduced to establish the stand-up meeting and setup a pull system.

Here's a change curve, that David drew in the class, showing a situation that he aims to avoid. You can see that when a lot of change is introduced in one go, the dip in performance can be too much for the organization to tolerate. Pressure mounts to drop the change and fire the change agents before any performance improvement is seen.

I've seen situations like this myself. When an organization wants to go Agile fast, a significant outlay in training and coaching is often required. Signing off on the costs for this shows the level of commitment to change. However, if the pressure to deliver, during this learning period, becomes too much and they take their foot off the accelerator and hit the brakes. It seems only those organizations who have a burning need for change (and believe that they can't go back) keep going long enough to reap the benefits.

Anderson emphasizes Kanban is different because it initiates a series of mini-changes, each backed up by empirical data. Here the change curve looks more like the next photo, a series of ripples, each making a small improvement to performance. When a team evolves their workflow and surrounding working practice themselves, changes tend to stick. This promotes a learning organization culture rather than attempting to institutionalize best practice. Kanban is a catalyst here towards becoming Lean.

 When I was taught SCRUM by Ken Schwaber, back in 2003, the emphasis was the same. Keep the existing interface and reporting mechanisms to management then "Inspect and Adapt."

Nowadays, more practices are often bundled in with the Scrum framework and it requires a bigger appetite for change. Being spoonfed practices that are known to work elsewhere and forcefully retrained as in "shock therapy" brings with it a risk that the team adheres rigidly to the new practices but doesn't feel empowered to adapt them. Scrumbut implementations and "cargo cult" agile are becoming more common.

I remember these approaches to change were contrasted by Kent Beck at XP2001 conference (although suspect the slides are lost in the mists of time). Back then, there was much talk about how important it was to do the all XP practices because the practices worked as a reinforcing system. Kent used the analogy of a roller-coaster and suggested that introducing change in a piecemeal fashion would increase stress on the team, as each change entailed a dip. At the same conference, Ron Jeffries decoupled XP practices in his circles diagram which helped teams looking for an incremental adoption to see the inner circle of "technical practices" as a place to start.

I believe that much of the worry about how "extreme" to be when starting with XP arose because there's no clear constraint to help balance the system. You must simply place your trust in the values, principles, and practices. You only qualify to tinker with them after you've fully assimilated XP---by which time you've absorbed some habits that are uncomfortable to let go of. No wonder Kent decided not to include Retrospectives in "XP Explained" 2nd edition (I did ask him but he wasn't convinced in the benefits).

Anyway, I don't want to get into a "named cloud" debate. There are many situations where XP or Scrum will be helpful. However, I see many situations where it's more practical to follow a gradual path to Agile. Where teams struggle is that if they're only attempting small changes then they often don't see how much they're improving. The beauty of a Kanban system is that it makes flow visible and tangible to all stakeholders, and helps the team maintain momentum in improving it.

David explains that a Kanban approach to change is like water, the work flows around the rocks in the river. It brings data to the surface that helps us work out how to improve without mandating a process. You can start with simple policies and adapt them as you go. There's no need to be like a chess player thinking too many moves ahead. Make a start with tactical fixes and trust that progress on root-causes will come in time.

Comments

[Henrik Kniberg]

Great post, thanks Rachel! I like David's "evolution over revolution" approach. I think one of the hardest jobs of a coach is to decide when to do evolution and when do revolution. I agree with David though that evolution should be the default.

[Adam D.]

This is a great article. Oh how far we've come in the last 10 years. Thought I was being Agile. Back to "doing" for the next little while :) Being a coach became more exciting!

[Dave Nicolette]

Thanks for sharing this. It's great stuff. I wonder whether this approach to introducing change is really unique to "kanban," though. Seems to be generally applicable. Still, great stuff.

[Nigel]

" I wonder whether this approach to introducing change is really unique to "kanban," though. Seems to be generally applicable. Still, great stuff."

It's not unique to Kanban at all. It is pretty standard change practice. Something that a lot of us do with Scrum as well.

[David Kaufer]

Kanban Leadership Workshop Washington DC - Sept 6-8, 2011
This 3-day leadership/coaching workshop with David J. Anderson, a founder of the Agile movement through his involvement in the creation of Feature Driven Development, is the last one being offered in the US through the end of 2011.
This workshop is suitable for managers, process engineers, change agents, experienced Agile, Lean, or project management coaches and consultants, existing Kanban practitioners with 1 year of experience, and those who have previously taken David’s Kanban class and are actively using Kanban at work. Attendees are expected to be familiar with David’s book, “Kanban - Successful Evolutionary Change for your Technology Business. Workshops participants will receive a copy of the book.
If you’d like to become a recommended Kanban coach or an approved Kanban trainer licensed to teach our official Kanban training material in 2011 then attending this workshop is essential.
Early registrants are entitled to discounts.
Location: Washington Hilton http://www1.hilton.com/en_US/hi/hotel/DCAWHHH-Washington-Hilton-District-of-Columbia/index.do
To register, please click on this link: http://agilemanagement.net/index.php/Blog/kanban_leadership_workshop_washington_dc_-_sept_6-8_2011