There are two questions you should ask before shipping software:

  • Are we able to ship?
  • Should we ship?

“Should we ship?” Is a business driven decision. Is it valuable to your business to put this latest feature into your users hands?  Your product manager represents the business interests on the team and should take this decision.

But for the question “Are we able to ship”, it is fundamentally a technical question. Is the software working?

Are we confident it won’t fail in production? The goal of the team engineers is to make sure they can and fully answer a “yes” to this question. In a nutshell, if your team cannot ship, it’s hard to learn. And the longer you’re not learning, the greater the risk that you’re wasting time and money building the wrong thing.

To be able to always have a “yes” to “Are we able to ship”, here are two practices to make it easy:

  • Stories
  • Continuous Integration

Stories

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.

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.

Teams that practice Extreme Programming (XP) believe that the best software is built through a process of learning, which requires them to continuously deliver software into the hands of users, get their feedback, and iterate on the product in response to that. Consider these two graphs of team speed over time, and ask yourself which team you want to be on:

You can’t do that if you’re on that first curve. You need the second curve. You need to GO FAST FOREVER. There’s lots of reasons a team slows down. But there’s one thing that will always slow a team down: bad code.

Continuous integration

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.

(Source: builttoadapt.io & content.pivotal.io)