Agile Principle #3: Deliver Working Software…a Lot.
By: Goodspeed
Tags: Software, Agile, Scrum, Development, Software Development

Agile Principle #3: “Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.”

Before agile and Scrum became the way hyper-efficient software development teams operate, waterfall project management philosophies were rampant, most likely an artifact of industrial and manufacturing industries that fueled the economy before the digital revolution. On these projects, large phases of Analysis > Requirements Specification > Design > Development > Testing & Integration > Deployment were commonplace. Engineers were often handed 100+ page specification documents that took months of research and iteration to complete, even longer to code, and several more months to test and deploy. It was not uncommon for the entire software development lifecycle to take 8–to-12+ months (true story — I have personally worked at a very large industrial organization that struggled to release new code to production just once per year).

Image courtesy of prodigi.io.

Given the fast-paced nature of web-based technology, waiting even a couple of months before users experience new functionality can be catastrophic to a project’s success. Markets shift, user preferences change, businesses reprioritize their strategic focus, original assumptions are proven inaccurate, etc. Agile software development represents a paradigm shift away from old-world project management thinking toward delivery of large projects in small chunks of work in an effort to dramatically reduce the risk of project failure.

Deliver working software…

The software you deliver on a regular cadence must work (duh), but what does work mean? This entirely depends on your team’s Definition of Done, which represents the minimum set of requirements that must be met by the work you do before releasing it to a production environment. This definition is applied to the context in which your team operates, but typically includes things like all acceptance criteria have been validated, unit test coverage is at least 80%, code is merged and all unit/functional/etc. tests are passing, the product owner has validated and approved the work, etc. Whenever possible, don’t deliver half-done software, which implies that technical debt has been accrued that must be paid at some point in the future — the code produced each sprint should be production-ready and just plain work with no further action required on behalf of the development team.

…frequently…

Delivering software frequently enables short feedback loops whereby new functionality is incorporated into the product in smaller increments, significantly reducing the risk that large, expensive changes are introduced late in development.

Image courtesy of aayushjain.com.

Reducing the size of the “leap of faith” is key to how agile helps reduce risk compared to traditional methodologies. Further, by introducing change frequently, organizations signal that they are listening to their users and value their opinion by engaging them as active participants in the product development process.

…from a couple of weeks to a couple of months…

With the recent evolution of DevOps and CI/CD technologies, this portion of the 3rd agile principle seems a bit dated. Deployment timescales have shifted away from months or even weeks toward continuous deployments — often several times a day for the most efficient organizations. In general, the shorter the timescale, the smaller the “leap of faith” and lower the inherent risk of failure by introducing new code that needs to be fixed, functionality that users don’t like, etc. Combine this with advanced A/B and canary testing and the risk is nearly eliminated.

…with a preference to the shorter timescale.

The shorter the timescale, the sooner in the software development process we are able to receive feedback from real users. The sooner we get this feedback, the sooner we can incorporate changes into the product to optimize their experience. The more optimized the experience, the more likely they are to stick around, tell friends, etc. and help your organization succeed.

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

While a vast majority of engineering teams operate within the Scrum framework and execute sprint after sprint (after sprint), it’s important that we take a step back to understand the bigger picture — the path to success more closely resembles that of a marathon. Winning this race requires constant close collaboration with your users as frequently as possible. While iterating quickly means shipping new features more often, it’s important to understand all of the levers available to you get there and the impact they have on delivery speed and throughput. In this marathon, every small optimization counts toward increasing the frequency at which you can iterate and ultimately help your organization succeed in the long run.