3 ways to be more agile with software shipping decisions

By Matthew Heusser, CIO |  IT Management, Agile, project management

I laughed. Even though I had only been at Microsoft a few months, I knew that there was no such thing as somebody approving my spec. Hell, nobody had time to read my spec, let alone approve it. The programmers were bugging me every day to get them more pages so they could write more code.- Joel Spolsky

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:


Originally published on CIO |  Click here to read the original story.
Join us:
Facebook

Twitter

Pinterest

Tumblr

LinkedIn

Google+

Answers - Powered by ITworld

ITworld Answers helps you solve problems and share expertise. Ask a question or take a crack at answering the new questions below.

Join us:
Facebook

Twitter

Pinterest

Tumblr

LinkedIn

Google+

Ask a Question
randomness