In our last post, we shared two key insights that emerged from our internal and client workshops: that we were measuring the wrong things, and that we lacked visibility into how work actually flowed through our delivery process. These two realizations pointed us to a clear first step, which was to build a system that could show us the truth.
So that's what we did.
Starting with what existed
We didn't begin by building something from scratch. We started with a third-party flow metrics platform called Actionable Agile Analytics, which plugged seamlessly into Jira. It gave us our first real window into flow metrics, and more importantly, it gave us a shared language for talking about delivery in a new and consistent way.
As our understanding deepened and we began to hit the boundaries of what that platform could show us, we took the next step: building our own custom platform. One designed specifically around the questions we needed to answer: how work moves through each step of our delivery process, where it gets stuck, and which parts of the process to focus on to improve the flow of value to our clients.
But the tool was only the beginning. What the data showed us when we started looking is where things got interesting.
The finding that changed everything: Touch time vs. idle time
We picked a typical work item and traced its full journey, from the moment work started to the moment it was deployed to production. Let's say that the journey took ten days.
We expected to find some inefficiency. What we found was confronting.
Of those ten days, roughly eight were idle. The work item wasn't being worked on. It was sitting in a delivery step, waiting. Waiting to be picked up, waiting for a decision, waiting for someone to notice it. Only two of the ten days involved anyone actually touching it.
Eighty percent idle. Twenty percent active.
Once you see that, you can't unsee it. And it immediately reframed the question we should be asking; not "how do we work faster?" but "how do we make sure that work items spend less time waiting?"
What was driving all that idle time?
Two patterns stood out above everything else.
The first was work in progress; specifically, too much of it. Teams were starting work items at a high rate but not completing them at the same rate. The more items in flight simultaneously, the more each individual item waited for attention.
A subtle but damaging habit had also taken hold alongside this: when a work item hit a snag or became unclear, the easiest response was to move it to a "blocked" column and pick up something new. The blocked column became a quiet graveyard. Items sat there as someone else's problem, while the team accumulated more and more in-progress work.
The mindset shift required here was significant; from "I'll start the next thing" to "I started this, it was prioritized for a reason, and I'll do whatever it takes to get it across the line before picking up something new."
The second major driver was unplanned work. Urgent tasks arrived mid-sprint, while critical quality issues demanded immediate attention. These interrupted flow constantly and unpredictably. The data made a clear case for investing more time in quality upfront, because the cost of being interrupted later was far higher than it appeared.
Where we expected the bottlenecks and where they actually were
We assumed, as most people do, that the slowdowns lived in the engineering steps. The build, the code, the technical complexity.
We were wrong.
The real bottlenecks were at the beginning and the end of the delivery process. Early steps like the idea generation, user story creation, architecture and design, and value validation were where work piled up and slowed down before it ever reached an engineer. And at the other end, user acceptance testing and deployment to production were equally problematic.
Unexpectedly, the middle was often not the constraint at all.
The harder finding
Perhaps the most humbling observation wasn't about process steps or WIP limits. It was this: the delivery habits that everyone in software knows are good practice, the basics, are genuinely hard to maintain under pressure. It is easy to know the right thing to do. It is much harder to do it consistently when teams are busy, timelines are tight, and the path of least resistance is always one click away.
Good habits are fragile. Bad habits are sticky. And the data showed us exactly where ours had taken hold.
What comes next
Seeing the problem clearly is not the same as solving it. The data gave us a foundation in the form of a shared, honest picture of how our delivery process actually worked, not how we imagined it did.
In the next post, we'll get into what we actually targeted: the specific behaviors and habits we wanted to change, the metrics we put in place to measure them, and the underlying goals and objectives that shaped our approach.
