Sunday, October 18, 2015

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

Sunday, October 04, 2015

Scrum Master or Zen Master?

Another Scrum-Master Anti-Pattern

Well – of course there is not one Scrum-Master anti-pattern. There are dozens.

Let's look at a special one today: The Scrum-Master as the Ruler, the Projectmanager, the Sovereign of the project.

To cut it short – Scrum-Masters are not.
Originally weren't meant to be at least.
Maybe sometimes they actually are – but they should not.

It is about the verb ‘master’

Here is what the dictionary on my computer has to say about the verb master:

2 it took ages to master the technique:
learn, become proficient in, know inside out, know (frontward and) backwards; pick up, grasp, understand; informal get the hang of.

If you look at it that way, a scrum master becomes to scrum what a zen master is to zen: someone who has mastered scrum and now is able to help others – at their request - to become more proficient in what they do.

Of course he also has a lot of other duties as well, but the fundamental idea of ‘mastering the process framework‘ in contrast to being the 'Master of the team' is really a big difference in the attitude.

The Scrum Guide explicitly states that ‘The Scrum Master is a servant-leader for the Scrum Team’, perhaps this is worth taking into consideration from time to time.

till next time
  Michael Mahlberg