Why Frequently Delivering Working Software Is Crucial to Agile
One of my favorite agile principles is “Working software is the primary measure of progress.” Unfortunately, many agile teams ignore this principle, instead focusing on collaboration, organizing self-directed teams, and performing agile ceremonies. While all the agile principles are important, without producing working software on a regular basis, the others won’t matter.
Traditional software development processes use the completion of requirements, specifications, and high-level design documents as evidence of progress. While completing documentation is often an indication that some progress has been made, until software has been implemented, tested, and approved by a customer, the amount of progress cannot be measured.
I’ve seen many nonagile teams merrily marching toward release believing they are on budget and schedule only to find out late in the process that the software does not scale, isn’t secure, or just isn’t what the customer wants anymore. The only way to measure progress accurately is to produce working software. After all, software is the only deliverable that absolutely has to exist!
Here are some common reasons I see for failing to frequently deliver working software.
No agreement on the definition of “done”: Negotiating what “done” means during sprints won’t work. The team needs to agree on a definition of “done” for individual stories, sprint completion, and releases prior to starting the first sprint. Otherwise, there is temptation to modify what “done” means every sprint so the team can declare victory.
When this occurs, not only is progress not as measurable, but the team never learns how to accurately estimate work and improve its process. If the team determines that the definition of “done” created up front isn’t working, it can change that definition during the development process. Just be careful that you are doing that for the right reasons instead of as an excuse.
Fear of repercussions: Teams are often afraid that if they don’t deliver what is promised (agile doesn’t make promises, by the way), they will be punished . Middle management will push for agile delivery against a release schedule mandated from above, and this may drive teams to say software is done when it is not.
Without a fear-free environment, teams will never focus on the root cause of why they are not successfully completing software development and will not get to fix the underlying problems.
Developers and testers do not work together collaboratively: Without fundamentally changing the way software developers and testers work, it is difficult to produce working software each sprint. Attempting to run sprints as “mini waterfalls” will ultimately result in needing to increase the size of sprints or shift testing into future sprints, each of which elongates feedback cycles and begins a slow progression back to a waterfall process.
Measuring progress based on the delivery of working software encourages and enables many of the other agile principles. Without it, you will likely not successfully build high-quality software using agile. Watch for signs that working software isn’t your team’s focus, as that will ultimately lead to quality and delivery problems.
