Working software is at the core of success with agile methods. Let’s remind ourselves about that.

A long time back, in 2017, someone Tweeted that “Agile” really only has one idea: short feedback loops. Oddly, that thread revived itself just the other day. I beg to differ.

It is certainly true that short feedback loops are a central result of the agile style, and that they are the objective of many, most, nearly all of the notions in the Manifesto. I’ll leave it to you to work out how each line of the Values and Principles relates to short feedback cycles.

But there’s more to it than that. Perhaps the most common largeish word in the Manifesto is “software”, generally combined as “working software” and once as “valuable software”. I think it’s fair to expect that valuable software works, so I would argue that the one of the most important notions in the Manifesto is working software.

Of all the mistakes I’ve made in software product development over six decades, the most damaging was not having working software available to ship before the patience of “the big guys” ran out. Not delivering before their patience runs out tends to redound negatively as regards one’s performance review.

I’ve written around thirty articles tagged with “increment”, and I meant every one of them. In my article How to Impose Agile, I proposed a simple rule, and pledged to provide to my imaginary team, all the training and support they need to live by the rule:

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.

Since I’ve worked on almost every kind of software known to humankind, I am quite certain that it is always possible to build the product in that fashion, where there is always a running version, the Increment, embodying everything that has been chosen to be in the product, and built so far.

Since it is possible, indeed not even really that difficult, I would ask for it, expect it,demand it, and provide all the things necessary to make it so. In so doing, I could change the conversation with the big guys from “when are you going to be done” to “could you to this next?” And that would make all the difference.

Strawberry Pie

Yes. This idea, which is central to my understanding of how to do software development successfully, is far too big to be a single strawberry. It’s more of a strawberry pie.

Yesterday, I wrote about GeePaw Hill’s emerging notion of the three shadows of a software product, called for now, behavioral, interpretive, and reactive. Those shadows are too large to be single strawberries and not sufficiently lumpy to serve to keep our jam from spreading too thinly.

So much more so, the Increment: it’s the real thing that casts those shadows. It’s a Big Deal, in my view, the second biggest deal in the agile idea space.

(The biggest, surely, is the focus on people. I promise that I don’t ever forget that, even though my focus is generally on the software and how we people can do it well. I try to be kind, respectful, and helpful. But I do not imagine that I’m “good with people”. That stuff’s hard, much harder than the mere programming that I write about. We’ll go down this path later on in this series. Let’s just say that the Increment is the most important technical thing to me, and carry on.)

What’s In This Pie?

We can identify some of the major ingredients of the Strawberry Increment Pie, but most of them are still too large to be single Strawberries. Sometimes in these articles, I despair of every getting down to lumps that are so small that no one can spread them too thinly. We can but try.

The Increment Pie has to work. It has to be seen to work, both by the developers, and by the stakeholders. One of the best ways, if not the best way, to gain confidence that a program works is to test it. It turns out that tests improve not just the behavioral aspect of a program, they also improve the interpretive aspect, by serving as small stories about it, and the reactive, because a testable program is more able to be changed.
Small Steps
I suppose one half-bun way someone could claim to meet my “always have running product” rule would be to create a “Hello World” on day one, and thereafter jam all the code in there but never make it work, planning to somehow magically make it go on the last day. That just proves that people can work around any rule they choose to. But I’d fire they spawny tails, I would. The next team would do better.

The Way is, as Hill puts it, “Many More Much Smaller Steps”, and that’s a key thing to learn to do. There are surely many things to learn when it comes to creating small steps. I freely grant that I can’t always see how to do something that moves me forward in ten minutes. Sometimes a step takes me an hour. Rarely it takes me two. Sometimes I don’t manage to make a step all day. I generally know tomorrow what to do in that case.

This is a huge lump of tasty strawberries, all needing to be taken apart. There are more than fifty named refactorings in Martin Fowler’s book on the topic. There are many refactoring “moves” that we commonly use over and over, in similar yet different ways, as we improve the code.

And we must improve the code. If we were to build our product increment by just piling on more and more code, the program would become completely unintelligible and completely resistant to change: the antithesis of what we need in the interpretive and reactive shadows. And I’d bet that it would also stop working, for the hat trick.

I would almost be willing to say that the TDD loop, the red-green-refactor loop, embodies the essence of everything we need in building the increment. It’s possible that every detailed strawberry will nicely tile into that loop somewhere. But there’s more, so much more!

People Working Together

All this needs to be done in a context of the “Whole Team”, the assembly of people who know what they want, people who provide funding, people who code, people who test, even a few people who think, who knows, we might need thinking.

All this needs to be done by many very human beings working together to create the thing. These people will have to come together for many purposes, including

  • Planning what is to be done;
  • Slicing ideas down to understandable size;
  • Deciding the order of things;
  • Conceiving an architecture that can support all we need;
  • Creating a user interface concept and details;
  • Building the product, incrementally.
  • Assessing progress;
  • Adjusting the path;
  • Adjusting the practice;
  • Writing what needs to be written;
  • Drawing the pictures that need to be drawn;

It’s endless. And it’s all about people working together, despite their own independent needs and goals, in service of creation of our product.

Sprint planning meetings and retrospectives don’t scratch the surface of the human interaction that we need. Mob programming and pair programming don’t begin to deal with the sharing of understanding that has to be developed. Big visible charts and Jira don’t even start to cover our need for communication. Product envisioning and Minimum Viable Product don’t provide more than a fraction of the understanding we require of the need and the potential solutions to the need.

Are we ever going to get to the Seven Strawberries of Software Development? Not if “seven” means what I think it does.

But maybe, just maybe, we can find a sort of “outline” of what we believe in, such that out toward the ends of the branches, we’ll find just a few strawberries that apply to that part of the outline.

Strawberries seem to grow in small clumps. Maybe, just maybe, we can find the clumping that applies to our Strawberries of Software Development.

I remain hopeful.