Agile Principles: Flow

This is the last of three articles covering the Agile Principles; in the last two, I wrote about High-Performing Teams and Time to Value. This post will expand on the concepts of Flow and Throughput, which I see represented in the following principles from the Agile Manifesto.

Flow and Throughput

• Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
• Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
• Continuous attention to technical excellence and good design enhances agility.

I like the concept of Flow because it implies constant force and motion.

It's important to measure the total output as well as the velocity. Products are alive; it means they are (must be) changing constantly, responding to market trends and customer needs. The product is born when the project goes live.

Definition of Throughput

According to OxfordLanguages, Throughput is the amount of material or items passing through a system or process. Under the lens of Lean Manufacturing, "throughput is a term used to describe the rate at which a company produces or processes its products or services (Investopedia)."

Definition of Flow

According to the Scaled Agile Framework (SAFe), "flow is characterized by a smooth transition of work through the entire value stream with a minimum of handoffs, delays, and rework (SAFe)."

Although both concepts are related, I view Throughput simply as a measure of output. On the other hand, Flow has a deeper meaning and can be connected to the project and the state of work (performance and engagement) of the team and its members.

Accept Change

A very important aspect of this principle is the capability to adapt and change course. These changes might come from different places: business stakeholders, customer needs, external requirements, or just unplanned work that is needed to keep the product going.

Constant Pace

Flow cannot be observed and measured only at the technical level. It must cover the entire product lifecycle, from the initial idea (hypothesis, requirement, etc.) to the product's availability for the end user in production.

Velocity should be continuous and stable, yes, it can be improved, but it will find an optimal level. In Lean Manufacturing, one of the goals is to reduce process overburden (waste). Of course, it's expected to have peaks of work and deadlines, but achieving a sustainable pace is essential so the team can excel and thrive.

Technical Excellence

Technical Excellence is a cornerstone of this principle (Flow). If we think about software, we can think immediately about reducing technical debt, but it's not only that. Technical Excellence also refers to the implementation of best practices and the capability of the team and process to improve continuously. Remember, we are not talking only about software but about products. Best practices and continuous improvement methodologies should connect the team across the product lifecycle, and this is where we can see the intersection of Design Thinking, Agile Development, and DevOps.

Lean focuses on reducing waste, which is crucial because delivering something that the customer doesn't use or value is pointless, regardless of the Throughput. While there are ways to determine in advance what will have the most significant impact on the customer (e.g., user research, rapid prototyping, etc.), it's also important to consider and enable a technical solution that can scale and improve over time. Not everything needs to be ready on day one; most things will require refactoring and rebuilding over time. Remember that time to value and Throughput shouldn't only be measured within the scope of the software development process. If it's not in the hands of the customer, it likely isn't adding value.

Here are some questions to open up a conversation with your team:

• Are you measuring velocity (Throughput) beyond the software development team?
• How often do you deploy and release new features and improvements to your product?
• How long does it take to go from an idea, or requirement, to production (this includes all the interactions from business, design, development, operations, …)?
• Is it painful for your team to deploy and release new software?
• Is it painful or difficult for your team to define and design new features or capabilities for your product?
• How long does it take for a new member to become productive after joining the team?