What change do you introduce next?

During Agile adoption and transformation, there's an important question of "what change do you introduce next".

Approaches

I see a few approaches to introduce the next change.

• Adopt Scrum, which means to introduce Scrum roles - cross-functional team, PO and SM; Scrum events - planning, daily Scrum, review and retrospective; Scrum artifacts - product backlog, sprint backlog; most importantly, delivering Potential Shippable Product Increment (PSPI) in every sprint. This is a big and radical change. And it is just a starting place. By asking to deliver PSPI every sprint, Scrum acts as a mirror, exposing your problems and weaknesses, which you introduce your next change to address them. In short, it is the radical change (adopting Scrum) followed by incremental changes in the spirit of continuous improvement.
• Adopt Kanban, which means to introduce 3-6 practices. 3 practices are visualize the work, limit WIP and manage flow. 6 practices include explicit policies, feedback loops, improvement in addition to the 3 practices. This is a less radical change than Scrum, since it does not involve immediate structural change. Kanban is more a change management technique than a development process. By limiting WIP and measuring cycle time, it exposes your problems and weaknesses so that you can improve. Kanban evolves from lean thinking, and continuous improvement is its root. In short, it is a less radical change (adopting Kanban) followed by incremental changes.
• Adopt specific practices based on experience. Scrum and Kanban are explicit methods that group a set of practices for synergy, while experience based approach contains more tacit knowledge. In David Hussman's approach to create coaching plan, he assesses 4 areas - Team and community, Iterative delivery, Product and planning, Improving and tuning, then, based on experience, suggests the next change or set of changes. The change is practice oriented, rather than method oriented. For instance, if product and planning are weak, he may suggest to adopt practices such as Agile chartering, Persona and Story mapping; if iterative delivery is more restricting them, continuous integration may be the next change to introduce. This is followed by another assessment after a while, and another round of change, which is a continuous improvement cycle too. In short, it is incremental change after incremental change.

Notes:

• As change, big or small, radical or incremental, they are really a continuum, rather than a dichotomy.
• One difference lies at the first step. Scrum takes bigger step than Kanban; experience based approach is flexible but usually takes smaller steps.
• Another difference lies at looking for the next change. Kanban and Scrum have built-in mechanism to guide your next change. Kanban has stronger focus and direction than Scrum on what to improve next. Experience based approach involves more tacit knowledge.

Path through Agile fluency

In 2012, James Shore and Diana Larsen created a team's path through Agile fluency.

• 1 star: focus on value by shifting team culture - adopting Scrum/Kanban practices
• 2 star: deliver value by shifting team skills - adopting XP practices
• 3 star: optimize value by shifting organizational structure - adopting product discovery practices such as lean startup
• 4 star: optimize for systems by shifting organizational culture - looking at culture of organizations such as Semco, Valve, etc.

In essence, Agile fluency model is an experience based approach. It creates explicit knowledge as a model based on authors' experience. As comparing to David's approach embedded in his coaching plan, I see two main differences.

• Agile fluency model contains more explicit knowledge than David's coaching plan. David only describes 4 areas that he would look into, which is explicit knowledge, while he doesn't explain how to come up with effective suggestions, which involves much tacit knowledge.
• The areas specified by David are in fact quite similar to areas in Agile fluency model. Team and Community vs. 1 star area; Iterative delivery vs. 2 star area; Product and planning vs. 3 star area. While Agile fluency model suggests the progression from area to area, David seems taking an approach to progress in depth in all areas.

Future work

In my experience of introducing changes, i have mainly been using the approach of starting with Scrum adoption. I realize more and more that many organizations are not ready for this approach, thus not effective in moving forward. I'm gradually taking more experience based approach in some context.

Considering "Limits to growth", i favor more on David's approach over Agile fluency path. However, we benefit from creating more explicit knowledge around areas.

• What's ideal in each area?
• What could be progression in those areas?
• Develop some checklists to guide the assessment and suggestions

I'll start on my own, talk to my colleagues at Odd-e, and talk to David about the interests to work together.