The Agile Wilderness: Principle #3: Delivering Frequently

Agile Principle #3: "Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale." (1)

Image from medium.com (2)

Delivering frequently is one of the clearest indicators that a team is actually adopting an agile mindset or not. When you go into organizations who are unable to delivery frequently due to constraints in their technology or thinking these are immediate red flags. I want to be very clear that due to regulations some organizations are unable to take on frequent releases to customers however they can still implement ways of learning in fast frequent cycles.

Digging into the agile principle

Let's dig into this principle a bit more. First, it starts by talking about working software which directly ties to the agile manifesto value of "working software over comprehensive documentation" (3) Working software is a tested software that gives value to an end user. Any integrations needed have been brought together and are ready to ship to customers.

Image from Lukemorton.tech (4)

I think the timescale of a couple weeks to a couple months in the principle seemed outrageous at the time but now is becoming more the norm. Especially with the rise of DevOps since these were written, the timescale has changed to hours/days instead of weeks/ months for many.

Moving to a shorter timescale allows us to deliver things in smaller chunks and get feedback and learning sooner which is core to the agile mindset. Opposed to what most were doing at the time, taking 6 months to a year or more to deliver value to customers and by that point we had either built the wrong thing or what we built was no longer needed by the customer.

Comparing the agile principle to Scrum values and SAFe scaled principles

As we think about the scrum values (5) that relate to this principle it really comes down to focus. We need our team to focus on the things that will help us learn from our customers and deliver value in as small of chunks as possible. This takes a strong product owner who is ruthless in their prioritization making sure we are taking on the most important work to impact the problems we are trying to solve for our customers.

As we start looking into SAFe principles (6) we see many that apply to this agile principle as a key part of scaling is having all the teams working together to deliver frequently. Specifically, 1,2, 4, and 6 are the ones I will go into in more detail.

• 1 - Take an economic view. This really goes back to the ruthless prioritization I was just referring to above. Specifically SAFe promotes the WSJF (Weighted Shortest Job First) prioritization method in order to make sure you are taking on the things that will deliver the most value for the least amount of effort. This also allows you to have a more data driven approach to your prioritization.
• 2 - Apply systems thinking. Thinking through all the pieces of a puzzle to make sure you can work get to working software is key. You need to understand dependencies and how to work across teams as you scale so that you can deliver frequently something of value.
• 4 - Build incrementally with fast, integrated learning integration cycles. This is expanding on the point I just made with systems thinking which is that to deliver value frequently we need to work together. As we scale the need to work in the same cycle so that we can build working software frequently.

• Image from SAFe scaled principle #4 (7)
• 6 - Visualize and limit WIP, reduce batch sizes, and manage queue lengths - These are key concepts from lean that help you to improve flow and reduce cycle time so that you can deliver more frequently. Visualize and limit WIP brings insight into what is blocking work from moving forward and making sure we are not constantly task switching causing us to get very little progress made on any of the work. Reducing batch sizes means we can get things to done sooner and learn from them rather than having larger pieces that may get slowed down in being able to deliver any value. Lastly managing your queue length reduces the noise and helps you to focus on what's most important and not get distracted by a large backlog of items you won't work on for a while.

Suggested changes to the original agile principle

As mentioned in the last article about working software (8), it is key to rethink the focus on working software and instead focus on "Validated Learning". I would also update and remove the timescale and just say as often as possible. There are now teams doing this weekly or even daily. This brings in concepts of DevOps around deployment and releases being separate which you can read more about within SAFe Release on Demand. (9)

To summarize, I would update the principles to "Deliver working software as frequently as possible based on validated learning."

Closing

In closing, delivering frequently so that we continue to deliver value and learn helps drive the core of an agile mindset. If you are running sprints but still only deliver value or get validated learning once a year, you may want to look for ways to reduce batch sizes and breakdown the work further to learn sooner and adjust accordingly. Here is a summary of my thoughts on the 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 #11: Self-Organizing Teams" 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) Agile Manifesto.org

(4) Defining your ways of working by Luke Morton

(5)?Scrum Values?from scrum.org

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

(7) SAFe scaled principle #4 from scaledagileframework.com

(8) The Agile Wilderness: Principle 7: Working Software

(9) Release on Demand from scaledagileframework.com