{"id":7928,"date":"2026-09-08T10:14:40","date_gmt":"2026-09-08T08:14:40","guid":{"rendered":"https:\/\/getnave.com\/blog\/?p=7928"},"modified":"2026-09-08T10:19:12","modified_gmt":"2026-09-08T08:19:12","slug":"joelma-castro-success-story","status":"publish","type":"post","link":"https:\/\/getnave.com\/blog\/joelma-castro-success-story\/","title":{"rendered":"Everyone Thought Development Was Slow. 77% of the Time, the Work Was Just Waiting."},"content":{"rendered":"
<\/div>\n

The team looked slow.<\/p>\n

Lead Time was 19.8 days. Cycle Time was 13.6 days. In the conversations around the work, the obvious question was why delivery was taking so long.<\/p>\n

Then Joelma Castro<\/a>, Agile Master and Squad Leader, looked at where the time was actually going.<\/p>\n

Four days of the Cycle Time were blocked. Another 6.5 days were spent waiting for QA approval. Together, that meant roughly 77% of the item’s Cycle Time was waiting.<\/p>\n

The delay wasn’t simply development. It was waiting.<\/p>\n

That one piece of evidence changed the conversation. The question stopped being “why is the team taking so long to deliver?” and became “why are our items waiting so long to be approved?”<\/p>\n

If your standup keeps circling around why development is slow, this is the question worth stealing: where is the time actually going?<\/p>\n

Joelma has a name for what happened next. It is the loop she runs on every team she works with:<\/p>\n

Measure \u2192 Investigate \u2192 Understand \u2192 Act \u2192 Measure again<\/strong><\/p>\n

Measure<\/h2>\n

“I don’t use the tool only to track indicators. I use the data as a way to ask questions about the flow, investigate behaviors, and direct improvement actions,<\/em>” she says. “My goal is not to find a number. It is to understand the behavior of the flow in order to, together with the team, take improvement actions.<\/em>”<\/p>\n

The numbers came straight from the team’s board. Nave’s Cumulative Flow Diagram put the two headline figures on the table: 19.8 days of Lead Time across the full workflow, and 13.6 days of Cycle Time from Ready for Development to Done.<\/p>\n

\"Lead<\/a><\/p>\n

Lead Time across the full workflow: 19.83 days on average.<\/em><\/p>\n

\"Cycle<\/a><\/p>\n

Cycle Time from Ready for Development to Done: 13.58 days on average.<\/em><\/p>\n

The number that mattered most was hiding one level deeper. Nave’s Cycle Time Breakdown<\/a> showed where those days were actually going: the single biggest share of the team’s Cycle Time, over 31%, was work that was already developed and tested, sitting in the queue for QA approval. Roughly 6.5 days per item. Blockages accounted for another 4 days.<\/p>\n

\"The<\/a><\/p>\n

The biggest slice of the team’s Cycle Time, over 31%: items already developed and tested, waiting for QA approval.<\/em><\/p>\n

\"Blocked<\/p>\n

Blocked time: external dependencies accounted for more than 4 days.<\/em><\/p>\n

A metric on its own is not a diagnosis. It is a signal that tells you where to look next.<\/p>\n

Investigate<\/h2>\n

“When I notice that Cycle Time has increased, for example, I don’t immediately conclude that the team has become less productive. I will investigate,”<\/em> she says. “Where did this increase happen? At which stage? Which items are driving this result? Is there any pattern among them? Are we talking about an isolated situation or a recurring behavior?”<\/em><\/p>\n

Once the team stopped treating “development is slow” as the diagnosis, they investigated the flow. They found QA was unavailable at certain times. Emergency work was taking priority. Some items were reaching development without enough refinement. Other conditions were creating blockages before work could reach production.<\/p>\n

“The problem, therefore, was not simply ‘development is slow’ or ‘this team is not efficient,'” Joelma says. “There was a bottleneck in the flow.”<\/p>\n

Understand<\/h2>\n

That distinction changes what you do about it.<\/p>\n

“If I interpret the problem as low development speed, I will probably look for ways to speed up the developers and may put resources in the wrong part of my flow, making the problem even worse. But if I understand that there is an approval queue and that the team suffers from many blocked items, I need to act on the capacity, the flow, and the conditions that are making the work wait.”<\/em><\/p>\n

This is where flow data changes the leadership conversation too. There is a huge difference between saying “We need to be faster” and asking “What is making the work wait?” The first puts the responsibility on people. The second invites everyone to investigate the system.<\/p>\n

Act<\/h2>\n

Once the causes were visible, the team could aim its improvement work at the conditions creating the queue and the blockages, not at pushing developers to go faster. Capacity, dependencies, priorities, quality, and the size of demands could all be discussed with evidence instead of perception. The question stopped being “who is causing the delay?” and became “what is making our work stop?”<\/p>\n