Most Agile conversations start in the wrong place.
They focus on frameworks, debate roles, and argue about which approach is “right.” I understand why those conversations happen. I used to be part of them.
I was a software engineer long before I moved into Scrum Mastery and coaching. I’ve written production code, lived with technical debt, and felt the pressure of being accountable for outcomes without always having clarity or control over the decisions shaping the work. That experience is why many Agile conversations feel incomplete to me now—not because frameworks don’t matter, but because the hardest problems I’ve seen were rarely caused by them.
They were caused by breakdowns in communication and a growing distance from real value.
What Agile Is Actually About
At its core, Agile is simple. It’s about communication, and it’s about delivering value.
That’s the work.
When communication is clear, reality surfaces sooner. When value is the measure, decisions improve. Learning and growth happen as a result, not because anyone set out to optimize for them directly.
When Agile struggles, communication becomes shallow and value becomes harder to connect to the work being done.
Why Scrum Can Feel Restrictive to Engineers
Many engineers experience Scrum as a set of limitations and hoops to jump through. There are more meetings, more structure, and more process layered on top of already complex work. That frustration is real.
But in practice, it’s often misdirected.
Scrum isn’t designed to limit engineers. It’s designed to surface constraints that already exist. One of the most common constraints teams face is that priorities change frequently.
On its own, that isn’t a problem. Markets shift. Customers respond. New information shows up. Adapting is part of the work.
The strain appears when priorities change without explanation, context, or acknowledgement of the tradeoffs involved. Teams are asked to pivot, but not invited into the reasoning behind the pivot. Work moves, but understanding doesn’t.
Scrum doesn’t create that tension. It exposes it.
When priorities change faster than teams can make sense of them, communication starts to erode. Engineers don’t resist change—they resist confusion. And when confusion persists, the framework itself begins to feel like the obstacle.
Frameworks as Starting Points
Frameworks tend to get blamed because they’re the most visible part of the system. But frameworks aren’t the enemy.
They aren’t rules to comply with or guarantees of success. They are starting points.
Frameworks give teams a shared language and a basic structure to communicate about work and value—especially when things are changing. What matters most is what happens after that starting point.
When teams are part of the conversation around shifting priorities, frameworks help them adapt. When teams are only told what moved, frameworks feel rigid.
Why Facilitation and Coaching Matter to Me
When I moved into a Scrum Master role, and later into coaching, it wasn’t because I stopped caring about engineering. It was because I cared about the people doing the work—and whether they had what they needed to deliver real value.
Over time, what mattered most to me was the work itself and the people responsible for it—whether teams had the clarity, context, and space they needed to do it well, especially when things were changing quickly.
Standups weren’t meant to be status updates. Planning wasn’t meant to lock teams into commitments that reality would immediately invalidate. Retrospectives weren’t meant to rehash frustration. They exist to help teams make sense of information and decide what to do next.
But there’s a pattern I’ve seen repeatedly. Teams surface the same insights sprint after sprint, fully aware that nothing will change. The conversations happen, the signals are clear, and yet the system doesn’t respond.
When teams can communicate honestly but don’t have room to adjust, communication starts to feel pointless. At that point, the problem isn’t the ceremony. It’s that communication has been disconnected from action.
Looking Beyond the Team
This is where coaching becomes necessary.
Coaching isn’t about making Agile feel smoother. It’s about examining the system surrounding the team. Who decides what value actually means? How are tradeoffs communicated when priorities change? What happens when teams surface information that challenges the current direction?
When those questions aren’t addressed, teams are asked to be transparent without being empowered. Information flows, but decisions stay the same. Movement slows—not because teams are resistant, but because the system doesn’t respond.
Why “Failing Fast” Misses the Point
Somewhere along the way, “failing fast” became a slogan. But nothing in Agile is really about failure.
There is only information showing up earlier or later.
If teams can speak openly but can’t pivot, insight is gained without impact. If teams can surface risks but can’t stop work, reality is visible but ignored. If teams can identify low value but can’t change direction, clarity arrives without consequence.
Value doesn’t improve because teams move faster. It improves when communication leads to meaningful response.
Where I’ve Landed
Over time, what mattered most to me was whether teams had the clarity they needed to do the work well—especially in environments where priorities shift and certainty is rare.
Agile works when communication is honest, value is the measure, and teams are trusted to respond.
Learning and growth aren’t objectives to chase. They’re signals that communication is working and value is being tested in the real world.
Frameworks don’t create agility. People do—when they’re given the space to understand, decide, and act together.
Want the Experiment-Driven Agile Retrospective Toolkit?
If you’d like the Toolkit, reach out and I’ll send details (what’s included, pricing, and how teams use it). Or subscribe for new posts and updates.