We talked at great length about how agile coding practice can be seen as combining several attempts at attacking the thinking knee, but what about agile non-coding practices.
As I push towards the topic, which is it what got me started on this set of muses, I want to offer a bit of caution before we start.
I’ve used the thinking-knee idea to elucidate a bunch of seemingly unconnected corners of the practice. It might seem I believe that’s all there is to agile: means to outwit the thinking knee. I don’t believe that.
I’m using "fighting the thinking knee" as a lens to help us clarify & unify a bunch of behaviors that don’t seem related on the surface. And as a lens, it’s useful. But it’s partial. Lots of parts of the agile practice have little to do with the thinking knee. Still, as we push out from coding practice, I hope you’ll see that the idea of the non-linear thinking knee is still useful in our considerations. Let’s go to it.
Almost every "make it smaller" impulse you see has as part of its rationale based in cheating the thinking knee. Making things smaller, after all, very often directly reduces the piece count. If we force all stories that get to be WIP to be two days or less of work, we’re very likely reducing the number of points a given story touches the existing code. That’s piece count.
Why have five daily 12-minute standups instead of one weekly hour-long standup? One of the reasons, smaller scope, which is just another way to say fewer pieces.
Not all of the tricks are this direct. Consider pairing & mobbing. Do these reduce the piece count? No. They really don’t. Does that mean they’re not related at all to the thinking knee here we step into chunking. We said before that all chunkings aren’t created equal. Some "work" better than others. What’s one way we can get better chunking?
Well, "better chunking" certainly seems to be closely related to "shared & sharable chunking", doesn’t it? Pairs & mobs have among other effects that they help create chunking schemes that are consistently more nearly optimal.
We prate endlessly on smaller cycle times. Shortening these actually relates to the thinking knee twice.
First, smaller cycles usually still means fewer pieces, the direct contact. Anything I can turn around in a few minutes is likely to involve far fewer parts than what I can turn around in a few days. But shorter cycles connects in another way. Do you know that WIP items are also pieces? Someone in our team, often several of us, is looking at our board, and sees each WIP item as a piece that must be thought about.
Shorter cycles means literally that WIP items live shorter lives. And that, in turn, means that there are fewer that need to be balanced in our minds at one time. So things that reduce WIP, either directly by having fewer lanes, or temporally by having shorter time in the lanes, connects right back to avoiding the thinking knee.
- (Aside: the technique of swarming, which gets little press but is super powerful, exists almost entirely for this purpose. Swarming is when a team takes one story and distributes its pieces to the entire team rather than to a single individual, pair, or mob.)
One reason chunks work is because they open & close. They form mental boundaries around pieces & other chunks. We can be inside the boundary and deal one way, or outside the boundary and deal another way. Getting work "done-done" is a way of closing a chunk. It takes the chunk and removes its guts from view. All of the tricks that work by shortening cycles do roughly this same thing.
CI is a form of this, and so is CD. Oddly, so is the part of TDD that lets me push the code whenever my tests are green. These all work in part by allowing us to take a piece or pieces that are in our head and move them out of our head.
So, I think i’ve just about exhausted what I needed to say about non-linearity, the thinking knee, and agile practice, at least as a separate topic. (i’m sure it will come up in passing again, for no other reason than because once you start looking at the thinking knee and our ways to work around it, you can’t stop looking at it.) the conclusion i’d wish you to draw: the non-linear thinking knee presents a huge challenge in s/w development, one we’ve spent decades tackling in a variety of ways. Agile practice, coding & non-coding, is the latest wave of these efforts.
The behavior i’d wish you to consider: explicitly considering piece-count, the knee, and all the creative ways there are to keep your chunks — scope — as modest & narrow as you can.
The thinking-knee can’t be eliminated. It is a fact of the biological limits of humans. But here and there, now and then, we can find ways to hold it at bay. Agile practice represents among other things our best latest efforts to identify & take advantage of these ways.