3 Ways to Be More Agile With Software Shipping Decisions
The agile development community gave up on the idea of 'approving' specifications and designs about 10 years ago. The next thing to go may just be the when-to-ship decision. As software release schedules are increasingly compressed, here are three ways to rethink the ship/no ship decision.
Tue, February 05, 2013
The story, taken from Spolsky's experience as a program manager at Microsoft, does more than illustrate the point of employee empowerment, of the "single wringable neck" for one product. It also illustrates the idea of a fluid set of requirements: An exact feature set can change over time. The Agile Manifesto reflects these values, emphasizing "responding to change over following a plan" and "working software over comprehensive documentation."
This idea is not universal. Plenty of medical and physical device companies get but one chance to install their product; for them, a specification continues to be an important part of the process. For software delivered in increments, though, the idea of a comprehensive requirements document with formal signoff can seem downright archaic, a relic of the previous century.
Today, requirements are often fluid, and the signoff decision a memory. The next step to fluid software is to eliminate the ship/no-ship "approval process." And it's happening right now, often in one of three ways: continuous deployment, team-wide consensus and testers serving as de facto staff officers.
1. Continuous Deployment: Push Code to Production With Each Commitment
Agile compresses the release timeline from months to weeks. Continuous deployment shrinks it further by asking, "What would it take to release to production with every commit?" It's being used by real companies, including Flickr, Twitter, imvu and Etsy.
Moving to continuous deployment means more than hooking up a build system and finding ways to upgrade without rebooting the server. It means the technical team needs to have code that is near production-ready with every commit.
Last year I went to Brooklyn to learn about continuous deployment at Etsy, and I was amazed at the takeaways:
- Most code is rolled to production "dark" (not executing), then activated over time with the use of configuration flags.
- The company invests heavily in monitoring and branching infrastructure in order to catch problems quickly.
- The tools group makes up a large percentage of the developer team and has a great deal of infrastructure to sense, fix and push fixes to production quickly.
- Since Etsy is PCI complaint, code involving credit cards, money and customer data goes through a more formal process.