We’ve all experienced them:

• The awkward handoff where nobody’s quite sure who owns what.

• The stand-up that becomes a status meeting for five different priorities.

• The clunky collaboration that drains energy instead of unlocking progress.

It’s tempting to dismiss these moments as challenges we just have to live with, symptoms of working in a complex organization. But what if we treated awkwardness as a signal? A sign that the current team structures, relationships, or responsibilities are no longer supporting the way work actually flows.

Understanding what drives your users is crucial for delivering products and services that truly meet their needs. While Jobs to Be Done (JTBD) focuses on uncovering the underlying motivations behind user actions, User Needs Mapping provides a framework for aligning teams and capabilities to meet those needs. Together, these methodologies offer a powerful approach to driving value and aligning your organization around user goals.

By combining User Needs Mapping with the "We can if..." approach from A Beautiful Constraint, you can create innovative, scalable solutions that work within your current limitations. You can overcome resource constraints when defining team and service boundaries and break free from path dependence by rethinking legacy systems and architectures.

All organizations operate within constraints.

Time. Budget. Legacy systems. Regulatory requirements. Skill gaps. Cultural inertia. These aren’t signs that something is broken. They’re the reality of operating in a complex world.

The challenge isn’t whether constraints exist. It’s how we relate to them. Too often, constraints are treated as blockers. Reasons we can’t act. Excuses for stagnation. But what if we reframed them?

Leading with the label can unintentionally create barriers to adopting powerful frameworks like Wardley Mapping, Team Topologies, or User Needs Mapping. By focusing on outcomes, breaking concepts into manageable pieces, and building trust through practical steps, you can guide your team toward meaningful change without overwhelming them.

Transitioning to new team boundaries is a common challenge for organizations that have identified more effective structures through techniques like User Needs Mapping or other strategic Team Topologies-based approaches. However, moving from your current state to an ideal team design can feel daunting. By integrating principles from Dynamic Reteaming, organizations can make small, incremental changes that evolve team structures naturally over time.

One of the most promising things about AI is how accessible it’s becoming. Teams don’t have to wait for central approval to experiment. Developers can integrate models in hours. Operations teams can automate tasks without waiting for platform teams. It’s fast. It’s exciting. It’s also a recipe for chaos if not handled with care. Because while AI is decentralizing capability, alignment has never been more important.

You don’t need a dedicated “AI team” that does all of the AI work. You need clarity about how AI fits into the value your teams deliver, and who’s responsible for making that value real, reliable, and resilient. Otherwise, even the most promising experiments will fade into the background, another initiative lost to structural ambiguity.

The most effective AI work doesn’t start with flashy ideas. It starts with a clear, painful need, and ends with a quietly powerful improvement. These projects may not get the loudest applause at first. But they’re the ones that stick, scale, and strengthen trust. Tech-first thinking starts with a hammer. People-first thinking starts with purpose. If you want to use AI well, don’t just ask what the model can do. Ask what people need, where the flow is broken, and what capabilities are holding them back.

AI is fast at a lot of things, but in most organizations, the system around it isn’t. That’s the real risk I see. Not that AI will fail, but that it will succeed just enough, in the wrong places, for the wrong reasons, and with little ability to scale or sustain. When teams don’t understand where the current friction or tension in the system really lies, AI will become an accelerant of those dysfunctions; it won't solve them.

AI can amplify human capability, streamline operations, and uncover insights we could never see before. But there is a problem playing out in boardrooms and backlog review sessions across the world: Organizations are reaching for AI without fixing the foundations that make it effective.

The result? Fragmented pilots. Shadow tools. Confused ownership. Duplication. More noise, not more value.

Agile has helped teams adopt better ways of working. We plan more collaboratively, reflect more frequently, and adapt more easily. But across many organisations, the same underlying question keeps surfacing:

“Why does delivery still feel so slow?”

This series has explored a few common answers to that question, not rooted in broken process, but in deeper structural and interactional frictions.

Agile gave us a better way to manage work. But many teams are still working within structures that were never designed for flow. Team boundaries are often shaped by legacy systems, old reporting lines, or the last big re-org. And while the way we deliver has evolved, the shape of the organisation often hasn’t. When that happens, friction persists, not because Agile isn’t working, but because the environment it’s working within isn’t supporting it.

As delivery scales, so does coordination. What begins as healthy collaboration across a few teams can quickly turn into a web of meetings, approvals, dependencies, and shared decisions. And before long, the organisation feels like it’s spending more time aligning around the work than actually doing it.

When delivery slows, the conversation often turns to team velocity, backlog prioritisation, or developer tooling. But in many organisations, the real constraint isn’t inside the product team, it’s upstream or alongside it. Platform teams, infrastructure teams, shared services. The groups meant to enable delivery quietly become the thing that holds it back. And not because they’re underperforming. Because they’re overwhelmed.

When delivery slows, it’s tempting to look at the backlog, the sprint, or the team. But often, the real issue sits between teams, where ownership is shared, fragmented, or unclear.

Many teams adopt Agile in the hope of moving faster. They introduce sprints and stand-ups, visualise the work, and improve discipline at the team level. The process brings rhythm, visibility, and a sense of progress. And yet, delivery is still slow. Work gets done, but the value takes too long to reach users. Dependencies multiply. Coordination becomes a constant effort. Every step forward seems to rely on waiting for someone else. "We're doing Agile", but are we really being agile?