What does the 3rd Agile Principle (Frequent Delivery) look like in Action?

Many want to go Agile or claim to be Agile. The question is, are you and will you align with the Agile values and principles? In this article, I expand on the third principle to better understand what it means and attempt to identify what evidence looks like to determine if a culture change may be occurring. What is this principle?  

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale is the third Agile principle. This principle promotes the ability that when customers believe there is value in what is built, it can be immediately delivered. Identifying the elusive customer value means you can release it when the customer wants it. If it is delivered too early, the customer may not be ready for it; if it is too late, the market opportunity is missed. 

Agile thinking includes a fluid world, where changes are continuous welcome, and teams have the capability of releasing frequently. This ability to frequently release, highlights the importance of having processes and infrastructure to help with continuous integration, build, and test. This ability assumes a level of automation that needs to be in place. Automated testing increases the possibility of testing the functionality as is reasonable, including the capability of performing non-functional testing such as performance testing, load testing, and more. 

What actions exhibit frequent delivery?  

• An established and positive relationship with customers
• Iterative framework with Sprint Reviews to incorporate feedback quickly 
• A release capability to incrementally and rapidly deploy software 
• Continuous integration supported by a merging process and configuration management system 
• A continuous build process supported by an automated build management system 
• Test automation infrastructure that can support continuous testing  

It is up to you to determine what supporting evidence will highlight that continuous integration, build, test, and frequent delivery is occurring. It is worth experimenting with this as it will help you better understand and embrace the Agile principles. The ultimate question, do you really believe in the principle that focuses on frequent delivery?

-------------------------------------------------------------------------------------------------

To learn more about what the Agile Principles look like in Action, consider reading:

• 1st Agile Principle (Satisfying Customer with Valuable Software) at: https://cmforagile.blogspot.com/2023/09/many-want-to-go-agile-or-claim-to-be.html
• 2nd Agile Principle (Welcome Change to Requirements) at: https://cmforagile.blogspot.com/2024/01/do-you-have-evidence-to-support-2nd.html

There is no Success or Fail, only Learn

I have been in discussions both in-person and on twitter with colleagues on whether we should use the word “fail” or “learn”.  This was in context to projects (aka, releases, increments).  Did they failed or did we instead learn.  I also realized that the term “fail” is somewhat subjective (e.g., did the whole project fail or just parts of it?).  The overwhelming agreement was that “what did we learn” was a better way to discuss the findings or results. This lends itself to a shift in mindset, to a continuous learning environment that recognizes that there is value even in the negative feedback.   We can learn from that feedback and adapt for better results in the future. 

Then it occurred to me, the term “success” was also a bit subjective.  I recall reading a Standish Group Study where those projects that were “deemed” successful, 45% of the features were never used.  Another 19% was rarely used.  This meant that projects deemed successful built 64% never or rarely used features.  That seems to be a very loose definition of what “success” looks like.  In addition, how many projects are deemed successful because it met the scheduled deliver date yet few customers upgraded to it or bought it?  Is there a benefit to use the term “learn” in place of success?

While it may sound feel like the terms success or fail are the way to traditionally judge a project, release, product, or service, we lose sight of the most important result of the work, the feedback and what we learned from that feedback.   This learning helps us adapt to achieve better results.  If you are working in an Agile context where there are short increments of work, there is the benefit of continuous learning where you can continuously adapt for better business results.

I would suggest in the modern lexicon of work, when a project, release, or increment of work is done, it is much more important to ask what was learned instead of classifying it as a success or failure.  This strengthens the mindset within the organization that there is a value in feedback and the most important thing is what did we learn.  It also emphasizes a discovery mindset where what we think a customer wants is really a hypothesis that must be explored.  It is in the learning that can help us lead to better business results in the future.  So next time people talk about a project as a success or failure, instead turn the discussion around and ask “What did we learn”?