The Agile Wilderness: Principle #7: Working Software

Agile Principle #7: "Working software is the primary measure of progress." (1)

Image from medium.com (2)

Delivering working software is a great starting point from where we were in waterfall but now, we have found ourselves in a build trap. Melissa Perri wrote a great book about this in "escaping the build trap" (3) where she talks about the importance of not just delivering features and instead focus on solving customer problems to reach the outcomes we want. So many features are created that no one uses creating over-complex systems to support making them harder to maintain or change. In the end, making us less able to adapt to the needs of our customers and actually solve the problems and reach the outcomes of our organizations.

Digging into the agile principle

With that said, this principle got people to move in the right direction. Working software was not something we ever saw in waterfall until the whole project was done. This principle points out that a project has really made no progress until something is in production that a customer can use. In waterfall, this usually meant at least 6 months to a year, and most of the time did not meet the needs of customers even if the requirements were followed perfectly.

The second part of the principle calls this the primary measure of progress. I appreciate what this was trying to accomplish however I believe this caused a short-sighted view to not validate what we built. We made progress by shipping features, which is better than just documents, but we still had no idea if what we built was solving the problem for the customer and impacting the outcomes we wanted to reach.

Comparing the agile principle to Scrum values and SAFe scaled principles

As we compare this principle to the scrum values (4) we see both courage and focus are needed. We need to have the courage as a team to dig into the hard problems and pivot when what we think will solve the problem doesn't. We need focus to dig into the problem at hand and discover what the real issues are through continuous discovery. This focus then helps led us down a path to solve the real problem for the customer. See "Continuous Discovery Habits" by Teresa Torres (5) for more on this.

SAFe scaled principle 5 (6), "base milestones on objective evaluation of working software", incorporates the feature delivery into a scaled practice. Although basing milestone on working software is helpful and more accurate than an initial estimate, it still does not tell us what we plan to build will actually have the impact we expect and is still just a forecast.

Suggested changes to the original agile principle

This fault of focusing on working software instead of actually solving customer problems started at the beginning in the agile manifesto. Therefore, I would update both the manifesto and this principle to "Validated Learning" instead of working software making this principle "Validated Learning is the primary measure of progress". Validated learning is the ability to test your assumptions around your solutions, making sure what you build will actually solve the customer problem before spending time building the entire solution. You start by digging into what the true problem is and then do hypothesis tests to validate if what you think will solve the customer problem actually will. This then leads you to delivering things that will impact the outcomes you are trying to reach rather than just building things you think "might" work and having a pile of features no one uses in your product.

Closing

In closing, working software was a great starting point but we now see teams stuck in a build trap where they are pumping out features with little to no discovery of the true customer problems. Validating our assumptions about our customer problems through learning is our key measure of progress. Here is a summary of my thoughts on this principle for reference:

I hope you have enjoyed this article and as always feel free to reach out to discuss further or drop a comment below to join the discussion. Thank you for your time and look forward to sharing my thoughts about "Principle #3: Deliver Frequently" next time.

About the Author

Jeff Mortimer?(#theAgileMoose ) is an Agile Enthusiast with over 10+ years of experience working in various roles on agile teams including business analyst, product owner, scrum master, team leader, technical delivery manager and now an agile coach consultant focused on product transformations. In additional to his certifications in CBAP, AAC, CSP-PO, SAFe Agilist and SAFe LPM, Jeff?has presented at several conferences throughout North America and joined the blogger universe a couple years ago to bring a voice to the everyday agile practitioners. He also just received his EMBA at Quantics School of Business and Technology. He is a husband to an amazing intelligent wife who has her doctorate in math education, father to kids who bring him joy every day, friend that brews beer and plays soccer, and citizen who helps organize volunteers to give back to the community.

Follow #theAgileMoose for the latest insights in the agile wilderness.

References

(1)?Agile Principles ?from agile alliance

(2)?Principles Image ?from medium.com

(3) "Escaping the Build Trap " by Melissa Perri

(4)?Scrum Values ?from scrum.org

(5) "Continuous Discovery Habits " by Teresa Torres

(6)?SAFe Scaled Principles ?from scaledagileframework.com