8 min read
I’ve spent a lot of time talking about outcomes and Realization. That is intentional. Technology organizations ultimately need to show that the work they deliver creates a measurable customer or business result. We should define that anticipated outcome before the work begins.
What are we trying to change? What result are we expecting? How will we know whether the investment mattered?
Once that direction is clear, the team still has to deliver it. That brings us back to the other side of the equation: Flow.
Over the years, we changed nearly every part of how we built and delivered software. We moved from Water-Scrum-Fall toward Agile, Lean, and DevOps; increased automation and continuous delivery; re-architected legacy systems; created cross-functional teams; invested in platform capabilities; and moved toward a product operating model with greater team autonomy.
The thinking behind those changes started much earlier for me with Eliyahu Goldratt’s The Goal, which taught us to look for the largest constraint in the system rather than push harder on the people inside it.
DORA later gave us much better visibility into software delivery performance. As deployments became more reliable and continuous, however, our questions moved beyond delivery. We needed to understand how work moved through the larger system, where it waited, how much work accumulated, and where dependencies, decisions, or priorities created friction.
That led us deeper into Flow Metrics, Mik Kersten’s Flow Framework and Project to Product, Value Stream Management, and eventually Steve Pereira’s Flow Engineering, helping us map the various workflow states.
Flow Time, Flow Load, Flow Efficiency, and related measures helped make the system visible. The point was never to collect another set of engineering metrics. It was to help teams and leaders see where work was slowing down and decide what to improve.
I have often said, “Fast flow happens when friction fades.”
The question is how teams make that happen repeatedly and that is where the Team Flow Improvement Loop comes in.
Improving Flow from within the team
The idea behind the loop is simple. Give teams enough visibility into their delivery system to understand how it is performing. Let them see where work slows down, discuss what may be causing the friction, form a hypothesis, make a small change, review the metrics, and learn from what happened.
Then do it again.
That is how Flow Metrics become more than a dashboard. They become feedback about the system the team works inside every day.
A team may discover work repeatedly waiting for approval. WIP may be increasing while Flow Time, percent complete and accurate, or team sentiment gets worse. A build, test, or external dependency may be adding days to work that otherwise moves quickly.
The team closest to that work usually has context that will never show up completely on an executive dashboard.
Once the constraint becomes visible, the conversation changes from reporting the problem to testing what might improve it.
The team may try setting a limit on WIP, automating an approval, or redefining how they handle a dependency. As a group, they may choose to swarm work that has been in progress for a period of time or attempt to change how they break work into smaller tasks. Sometimes, the data shows the team’s real constraint is outside of the team, and requires leadership assistance.
The important part is not making a large change. It is having a hypothesis about what is creating friction, making a small adjustment, and watching what happens.
Teams do not always need another transformation. Sometimes they need enough visibility and support to fix the next constraint in front of them.
Let the data become feedback
This was an important shift for us as teams grew more comfortable using Flow, quality, and sentiment metrics.
They learned to treat the data as a mirror.
One team had a work item that had been open for more than 100 days. The first reaction was concern about how the number would look. Someone suggested changing the ticket status to Backlog so it would no longer affect cycle time.
But the aged work was useful information.
It exposed a hidden dependency that had been slowing the team for months. Once it became visible, we could finally discuss the real constraint.
Changing the status would have made the metric look better while leaving the system exactly as it was.
That taught me something about measurement that I still believe: the purpose of Flow data is to help us understand what is happening.
If a team tries an improvement, the next set of metrics provides evidence: whether waiting declined, aging work cleared, Flow Time improved, and WIP became more manageable while quality remained steady.
Sometimes the hypothesis will be right. Sometimes the team will discover that the constraint was somewhere else. Both are useful because both create learning.
This is also why I continue to value a good retrospective.
Teams have the flexibility to change how they work. They can automate steps, adjust workflow and WIP limits, implement earlier tests, and change how they deal with dependencies. Without looking back, these changes can become normal, and it can even be lost to everyone whether these changes were helpful.
A retrospective creates space to examine what the team tried, what the evidence showed, and what to adjust next.
It also permits the team to say an experiment did not work.
That matters. If every improvement has to be presented as a success, teams stop experimenting and start protecting themselves. Learning requires enough psychological safety to admit that a hypothesis was wrong, adjust it, and try something else.
Different conversations, same system
One distinction became increasingly important to me. The business conversation should focus on direction, priorities, investment, and outcomes. The team conversation should focus on bottlenecks, friction, dependencies, quality, and experiments that improve Flow.
Those conversations are connected, but they happen at different levels of the system.
The business establishes what matters and the anticipated outcome. Teams need enough context to understand why the work matters and enough autonomy to improve how they deliver it.
That does not mean teams invent priorities or outcomes in isolation. Autonomy lies primarily in how the team improves the system around the work.
Leadership still has an important role.
Leaders provide direction, guardrails, stability, data, platform capabilities, automation, and support. They also help remove constraints the team cannot solve on its own.
Constant priority churn, moving people between teams, or changing direction before an experiment has time to produce evidence can undermine the learning process.
Other constraints may sit entirely outside the team: cross-functional approvals, platform investments, architectural dependencies, or business decisions.
Those are leadership problems to help solve.
When leaders look at Flow trends, one of the most valuable questions they can ask is: How can I help remove the bottleneck?
That keeps leadership focused on improving the conditions around the work rather than controlling every improvement within it.
Improve the system, not the metric
If teams have visibility into their current performance, enough autonomy to experiment, and a regular way to learn from the evidence, the numbers should eventually improve. That was my experience.
Waiting declines, work gets stuck less often, WIP becomes more manageable, and dependencies surface earlier. Delivery becomes more predictable because the team improved the system. The numbers improve because people improved the system.
Problems begin when leadership reverses that relationship and turns the metric itself into the objective.
Set a goal to increase throughput by 15 percent, reduce cycle time by 20 percent, or make one team’s numbers resemble another team’s, and people will naturally respond to the target. Work may be divided differently. Difficult tasks may be avoided. Attention shifts toward improving the scoreboard.
The dashboard can become healthier while the system underneath it does not.
This is different from a team setting a target as part of an experiment. In that case, the number is a hypothesis to test, not a performance commitment imposed from above.
Compare a team primarily to its own history. Look at trends. Understand why something changed. Use the information to find friction and improve the system.
As I wrote in Profitable Engineering, “When teams realize the data is used to remove the rocks in their shoes, they stop gaming the system and start using it to improve.” Visibility is valuable until it becomes control.
If a Flow Metric is set as a quota, teams will manage the quota. If it becomes a ranking metric, teams will protect themselves from comparisons. If it becomes a way to determine who is responsible for achieving a bad target or goal, discussions will shift from the metrics or system to the blame game.
That defeats much of the reason for collecting the data in the first place.
The better use of Flow Metrics is to create a feedback system: see what is happening, understand the constraint, form a hypothesis, make a small change, review the evidence, learn, and repeat.
That is the Team Flow Improvement Loop.
It gives the business a path to better performance without requiring leadership to command every improvement into existence.
Flow still has to connect to Realization
Improving Flow is only part of the larger system. A team can become remarkably efficient and still build something customers do not need. That is why the anticipated outcome matters.
The Team Flow Improvement Loop helps teams improve their ability to deliver against that purpose. Realization closes the larger loop after release by showing whether the investment produced the customer or business result we expected. That evidence feeds the next decision. Flow tells us how the work moved. Realization tells us whether it mattered.
Leadership provides purpose, direction, boundaries, and assistance for teams in removing obstacles in the system. Teams learn to expand their capability and efficiency as they improve the systems that they operate.
Over time, the evidence should show the difference.
Fast Flow happens when friction fades.
From Profitable Engineering
The Team Flow Improvement Loop builds on ideas explored throughout Profitable Engineering: Transforming Technology Teams into Strategic Business Partners, particularly the relationship between Flow, team autonomy, measurement, continuous improvement, and Realization.
The book also looks at how leaders can make technology work visible, reduce friction across the delivery system, improve the conditions in which teams operate, and connect engineering investment to measurable customer and business outcomes.
If this way of thinking about Flow is useful, Profitable Engineering explores the larger relationship between Flow, Realization, leadership, operating models, and business outcomes.
Learn more about Profitable Engineering.