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

Why I hate "Inspect and Adapt"

Because more often than not, people don’t.

They way I grew up with agile, one of the basic tenets of all agile approaches was the notion that there is no prescribed ‘right’ process, but you have to do what it right at this point in time. There even was a lengthy discussion whether the approach should be called ‘agile’ or ‘adaptive’ when the agile manifesto was created.

Now I see people ‘doing agile’ all around in manners I sometimes fail to understand. And I hear complaints that the agile stuff doesn’t really work. And more often than not, the explanation I get is along the lines of “But agile says ‘inspect and adapt’ and we adapted.”

IMHO one of the best answers to that was written by Ron Jeffries and is called We tried baseball and it Didn’t work.

And what I see quite often when I hear that teams ‘adapted’ the approach they try to use, is exactly that – they adapt without doing the inspection of the real thing first. Go ahead - read it! :)

So if you want to use the inspect and adapt approach, please make sure that you have something to inspect before you adapt it.

till next time
  Michael Mahlberg

Why is there never enough time to do it right?

There is this adage “why is there never enough time to do it right, but always time to do it over?” depicting that in the long run it almost never pays of to try to do something quick and dirty. Once again my friend and esteemed colleague Tom Breur made an excellent point on this effect in his blog post.

The flip side

But there is a flip side to that. While I seriously loathe the “quick and dirty” approach so many people still try to make work I am also weary about “getting it right the first time.“
Because "getting it right the first time" just isn’t in the mindset of the scientific method. Nor PDSA/PDCA. Nor Inspect and adapt. Nor does it cater to the nature of knowledge work.

Can we ever get it right the first time?

Of course it is possible to get things right the first time. For example if we're talking about launching a product. Or if it is about adhering to our code of conduct. And – and that is especially important in my point of view – we can work in what we consider to be the right way. Using the right tools for the job. Sharpening the saw in between felling trees. Just generally being good craftsmen.
Take the iPhone for example. Taking into account that it factually redefined the market it was obviously "done right the first time." Unlike for example the newton, which had a solid follower-ship but just didn't get traction with the mainstream.
Or take electric light, the classic example. More than 1000 experiments until there was a working lightbulb. But when it went public, it seemingly was done “right” from the way cities look at night these days.

So what’s the trick?

I don’t know the trick to getting it right the first time, but in all the efforts I have seen that managed to “get it right the first time” there was a lot of learning through experimenting (which means a lot of failures) before things actually went ’live’.

If you want to get it right...

... remember that in most knowledge-work and especially in software development, it is necessary to do it wrong a couple of times in order to find out what right really means.

...and still be willing to do it over.

Because over time you will learn. And add funny things like Copy&Paste. What they did on the iPhone. After it broke all sales records for smartphones at that time.

So, yes: Take your time to get it right. And please do not expect everything to be right the first time!

till next time
  Michael Mahlberg

Does PDCA equal “Plan the work, work the plan (and control that)?" – I don't think so!

I don't know how this came about, but a little while ago a friend of mine (whom I highly regard, both personally as well as as a project manager) came up with the notion that PDCA implies planning, having the plan executed (do), checking the results and (re)acting if they are not up to standard.

Maybe I am mistaken and that is, what Deming really means, but the way I understand his text and for example this talk by deming himself it is quite the opposite.

The way I understand it, it is an almost direct implementation of the scientific method:

• Plan: Formulate a hypothesis and design an experiment for its verification (on a controllable scale, including the definition of an expected outcome)
• Do: Execute the experiment (in a more or less controlled environment)
• Check: Verify the results from the experiment with the expected outcome
• Act: Either implement the changes from the hypothesis or don't! – Depending on the outcome of the experiment.

Am I wrong in my interpretation?

Cheers Michael

Add some PDCA-Spice to your “Inspect and Adapt”

My beef with “inspect and adapt”

According to legend agile software development almost would have been called “adaptive“ software development. And for a big part that is what agile approaches are about.
It is all about adapting the process, the tools, the interactions to the situation at hand. And most approaches out there have very well defined ways to handle such changes.
But – and it is a huge but – nowadays some people justify everything they would like to change by just invoking “inspect and adapt.” But in some cases (and those are the cases I'm so agitated about) it is only adapt. Or not. Actually sometimes it is only change. But without inspecting first, there is nothing to adapt towards!

What adaptation is, ...

... is for example put nicely by wikipedia:

Adaptation, in biology, is the process whereby a population becomes better suited to its habitat. (emphasis added)

It is not some random change. It is based upon circumstances. Actual facts and requirements. And if one aspires to adapt to something intentionally that just is not possible without knowing those circumstances. In other words: it is necessary to inspect the circumstances.

If you gotta do it, do it right

So yes, you should follow “inspect and adapt” – just don‘t call it a method or try to imply that every time you change some aspect of your process you‘re following the ideas of “inspect and adapt.” If you want to change the ways you work for the better, try employing some formal approaches.

Take some advice from the Lean and Kanban community and follow the so-called scientific method, which – [according to the university of Riverside, CA] – consists of the following steps

1. Observe some aspect of the universe.
2. Invent a tentative description, called a hypothesis, that is consistent with what you have observed.
3. Use the hypothesis to make predictions.
4. Test those predictions by experiments or further observations and modify the hypothesis in the light of your results.
5. Repeat steps 3 and 4 until there are no discrepancies between theory and experiment and/or observation.

One of the approaches that has the thinking behind this ingrained in its DNA is the Deming cycle, often called the PDCA cycle.
The four steps P lan, D o, C heck and A ct actually implement the scientific method for the context of process improvement.

Some things about the PDCA-Cycle come up in conjunction with Toyota’s implementation that seem noteworthy:

• Plan
  build a model of the expected changes to the process – a model also specifying the expected outcomes of the changes
• Do
  try the proposed changes on a small scale, if necessary with extra effort (that can be accounted for in the check step)
• Check
  Verify that the process changes deliver the expected outcomes
• Act
  Roll out the changes to a broader audience, including the automation of labor-intensive tasks or roll back the changes and go to square one (e.g. Plan)

(The rinse-repeat of the whole cycle is somewhat implied by the name cycle, and thus the fifth step – start again with the next idea – is not made explicit)

One more thing... in fact, PDCA is not the Deming cycle – PDSA is

At least according to a guy called W. Edwards Deming this cycle is called the PDSA cycle – and he really should know it...

Be that how it may – the question remains: will you just randomly change things and justify those changes by citing “inspect and adapt” or will you inspect and adapt by following a scheme like PDCA and “install” or “back out” changes based upon feedback collected on some experiment that provided you with real data?

till next time
  Michael Mahlberg