This article makes a very simple and key point about Agile Software Development, and about Scrum.

If you are not producing working, running, tested usable software in every single Sprint or iteration, you are not [yet] “doing” Agile, you are not [yet] “doing” Scrum.

You might be on the road – if you are working hard to get to the point of working software in every cycle – but you are absolutely Not There Yet.1

A second point is that if you’re not doing Agile or Scrum [yet], it is not appropriate to say that you are.

A third point might be that if you’re teaching or coaching Agile or Scrum, and you let the focus on working software slide … well, let’s just say that I have a serious problem with that.

We’ll begin with some direct quotes from the Manifesto for Agile Software Development and the Scrum Guide as of today.

Manifesto for Agile Software Development

The “Agile Manifesto” includes four values and twelve principles. One of those values refers to working software and three of the principles do as well:

Working software over comprehensive documentation

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

Working software is the primary measure of progress.

Scrum Guide

The Scrum Guide is jointly recognized by all the main Scrum associations as the official core document for Scrum. It is co-written by the creators of Scrum, Jeff Sutherland and Ken Schwaber. Here are some of the things it has to say about working software, which Scrum calls “the increment”. Emphasis in the quotes below is mine.

The Increment

The Increment is the sum of all the Product Backlog items completed during a Sprint and the value of the increments of all previous Sprints. At the end of a Sprint, the new Increment must be “Done,” which means it must be in useable condition and meet the Scrum Team’s definition of “Done”. An increment is a body of inspectable, done work that supports empiricism at the end of the Sprint. The increment is a step toward a vision or goal. The increment must be in useable condition regardless of whether the Product Owner decides to release it.

The Development Team

The Development Team consists of professionals who do the work of delivering a potentially releasable Increment of “Done” product at the end of each Sprint.

The Sprint

The heart of Scrum is a Sprint, a time-box of one month or less during which a “Done”, useable, and potentially releasable product Increment is created.

Sprint Planning

Sprint Planning answers the following:

  1. What can be delivered in the Increment resulting from the upcoming Sprint?
  2. How will the work needed to deliver the Increment be achieved?

Sprint Review

A Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed. … the presentation of the Increment is intended to elicit feedback and foster collaboration.

The Development Team demonstrates the work that it has “Done” and answers questions about the Increment;

Definition of Done

Development Teams deliver an Increment of product functionality every Sprint. This Increment is useable, so a Product Owner may choose to immediately release it.

Each Increment is additive to all prior Increments and thoroughly tested, ensuring that all Increments work together.

We have to create working software

I’m almost inclined just to rest my case. The source documents, it seems to me, are as clear as day.

Working, tested, runnable, shippable software is absolutely central to the ideas in the Manifesto for Agile Software Development, and to the ideas in everyone’s favorite “Agile” framework, Scrum.

There is no getting around it. If you’re not delivering working software on a short cycle, you’re not there yet.2

But let’s do talk a bit about the likely impediments to getting working software that a team might be laboring under.

Pressure

My esteemed colleague John Miller, in a recent tweet, referenced a team who felt that “things take time, and pressuring developers to deliver in every Sprint is unsafe”.

Pressure does not help teams go faster.3 It causes them to become nervous, to take shortcuts, and to make mistakes. This slows you down. It does not speed you up.

And yes, if a team perceives that management is all about “whipping the ponies harder”, they will not thrive, and they will not learn, and they will be less capable than they would have been without being under the whip.

So yes, safety is a prerequisite.

Knowing How

Counterintuitively, having software working and ready to go every couple of weeks really isn’t that hard in almost every domain.4 It is, however, something that you have learn about, and there are things you need to do. Most of those things are common across all domains, though they are done a bit differently in every situation, as you might expect.

A really dumb example

Let’s consider a stupid example, one of my favorite tricks. Can the team build and test the system, with no changes, inside a Sprint?

If not, work on that. But very few teams need more than two weeks to build and test. Perhaps there is a lot of manual testing that is taking the time? Work on that, slicing the testing down to key bits, automating, and so on. Pretty soon, you can build and test a no-change version inside the Sprint.

Now then. Here’s your backlog item. “Change the message ‘Please log in’ to say ‘Please enter your credentials’. Then build and release the system.

I would bet that we could find that message, change it, and then run our two-week build and test and have a shippable increment.

“But that’s stupid, we’d never get anything done.”

Yes, but you’re already not getting anything actually done, so this is better. And now, we continue to improve the build and test, and continue to put in little tiny stories. Our real target point is probably to get the build and test down to two days, then to one day. If it were two days long in a one-week Sprint, we could add features for three days and then build and test for two and voila! working software.

“But what if one of the things we build doesn’t pass the tests?”

Two things: First, that story isn’t done, inspect and adapt and figure out what to do. Second thing, I can tell you right now that whatever testing we did on that story wasn’t good enough so we’ll inspect and adapt our testing, until we become quite certain, when we put a story into the build, that it isn’t going to break anything.

Now if we’re working on the worst legacy code in history, this would be difficult, and it would take some time … but we could do it.

Or don’t do it

It’s OK to decide “In our process, we’ve decided not to ship working software in every cycle”. It’s not OK, in my view, to call your process “Agile” or “Scrum”, because both Agile and Scrum are absolutely clear about delivering working software.

Call it Software-Free-Agile or Near-Beer-Scrum or something. If you’re really working hard to deliver working software and just not there yet, call it “Working-Toward-Agile” or “Slouching-Towards-Scrum”. Acknowledge the truth of where you are, and where you’re heading. Don’t water down the truth for yourself or others.

When you’re not there, don’t say you’re there. It won’t work well.

Learning is Required

Delivering working software in every cycle isn’t deeply difficult. Any team I’ve ever encountered could readily learn to do it. They did need space provided, what John Miller referred to as “safety” in his tweet. And they very likely need a bit of education.

There is a particular trick to the working software cycle, as I prefer to do it. It goes like this:

  1. Start with working software. Ideally an “End Card”, ideally bug-free, but something that runs. Your existing legacy product will do if that’s all you’ve got.
  2. Select a very simple next feature to do. No, that’s too big, even simpler. There you go.
  3. Write an automated example that will fail until that feature works, and then succeed. If it requires more than one example, go back to #2.
  4. Start programming: Run the example; add some code; run the example; every time the example runs, refine and improve the code a bit. When you’re satisfied with the example and code quality, that bit of feature is ready to ship.5
  5. You’re back to working software, with a new feature. Go to 2.

Really. This is the so called Test-Driven, or Example-Guided, or Behavior-Driven development cycle. It feels slow at first, but it has the delightful property that if your examples are good, and they run, the feature in question is correctly implemented. You can submit it to the build and test with confidence.

Sure, sometimes you’ll stumble and need to figure out better ways of writing and running the examples, but there’s no magic to that.

Conclusion

More detail on how to ship working software is out of scope for this article. Check this site’s categories for the tag “tdd” and after checking those, you’ll find categories and tags for other related articles.

The point here is really simple, as I said at the beginning:

If you are not producing working, running, tested usable software in every single Sprint or iteration, you are not [yet] “doing” Agile, you are not [yet] “doing” Scrum.

No software: No Agile, No Scrum.

Those are the rules. Govern yourselves accordingly. Thanks!


  1. Are we there yet, Daddy? Not yet, kids, not until we get some working software out of this thing.

  2. Now are we there yet, Daddy? No, kids. We’re not there until you show me the software.

  3. Perhaps in tiny amounts, pressure helps. I doubt it even then. In larger quantities, no help at all, just trouble.

  4. In my over half-century of working in software, I’ve worked in many domains, and worked with teams in many others. Really: there are few if any domains where you can’t learn to do this.

  5. Thanks to Dan Terhorst-North for the word “example”.