(2021-10-26) GeePawHill MMMSS A Closer Look At Steps

GeePawHill: MMMSS - A Closer Look at Steps. Today, let’s close in a little more on what "step" means to us.

I’m not much for rigorous definitions, because life isn’t Euclid or Plato, and everything we do that’s important involves making judgement calls near fractal boundaries, but let’s take a look at the idea of a "step" in a little more depth.

A step is a purposeful gap of unreadiness between two points of readiness on some system’s timeline, a before point and an after point. The system starts ready, and it ends ready, and the step is that period during which it’s not ready. It’s important to distinguish here between "action" and "step".

To take this step, I do several actions in a sequence: loosening the bolt on the steering fork, removing the old handlebars, aligning the new ones, and tightening that same bolt.

from any given point of readiness, there are an effectively infinite number of possible steps we might take. How, then, do we decide between them?

MMMSS is saying that we set a pre-determined maximum step-size, we call it a "stride length", in elapsed time, and that we won’t choose a step longer than our chosen stride-length.

The correct stride-length, of course, depends on our operational context.

A typical operational context in professional programming would be: "changing our production-ready code". That is, each step we’re taking has the actions of checking out the code, editing it, and checking it back in. My stride-length here is "well under an hour."

Another common operational context for software development is "changing product", in which we are implementing a story. My standard stride-length for this is less than 2 team-days from start to finish.

A third one? "changing process". Here, we usually need a little more time, and the limit approaches that of a single working week to actually "ship" a new process. Some take a day, some take three, none take longer than five.

Maybe the biggest lesson I learned from TDD back in the oughties was just how far I could reduce my stride-length if I only chose to.

"Not make things worse":

There is a significant difference here between MMMSS and the traditional wisdom, which says that every step must actively improve the value stream. That is not the MMMSS view. This subtle point actually dramatically changes the game.

Of course, we prefer steps that improve our value stream, and we look for them. We are always looking for the biggest value bang from our step buck. But it’s important to understand that we do not require "greater-than" value, only "not less than".

Steps that are too big and aimed right at the finish line seem so attractive! But MMMSS tells you you’re being lulled. You’re ignoring the intrinsic benefit of steps, you’re relying on simple plane geometry, and so on.

The arrow marked #3 is also a reject. It is small enough, and it takes us in the right direction, but it’s not technically a step. It’s drawn in our blue "action" color, and if we take the action, at the end of it we will not be ready.

To make that last point a little more clear, look at #4. There’s a path of non-step actions that take us from here all the way to the horizon. This is what old-school rework-avoidance development theory drives teams to try all the time out in the field.

So what about actions we choose? This picture is simpler.

most teams love that #2 cuz it goes so straight at the goal, but that can be an error, actually.

*To clarify, we look at step #3. Notice two things: 1) the first step adds no value. That’s legal, the rule is only that it can’t make things worse. 2) Unlike the others, there’s a path of steps from where we’re at to where we want to be, each smaller than our stride-length.

Arranging steps in paths like #3 is a whole skill: "path-focused design."* (2021-05-25) GeePawHill: Path-focused Design

MMMSS says this is what design is.

We are constantly, in MMMSS, using our individual and team judgments to assess things that, frankly, we can’t know. Setting stride-length is judgment. Guessing a step’s size is judgment. Guaranteeing a step isn’t just an action is judgment. Path-focused design is judgment.

we’re going to have to find ways to practice, attempt, experience, and build our judgment.