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

The Meta of getting to Small in an Agile World

If you are Agile in the Product delivery and software development space, there is strong emphasis on thinking small.  This means decomposing work to small pieces to allow for iterative and incremental delivery and eventually the continuous flow of work. While this sounds straight-forward, in practice, it is hard because it disregards the challenging mindset shift that must occur to get people to think small. 

It is important for Agile teams, coaches, and leaders need to understand for those who have never decomposed their work to “small” size chunks, they have little idea what that means and it may take time. This article focuses on several reasons why “decomposing the work to small pieces” is challenging and the meta surrounding the concept of small.

Small is mindset shift  

Imagine that you have never considered what is small and someone says, “think small!”  This is meaningless without any context or experience in “getting to small”.  To achieve the concept of understanding small bite-sized pieces or work, there is mindset change that must occur.  Imagine if you were piloting a plane for the first time and your instructor says, you must go “fast” to take off.  What does fast enough mean if you’ve not done this before? If you only ride a bicycle, then fast may mean 25 mph (or 40 kph). However, in order to take-off, fast means 75 mph (or 120 kph) for a propeller plane and 170 mph (or 275 kph) for a jet.  There must be a strategic steps to shift the mindset to think differently that includes allowing the team time to learn and experience their way to small. 

Small is Relative 

What is “small” will be different depending on the type of work a team is doing. There is back-end, middleware, front-end work and more. Each team must gauge what is small based on their work. Also, what is small will differ from team to team and is relative to team size, talent, and experience. What is small must be specific to each team. Management must not compare sizes across teams as this will deteriorate the relative sizing for the specific teams.

  
Small is Complex 

Creative work like building new products and services (or features therein) are considered complex (per the Cynefin framework) as there are unknowns and “unknown unknowns”, ergo requiring a "probe–sense–respond" approach.  Many will translate small to days of work. But translating small to time of work disregards the complexity and unknowns of the work. In an Agile world, we consider not just effort, we look at complexity of the work (e.g., what is known and unknown), and any risks involved in the work (e.g., what skills, experience, tools, infrastructure a team has and more specifically what they don’t have.  What this means is that to identify small work, you must look at effort, complexity, and risk so it isn’t straight-forward.

Small is Imprecise 

In an Agile world, we don't pretend to think that we can have precision in our sizes. We want good sizes but we have to move away from the traditional mindset where we think we can provide accurate estimates. If it isn't correct, this is actually okay as we’ll soon learn more about the work.  When you size the work within an iteration (aka, sprint) and the iteration is done, you will quickly build a historical database of sizing and will learn more about the work.  The very next iteration, you will have learned whether you were over or under for a size and when similar type work comes along you have input for the future sizing of work.  In other words, “don’t sweat the sizing”. 

Summary

When transforming to Agile, there is a shift to to small pieces of work allowing for iterative and incremental delivery of the work. Small is challenging for teams that have not had to work decompose to small. Understanding the meta around getting to small can help coaches, teams, and leaders navigate the challenges knowing that it is a mindset shift, it is imprecise, it is relative to the work and each team, and is complex.