A team that can’t ship can’t learn.

Concourse, a CI Board. Photo via the Concourse blog

There are two questions you have to ask when considering shipping software:

  • Can we ship?
  • Should we ship?

“Should we ship?” is ultimately a business decision. Is it valuable to the business to put the latest features in the hands of the users right now? The product manager (PM) represents the business interests on the team and must own this decision.

However, the question “Can we ship?” is fundamentally an engineering question. Is the software in a working state? Are we confident it won’t fail in production? The goal of the XP engineers is to always — ALWAYS — have a “yes” answer to this question. A team that can’t ship, can’t learn. And the longer you’re not learning, the greater the risk that you’re wasting time and money building the wrong thing.

The combination of three XP practices make it possible for teams to always have a “yes” answer to the question “Can We Ship?”:

  • Stories
  • TDD
  • Continuous Integration

What’s a story? It’s a little description of how a user interacts with the system. It’s the smallest piece of user value that you can put in front of users to learn from. You believe that the feature described in the story, on its own, provides value to users. It can’t be demoware or vaporware. It has to be real. It doesn’t need to be a lot — just enough to test your belief.

If your backlog consists of stories that conform to this definition, and your engineers only commit implementations of those stories once the team (PM, Designers, and Engineers) agree the implementation completes the story, then you’ll never have any half-implemented features in the build.

But does the software work? Well we’ve already talked about how XP engineers answer that question: they TDD. Any pair, on any pairing station, at any time, can run the tests to determine if their copy of the code works — if all of the features of the product work correctly. But on a big team, you have lots of pairs working in parallel, and therefore the codebase exists in multiple states simultaneously; the tests might be passing on one pairing station, but failing on another. That’s where we get to continuous integration (CI): the team needs a single source of truth that they can point to in order to answer the question “does it work?” Every time a pair pushes up their code, a new CI build gets triggered. And if the CI build is green, it works. You can ship the software. Now the PM has to decide if the team should ship the software.

It’s worth noting that some PMs automate their decision with respect to shipping. Some always have the default answer: “Ship on green.” In effect, they’ve asked the engineers to add another step to their build pipeline to automatically promote code to production on a green build. That’s called “continuous deployment.” However, although the mechanics of it are facilitated by engineers, shipping is still a business responsibility. The default answer of “ship on green” doesn’t abdicate the responsibility of the decision to the engineers. The PM still has the responsibility of understanding how the features are working in production and how users are responding to it — which means the PM has to prioritize all of the engineering work necessary to build automated production monitoring capabilities that make continuous deployment responsible.