Strawberries 2: Increment. Rhythm. Brackets.

We’re here to replace raspberry jam with strawberry jam. We need those delicious nodules of flavor and value.

Weinberg’s Law of Raspberry Jam is often quoted to explain why there’s so much flaccid and Dark “Agile” out there:

The wider you spread it, the thinner it gets.

I want to replace that thinking with Jerry’s Law of Strawberry Jam:

As long as it has lumps, you can never spread it too thin.

The Strawberries series works toward discovering and describing strawberries, easy to try, tasty ideas that are difficult to spread too thin. By and large, you have a strawberry or you don’t¹.

Today’s topic, well, topics, are the Increment, Rhythm, and Brackets. They go together, as we’ll see.

Increment

I have written often about the Increment. That’s because, to me, it is the single most important element in creating a software product in the agile fashion. In one of my personal favorite articles, I phrased it this way:

Every product team will be responsible for having a ready-to-ship, integrated, working, tested product all the time, containing all the solutions that the team has chosen to be in the product.

When I say “all the time”, I mean to say that if there is a minute in your product’s development cycle when you do not have a ready-to-ship, integrated, working, tested product, with all the capabilities you’ve so far accomplished, if there is a minute when you don’t have the Increment, you’re doing it wrong.

Of course, we are not perfect and all that. But creating the increment is easy. For the programmers among us, here’s the first increment for Product X:

10 PRINT "PRODUCT X: CAVEAT EMPTOR"
20 END

There you go. Get to improving. Maybe your first improvement should be to pick a different language, I don’t know. Just keep it working. Add a single capability, test it, it’s ready to go again. Rinse, repeat.

It’s surprisingly easy once you get the beat. Which is our next topic.

Rhythm

I owe GeePaw Hill for this term. You may also hear the term “cadence”. There is even a bit of rhythm in “release train”, and a bit of value, which I’ll leave to the reader to work out. Unless I don’t.

Our lives are literally lived according to rhythm². Our hearts beat rather regularly, around three billion times over our lifetime. The sun has risen and set almost 30,000 times over my lifetime. (February 13 will be the magic day.)

In our work, we generally count years, months, weeks, days, and hours. Most of those are arbitrary, but they are built into our culture, and they provide a rhythm by which we order our time.

I would suggest that as we look at our software product development, we should look at at least these important rhythms:

Year, Fiscal or Calendar

Our company probably makes significant decisions on this cycle. We would do well to schedule some important review and planning relating to this rhythm, probably leading it.

Quarter

Companies often think in terms of quarters. Again, we will probably do well to schedule some review and planning.

Month

Again, same drill. Monthly status reports, and so on. Stuff happens. We’ll do well to look sharp at those intervals.

Week

At last, something that probably actually affect us. With any luck, we work some number of days every week, then get a few days off. We’ll do well to look forward and back at those intervals.

Day

Yes. Probably makes sense to reorient every morning, make sure we’re on the right track, assess any ideas that our team members have had overnight, deal with issues of the previous day.

Morning / Afternoon

It’s up to you, but any break we may take is a great opportunity to look around and see how we’re doing.

The Tests Run

Ship it. This is in some ways the key rhythm of software development. If we can arrange things so that every hour, every fifteen minutes, every five minutes, every tiny interval, when the tests run we can commit our code …

We’ll have a shippable increment, all the time. The key ingredient, right there.

We get to pick our rhythms, to some degree, and some are provided by the earth spinning around the sun, or by the person in the corner office upstairs. We need to attend to them, and to keep them as orderly as possible.

We do that by looking all around. Which is the next topic:

Brackets

The idea is that at each rhythm to which we wish to attend, there should be “Brackets”³ that surround it. In the opening or entry bracket, we look forward, planning what we intend to do over that interval. And in the closing or exit bracket, at the end of a rhythmic interval, we look back at what really happened, learn from it, and then turn around to face in the direction of the next opening bracket.

The opening Bracket is “prospective” and the closing Bracket is “retrospective”. Open, plan. Close, assess.

We plan, we execute, we assess. The picture in the talk and article where we introduced this idea was this:

We observe the need, we do the thing, we produce the bit. And, of course, we integrate it:

Generally, most of our brackets are nested one inside the other:

{ [ (...) (...) ] [ (...) (...) ] ... }

But they need not be. For example, suppose we’re a great team and we’ve learned to slice all our features so that they can all be done in less than a week. Well, then our feature brackets will usually fall inside our weekly brackets, but sometimes a feature will overlap the weekend. So be it. We’re not requiring brackets to be nested: we’re inviting ourselves to consider what we’re going to do before we do a thing, and to consider how it went when we’re done.

One more thing for this topic, and it’s important:

Smaller is Better

It is probably possible to open and close a bracket so often that the overhead wipes out all the work. Certainly if we held a meeting every time we wanted to write a line of code, that would be too much.

Or would it? In Mob Programming, we run a continuous meeting, and everyone involved is generally there, and we write all the code, one line at a time, with open discussion and group understanding.

I would offer that if bracket time is encroaching on building time, the problem isn’t too many brackets, or brackets that are too small, it’s that the bracket itself isn’t efficient.

When we do TDD, and write the next test, that opens a bracket. When the test runs, the bracket is closed. Ship it.

Most of us who do TDD do it because it is the fastest way we know to add working code to our system. We wouldn’t do it if it slowed us down: it’s not that much fun. And when we’re on our game, we open and close a TDD test bracket every ten minutes, or every five minutes, or even faster.

How long do you want to close your eyes while driving along in traffic? Not very long, I hope⁴. The more chances we have to look around, the better our chances of seeing the important thing. The more frequently we can check that we’re on the right path, the less time we’ll spend off the track.

The trick is to keep the checks short when the cycle is short. But never stop checking. No bracket is too small. Some are not efficient enough.

Summary

Those are the Strawberries for today.

Brackets

Work in a series of prospective-retrospective time boxes that we call Brackets. Some are large. Some are tiny.

Rhythm

Let the Brackets provide a Rhythm to your work, from the few minutes between commits of code, to the few hours between releasing a feature, to the week or checking in with stakeholders, to the monthly, and quarterly, and yearly reports.

Increment

And at the close of every Bracket, from the smallest to the largest, have in hand the Increment, a running, integrated, tested, working version of the product.