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.
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.