When Agile Coaching Doesn’t Deliver: A Results-Based Alternative for Tech Leaders

If coaching engagements have disappointed you by promising transformation yet delivering nothing more than process buzzwords, you are not alone.

IBM found that 84% of digital transformations fail. Other studies put Agile transformation failure rates at 96%. The numbers vary. The pattern doesn’t: most organizations invest in transformation and end up with ceremonies rather than results.

I’ve spent more than 13 years coaching tech teams through operational improvements. The organizations that succeed share one thing: they focus on business outcomes, not solely on adopting methodologies. The ones that fail do the opposite.

This article explains why most transformations stall and what actually drives measurable results.

Why Most Agile Transformations Stall

Agile is valuable. The principles are sound, but the problem is how many organizations adopt it.

Most transformations follow a predictable pattern: leadership announces the initiative, teams get trained on Scrum or SAFe, coaches facilitate ceremonies, and everyone waits for results. Months pass. Standups, retros, and sprints happen, but delivery doesn’t improve. Typically, Quality and Lead times don’t improve.

When leaders ask why, they hear explanations about “culture” and “mindset” and “the journey.” They hear that transformation takes time. They also hear that they need more training, more coaches, more commitment.

Eventually, the organization declares the transformation complete (or quietly abandons it) and moves on. Leaders conclude that “Agile doesn’t work for us” or that their teams “aren’t ready.” Neither conclusion is accurate.

The Real Problem: Optimizing the Container, Not the Content

Scrum, SAFe, Kanban, and other frameworks optimize how work is organized. They provide containers for work: sprints, backlogs, ceremonies, and roles. These containers are useful, no doubt.

But containers don’t fix what’s inside them.

If your code review process creates a 3-day bottleneck, putting it inside a sprint doesn’t remove it. If 40% of your sprint capacity goes to unplanned work and firefighting, a Kanban board makes that visible but doesn’t fix it. If your testing finds defects too late, retrospectives will identify the pattern, but here too won’t eliminate the root cause.

Those Agile frameworks assume the work itself is efficient. They assume the problem is coordination and communication. Sometimes it is, but often it isn’t.

The real problems hide in the actual flow of value: how a feature request becomes working software, where work waits, why defects escape to production, and what causes the firefighting that consumes your capacity. Those frameworks don’t examine this. Instead, they organize around it.

What Results-Based Coaching Looks Like

When I work with tech teams, the same practices appear in every successful engagement. They’re not new. They’re foundational Lean practices that most Agile transformations skip entirely. The difference is how they’re applied: aimed at specific business outcomes, not methodology adoption.

I call this results-based coaching: instead of adopting a framework and hoping for outcomes, you define the outcome first and work backward to the changes that will produce it.

These four practices reinforce each other. Performance gap framing tells you what to measure and, therefore, what problem to solve. Direct observation and value stream mapping reveal why the gap exists. Root cause analysis identifies what to change. They do not happen sequentially. 

Direct Observation of Work

Reports and dashboards show outcomes. They don’t show causes.

DORA metrics tell you that your lead time is 30 days. They don’t tell you why. Jira tells you that a ticket sat in “In Review” for 5 days. It doesn’t tell you that the reviewer was in back-to-back meetings and couldn’t focus on code reviews until Friday afternoon.

The only way to understand what actually happens is to observe it directly. I mean sitting with teams, watching how work flows, seeing where interruptions occur, and noticing what the data doesn’t capture.

In manufacturing, this practice is called Gemba: going to where value is created, to see. The same principle applies to software. You cannot fix what you cannot see, and you cannot see the real problems from a dashboard.

When I observe teams, I consistently find problems that never show up in reports:

• Developers wait days for environment access or credentials
• The same bug was fixed multiple times because nobody addressed the root cause
• Knowledge trapped in one person’s head, creating bottlenecks whenever they’re unavailable
• Context switching that fragments focus and extends lead times
• Manual processes that could be automated, but “there’s never time.”

These problems are invisible to frameworks, but they become visible through direct observation.

Value Stream Mapping

Most Agile implementations focus on the team level. But value doesn’t flow through a single team. It flows through the entire organization: from customer request to delivered solution.

Even though SAFe includes value streams as a core concept, there’s a difference between organizing teams around value streams and actually mapping the flow of work to find waste. In my experience, concrete value stream mapping with process times, wait times, and % complete and accuracy rarely occurs in SAFe implementations.

Value stream mapping traces the end-to-end flow. You pick a real piece of work and follow it from inception to delivery. At each step, you measure two things: how long the work takes (processing time) and how long it waits in the queue (queue time). You may add other things.

The results are often shocking. In a typical software organization, 10-15% of lead time is actual work. The rest is waiting: waiting for approval, waiting for review, waiting for a deployment window, waiting for someone to be available.

That finding reframes the question. Instead of asking “how do we make developers faster?” you ask “why does work spend 85% of its time waiting?” The answers lead to different interventions.

Value stream mapping also reveals dependencies, handoffs, and rework loops that frameworks don’t address. When you can see the entire flow, you can identify where improvements will have the greatest impact.

Performance Gap Framing

Vague goals produce vague results. “Improve delivery” is not actionable. “Reduce lead time from 45 days to 20 days by Q3” is actionable.

Performance gap framing makes problems concrete and measurable:

• Current state: What is happening now, with specific metrics
• Target state: What good looks like, with specific metrics
• Gap: The difference that needs to be closed
• Business impact: What closing the gap is worth in financial terms. Or, what is the actual business impact of the current state?

This framing moves focus from blame to system improvement. “Developers are slow” becomes “the process creates 5 days of wait time that we can eliminate.” The team isn’t the problem. Actually, the system is the problem, and indeed, systems can be changed.

Performance gaps also create accountability. When the target is specific and measurable, you know whether you’re making progress. When the target is “be more agile,” nobody knows anything.

Root Cause Analysis

Symptoms are easy to spot, but root causes take work to find.

When delivery is late, the symptom is “we missed the deadline.” The root cause might be:

• Defects discovered late that required rework, testers lack the business-related skills
• Requirements that changed mid-sprint, because product owners don’t know how to manage them properly with the clients
• Dependencies on other teams that weren’t ready, because the team lacked the technical depth for proper user story sizing
• Unplanned work that consumed planned capacity, because the tech lead does not understand the kanban
• Estimation based on hope rather than data, because of a lack of technical depth

Each root cause requires a different intervention. Fixing the wrong cause wastes effort and leaves the real problem untouched.

Root cause analysis uses structured methods (like the 5 Whys) to trace symptoms back to their origins. Combined with data, this analysis reveals what to fix, and more importantly, how much fixing it is worth.

When you can say “this problem costs us $200,000 per quarter in rework and delays,” the business case for fixing it writes itself.

Case Study: Reducing Infrastructure Deployment Lead Time by 55%

A DevOps team at a large enterprise handled cloud infrastructure deployments. Eight engineers running Scrum: two-week sprints, daily standups, retrospectives, and a Scrum Master. They followed the framework.

Development teams complained about waiting too long for environments. In retrospectives, the DevOps team discussed many aspects of the issue, but nothing changed.

Performance gap framing: I started by measuring the actual lead time. I went through the last several deployments, step by step, and uncovered the reality: 64 days on average. Development teams waited two months for environments they could use properly. We decided to set the target to 30 days maximum. Every delayed deployment pushed back feature releases and burned budget on waiting. This was a time-to-market issue for the whole organization.

Direct observation: I traced an actual deployment request through the system. I didn’t attend ceremonies. I just followed the work.

What I found: the cloud engineer had no admin rights and waited 7 days for the tech lead to return from vacation. The networking team deleted a subnet because they weren’t notified about a new Azure ML process. Security group requests bounced between teams for 10 days because nobody knew which ticket to create. A document template was wrong. Even version two was incorrect.

The initial Agile reality: None of this surfaced in standups. The visual board showed “blocked.” It didn’t show why, nor was there any ongoing action to clarify the situation.

Mapping the flow: I mapped nine steps across five teams. I measured the lead time at each step. It was how we ended up with 64 days end-to-end. The mapping revealed where time disappeared: 31 days in a single queue for security group creation and flow opening requests. Requests waited in the queue because teams didn’t know where to route them.

Root causes identified through observation:

• No admin rights for cloud engineers (in our case, only the tech lead could grant them, but he was not available)
• No documentation for request routing between teams
• Wrong templates for service-account creation
• No clarity on which security group to request for different environments

The interventions: We created a deployment checklist with every entry point and routing decision. We front-loaded long lead-time requests (especially security groups) to run in parallel instead of sequentially. We scheduled early handover meetings before deployment completion. We documented what didn’t exist.

The results: The next deployment took 29 days. Down from 64, we achieved a 55% reduction.

The Scrum ceremonies continued. But the improvement came from tracing actual work across team boundaries, observing specific failures, and fixing specific root causes. The retrospectives had discussed “communication” for months. Direct observation revealed the real problems: missing documentation, unclear routing, and wrong templates. Those are fixable. “Better communication” is not.

Where This Approach Works Best

This approach fits some situations better than others.

It works well when:

You have a specific performance problem you can measure. “Deployments take too long,” or “too many defects escape to production,” or “we miss commitments every sprint.” If you can put a number on it, you can improve it.

Your team is stable enough to sustain changes. If people leave every few months or reorganizations happen quarterly, improvements won’t stick. You need enough continuity to implement changes and see results.

Leadership will act on what the observations reveal. Direct observation surfaces uncomfortable truths. If leaders want validation rather than honesty, they won’t like what this approach uncovers.

It works less well when:

The goal is cultural change without operational targets. “We want to be more innovative” or “we need better collaboration” are worthy goals, but without specific metrics, there’s nothing to measure and no way to know if you’ve succeeded.

The organization is mid-reorganization. When reporting lines shift and teams dissolve, there’s no stable system to improve. Wait until the dust settles.

Nobody owns the problem. Every improvement needs someone accountable for the outcome. If the performance gap falls between teams and no one owns it, the approach stalls.

Getting Started

You don’t need a consultant to begin. Here are three things you can do this week:

1. Trace One Feature End-to-End

Pick a recently completed feature. Trace its journey from first request to production deployment. Note when work started at each stage, when it finished, and how long it took between stages.

Calculate the ratio of working time to waiting time. If you’re like most teams, you’ll find opportunities hiding in the wait times that no framework addresses.

2. Observe Without Agenda

Spend one hour watching your team work. Don’t ask questions. Don’t facilitate. Just watch.

Notice interruptions, context switches, and delays. Notice what problems surface in conversation that never appear in Jira. Notice the difference between what the process says should happen and what actually happens.

3. Define One Performance Gap

Identify one metric that matters to your business. Define where you are now and where you need to be. Make it specific: “Reduce escaped defects from 12 per month to 3 per month by the end of Q2.”

Then ask: what would we need to change to close this gap? The answers will point toward the work that actually matters.

Conclusion

Agile frameworks are tools, not solutions. They provide structure for organizing work but don’t address the operational problems that cause most delivery failures.

When transformation stalls, the answer isn’t more training or more ceremonies. It’s looking at the actual flow of value: observing where work gets stuck, measuring the gaps between current and target performance, finding root causes, and implementing changes that produce measurable results.

This approach is less dramatic than a transformation. It doesn’t have a catchy framework name. But it produces outcomes you can measure and improvements that stick.

If your organization invested in transformation and got process buzzwords instead of business results, a different path exists. It starts with observation, seeing what’s actually happening, and fixing specific root causes.

Frequently Asked Questions 

Isn’t this just Lean? How is it different from Agile?

This approach draws on Lean principles, particularly direct observation (Gemba), value stream mapping, and PDCA cycles for problem-solving. The difference from typical Agile coaching is the focus: Agile coaching often centers on framework adoption and team practices, while this approach centers on measurable business outcomes. The two can complement each other. The problem arises when framework adoption becomes the goal instead of the means.

Our Agile coaches told us that transformation takes 2-3 years. Is that wrong?

Culture change does take time. But operational improvements don’t require waiting for culture to change first. You can reduce defects, shorten lead times, and improve delivery reliability while culture evolves. In fact, visible operational improvements often accelerate culture change because people see that new approaches actually work.

We already track DORA metrics. Why isn’t that enough?

DORA metrics tell you what’s happening. They don’t tell you why. Knowing your lead time is 30 days doesn’t explain the root causes of that lead time or which interventions will reduce it. Metrics identify where to look. Observation and analysis reveal what to do.

How do you avoid this from becoming another never-ending initiative?

By defining success upfront with specific, measurable targets and timeframes. A targeted engagement might be “reduce escaped defects by 50% within 4 months.” When you hit the target, the engagement ends. The team owns the improvements and can independently apply the methods to future problems.

What if leadership doesn’t support looking at root causes?

Start small. Find one problem with a clear business cost. Solve it visibly. Use the results to build support for broader application. Leaders who resist abstract methodology often embrace concrete results.

Can this work with remote or distributed teams?

Yes. Observation can happen virtually through screen sharing, recorded work sessions, and analysis of communication patterns. The principle is the same: understand how work actually flows rather than relying solely on reports and metrics. Remote observation requires more intentional setup but reveals similar patterns.