Negotiating changes

aka “What’s all this talk about «experiments» and «safe to fail» about?”

Inspect and adapt may sound nice, but all too often, I only see adapt. Without inspect. That’s one of the reasons I like the more systemic approach from Kanban so much:

• the Principle: Agree to pursue improvement through evolutionary change
• the Practice: Improve collaboratively, evolve experimentally (using the scientific method)

What's the big difference here?
Most of all, using the scientific method implies an approach based on observable effects of changes. Concepts like the Cynefin Model or the Toyota Kata include things like a ‘probe’ – a safe to fail experiment.

Let's illustrate this with an example from a “scrum by name”-team from the recent past. After some tension about a change, a friend of mine –who was responsible for organizational matters in that situation– agreed to “go ahead and implement the idea”, adding that he already knew that it would be “a waste of time.“
For me this approach was a good example for the traditional mindset of simply adapting without employing the scientific method.

Whatever one did in that situation, it should not be a waste of time. As the late Jerry Weinberg once said: “You can’t always win – but you can always learn.”

Instead of simply implementing that change, the systems thinking approach would be to run it as an experiment!

So what would that mean?

• Firstly talk with all parties concerned about the (observable!) attributes of the work that should not change (e.g. «the Standup should not become longer») and how to measure or recognize any unwanted changes.
• Then talk about the things that should change and how to measure and recognize these changes. And don’t forget that you need a baseline for that – otherwise it’s hard to recognize whether things have improved or not.
• Agree upon the next time you evaluate the data and decide on whether you want to proceed with this change you're experimenting on. You might want keep the change, roll it forward or roll it back.
  Rinse and repeat. (This is by the way one way to implement a PDSA loop)

A concrete example

This may sound difficult, but coming back to an example from an earlier post –having the PO attend the daily Scrum– it may be as simple as:

• We don’t want the daily Scrum to be longer than it is now and we don’t want an increased number of meetings with the PO. Now we have 15 minutes standups and an average of 4 meetings with the PO per week.
• We do want the PO to be have more situational awareness. We would know that if he called us less often about the schedule. Today he calls every other day.
• We will decide how to proceed in three weeks after we lived through one and a half iterations or if the daily is longer than 30 Minutes twice in a row (this part of what makes the experiment safe to fail, along with the small size of it).

[BTW: ‘We’ in this example might or might not include the PO - that’s a question of the individual setup and the maturity of the team and organization.]

Now if the experiment ‘fails’ (e.g. the things that shouldn’t have changed changed and those that should didn’t) that still delivered value: the team learned that they need a different way to involve the PO and can work on other approaches to include them. If, on the other hand, everything works out as desired it is just a matter of agreeing to continue with those new rules.

When thinking about feasible experiments (also called probes) I also like the question I learned from David: Is it small enough to try and safe enough to fail?

Happy experimenting!

till next time
  Michael Mahlberg