Earlier, we sketched out MMMSS, Many More Much Smaller Steps, laying out the bare bones. Cool, cool, but now we need to thicken our sense of the idea. Today, let’s close in a little more on what "step" means to us.
Many Much More Smaller Steps – First Sketch | GeePawHill.Org
The first plank of my take on fixing the trade is MMMSS: If you want more value faster, take Many More Much Smaller Steps. Today I want to start laying this out for folks. This isn’t gonna happen in o…
Tho I love my geekery, I don’t love it as much as the world. Here’s comfort food for today, take a break, enjoy this thread, but please stay in the largest game: actual social change.
We can fix this world, folks. We’re the only thing that can. Black Lives Matter.
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.
I want these really cool swept-back handlebars on my bicycle, with neon-orange soft grips and rainbow colored streamers, in order to clearly establish my primacy as the cool kid in our neighborhood. I will take the step of putting them on.
The bike is currently ready, if boring, cuz I could go for a spin now. On purpose, I will take the step of installing these new handlebars, during which time the bike isn’t ready, but after which, it is. The space between these two ready’s is the step.
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.
In casual parlance, we might call these single-activity actions "steps", but in MMMSS these are not steps. Why not? Because no one of these actions take us from ready to ready, and a step always does.
Loosening the fork’s bolt isn’t a step because we go from ready to unready. Tighten things back down isn’t a step, because it takes us from unready to ready. The others all go from unready to unready. So no, these are actions, not steps. MMMSS steps are always ready-to-ready.
A step can be one action or many, but to be a step it has to take us from ready to ready.
There are steps that just consist of a single action, but swapping handlebars isn’t one, and steps that are a sequence of discrete actions are far more common than the single-action kind.
Here’s a picture. I put a red circle at the beginning, that’s our cost, the stored up value we need to implement the step, and a green one at the end, for the benefit. The sequence of actions is in blue, and the step itself is the long violet arrow.
So, carrying this working definition of step, you can clearly see that, 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?
The center of MMMSS is just here, in the criteria a step must have for us to choose it. There are just two required criteria: In shorthand, we say, to be chosen, a step must be a) small enough, and b) not make things worse.
"Small enough":
All steps take time, from a few minutes to, well, whatever, months and months. 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. This is just fancy-talk for "what kind of system is the step changing?"
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.
This constraint, "small enough", can be made very severe, depending on how we set our pre-determined stride-length.
My own desired stride-length in coding should make this clear. Under an hour, centered on about 15 minutes, takes practice and technique.
It also takes stubbornness, creativity, and a deep consciousness of the fact that most efforts to optimize the business of working in stride-limited steps do not optimize anything at all. They are idols of the schema. We will surely be getting to that in the coming days. 🙂
MMMSS is urging you to choose the smallest stride-length you can consistently deliver right now, and further, to develop and practice your technique so that you can steadily reduce that stride-length over time.
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. Making that choice made me a far stronger — and faster — programmer.
"Not make things worse":
The system we’re changing produces value right now. We want more value from it, so that’s why we’re changing it. Not making things worse means we choose steps that do not reduce the value stream we’re currently getting from the system.
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".
Spoze the swept-back handlebars come separately from the neon orange grips w/streamers, and the ends of them have to be properly prepared, idunno, scratched up with steel wool to make the grips stick.
There are really three steps in play here. 1) Attach the handlebars, which gives us a small value boost. 2) abrade the ends, which gives us nothing at all in value, 3) attach the grips, which wins the neighborhood.
Are these all steps? Yep. Each one goes ready to ready. Each one is quite small, too. But that second step, scratching up the end of the handlebars, doesn’t really affect our value at all. It’s still a step, and still a valid choice in MMMSS terms.
So put the two criteria together. Small enough and not making things worse. Here’s another picture, this time of some rejected options.
By far the most beloved option here is the one marked #1. Teams pick this kind of option all the time, and it gets them in horrible trouble. It’s a very straight step aimed right at the horizon goal, but it’s bigger than our allowed stride-length, by quite a lot.
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. We reject steps that are not small enough.
We also reject those two steps marked with #2, because even though they’re small enough, taking either of them will reduce our value: they are making things worse. This is an easy rejection, and most teams aren’t at risk of choosing this kind of step.
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.
Choosing an option like #3 is not as common as #1, but it’s still an error teams frequently make. They’re conflating "discrete action" with "step". But steps are ready-to-ready, actions may or may not be, and this one isn’t.
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.
Here’s the thing tho, that path in #4 is sleight-of-hand. It doesn’t look like the too-big step of #1. Look, Ma, it’s a plan!! But it has exactly the same consequences as #1 does. Our system will be unready from the first action all the way to the horizon. Yuck.
So what about actions we choose? This picture is simpler. You’ve just got the stride-length radius and a variety of steps, where each of them might be the right choice.
The two steps marked #1 are straightforward enough, they’re true steps, they make things a little better, and they get us closer to the horizon. Of course, 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", where, instead of focusing on what each piece of our app will look like at the end, we focus on making a path like #3. In fact, MMMSS says this is what design is. More on this later.
Looking at all this, we’re starting to get somewhere. I want to point out one aspect tho, and I’ll keep banging away at it over and over as we proceed: there is a staggering amount of human judgment in all of this.
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.
To really pull this MMMSS thing off, we’re going to have to find ways to practice, attempt, experience, and build our judgment. In the immortal words of Rita Mae Brown: “Good judgment comes from experience, and experience comes from bad judgment.”
Coming soon, the case in depth. That case has both support for MMMSS (how it does its magic) and critique of the old school (compared to what!??). For our next trick, let’s take on the positive one: the intrinsic benefit of steps. Seeya soon.
Does the GeePaw Blogcast add value?
If so, consider a monthly donation to help keep the content flowing. You can also subscribe for free to get weekly posts sent straight to your inbox. And to get more involved in the conversation, jump into the Camerata and start talking to other like-minded Change-Harvesters today.