Increment? What's that?

Scrum asks for an Increment every Sprint. Of all the Scrum rules, this one is most important for developer success and survival.

Let’s pick some relevant quotes from the current Scrum Guide:

An Increment is a concrete stepping stone toward the Product Goal. Each Increment is additive to all prior Increments and thoroughly verified, ensuring that all Increments work together. In order to provide value, the Increment must be usable.

Developers are the people in the Scrum Team that are committed to creating any aspect of a usable Increment each Sprint.

The whole focus of Scrum is on incrementally producing the product, delivering a verified, integrated, usable “stepping stone” in each Sprint.

I’m tempted to amplify at great length each of the key words here, verified, integrated, usable. I’ll spare you that: you can find me doing it in many other articles with the same categories and topics as this one. In this short article, I have one goal: to describe why the Increment is the most important Scrum element for developer success and survival.

In the olden days, prior to Scrum, when we undertook a software project, we’d go heads down for many weeks or months, doing our best to build the thing. We’d have to give reports, most likely, and they would say things like “Design 45% complete” and “Coding 80% done” and “Testing 15% done” and “Only 1434 bugs remaining”.

Only near the end of the project, and after the deadline, did the pressure really come down. For much of the project, development work could be about development. Much of the time, things weren’t too bad.

Scrum changed all that.

Now we have to get together every week or two–hell, we get together every DAY–and say where we are and how we’re doing and if there’s anything in our way. And at those review meetings, they can interrogate us and ask us why we aren’t done and when we will be. And, all too often, in each Sprint they ask us to estimate all our work, and to explain why our estimates are’t correct.

The technical term for this situation is “This sucks!”

What Scrum is asking for can change the game, if only we can do it.

Scrum is asking us to show up at the review meeting, every single Sprint, with a new Increment, tested, integrated, and usable, containing all the work that has gone before.

That changes everything. With even the meager showmanship of the average programmer, we can put the software, working and usable, at the center of the conversation.

“How much is done?” “This much: look at it!”

“When will it all be done?” “What would you like us to do next?”

“When can users have it?” “Now: it’s usable.”

“It needs to do more!” “What would you like us to do next?”

When faced with a usable but incomplete product, even the most root-pulling, pony-whipping stakeholder can’t long resist figuring out what few things might actually be able to satisfy some customers, solve some problems, get some sales.

It’s not perfect. Nothing is perfect. But it’s a heck of a lot better than what happens when we show up with nothing but slides and the old soft shoe.

But it’s hard to do!?!?

Yes, I know it’s hard to do. I also know that it isn’t as hard as it seems, and it’s well within reach of almost any team on almost any product. The elements of getting it done should be familiar to any reader of my innumerable articles. Some of the key elements include:

Slicing Stories

No matter what they call your requirements, stories or demands, the same thing needs to be done. Slice down each request into small enough slices that each one can be done inside a Sprint. Ideally, in a day or two. Each slice should go from top to bottom of the application, from an initially rudimentary user interface to an initially elementary data store.

Continuous Testing

Because we are building this this incrementally, we’re going over and over the code, improving it and extending it. This will inevitably break things. We need to continually grow a scaffolding of tests that show us that the new things work, and the old ones haven’t broken.

And those tests have to be fast. We have to learn how.

Continuous Integration

We can’t wait until the last half day before the review meeting to bring our work together into one integrated Increment. That trick never works. We need to integrate daily, hourly, all the time.

At first, this will be hard. Soon, we’ll learn to work in tiny working steps so that we never “break the build”.

Incremental Infrastructure

We can’t wait for weeks to build up the entire database structure, or the 16 AWS servers that we’ll spin up. We need to build up all our infrastructure incrementally, so that with every Increment we have more user function and more infrastructure.

This, too, requires us to learn how. Good OO design, in-memory databases, clean interfaces where network calls will someday be. Quite doable, and rather fun to figure out.

Incremental Design: Refactoring

Obviously, if we deliver an Increment after the first week, and every week thereafter, the complete and full design of the end product will not be figured out in that first week. We can, however, figure out a design that will support the work of a single week. And we do that every week: slice off just enough new capability to permit us to enhance the design just enough to support the new slice.

Again, this requires skill.

Hard to do? Not once we know how.

In a green-field situation, I’d advise a team to build some tiny increments, maybe even tossing them out as they learn, but always building a discernibly better one in the next Sprint. They would rapidly learn how to do small stories, test them well, design just enough, and keep things moving forward.

They would start slow, and gain speed as they learned.

In a brown-field situation, it’s definitely harder. We’ve probably horked up the design, we probably don’t have enough tests, our build runs for ages, and writing a new test takes longer than writing the code and debugging it.

It’s possible to turn the situation around. We have to take on less “work”, focus on improving the build and tests, improving the code and its underlying “design”, and essentially work our way out of the hole we have dug for ourselves.

It’s hard, but it’s possible.

And, to me, if I want my life ever to be enjoyable again, it’s necessary. Otherwise, I have to face those root-pulling pony-whipping sons of darkness every week and have my roots pulled and my poor pony back whipped. I don’t like that. I hope you don’t like it either.

Some of us can move to new situations. Most of us cannot.

We need to do just one thing:

Learn to Build the Increment

It can be learned. The basic techniques are those of XP, Extreme Programming. You can read about them here, you can watch me apply them as best I can in my articles. You can find videos and books on the subject.

Most of all, you can learn what these ideas really are, and practice, Practice, PRACTICE.

You can learn to do this.

Will Scrum Help Us?

Well, maybe. The Scrum Alliance “Certified Scrum Developer” program includes learning objectives that, if you were to attain them, would equip you nicely to do this. The Scrum.org Professional Scrum Developer program has similar objectives.

Unfortunately, there aren’t many Scrum Alliance offerings or Scrum.org offerings that will take you all the way. As far as I know, there are none. But there are some good offerings.

If you can find a CSD class of three days or more, and if you ask the instructor whether there is actual programming in the class, and there is lots of programming, you may well get a good taste of what has to be done. Even the best such classes¹, even the five days ones if you could find one, give only enough of a taste to let you know what doing it right feels like, and to show you why you’d like to work that way.

Then you practice, Practice, PRACTICE.

What about a class with no programming? Well, I haven’t taken one and I wouldn’t offer one, but, given my ignorance, I certainly don’t know how much value they’d have. Check the learning objectives and see what you think.

My own advice would be to look for videos from Bill Wake, James Shore, J B Rainsberger, Dave Farley, GeePaw Hill, and the likes of those.

But the main thing is to recognize that you and your team need to know how to deliver the Increment, and by hook or crook, learn to do it.

You can, and in my view, it’s a life-changer when you do.