agile principles

The Future of Agility: Looking Ahead to 2026

Over the past several weeks, I’ve explored some of the biggest shifts shaping Agile in 2025 — from the return to basics to the rise of AI-driven agility, from platform engineering to value stream thinking, from hybrid development approaches to hyper-collaboration and evolving roles.

Each of these trends points toward a single, unmistakable truth:

Agility isn’t about frameworks anymore — it’s about mindsets, outcomes, and adaptability.

As we look toward 2026, I see the Agile world continuing to evolve in three key directions: simplification, augmentation, and integration.

Let’s take a closer look at where we’ve been — and where we’re headed.

1. Back to Basics — The Simplification Revolution

We started the series with what I still believe is the most critical conversation: getting back to Agile basics.

Somewhere along the way, many organizations overcomplicated agility with layered frameworks, rigid ceremonies, and too many tools chasing too little purpose. But the best teams are rediscovering that simplicity works.

In 2026, I hope to see even more organizations stripping away the unnecessary and focusing on what truly matters: clear goals, empowered teams, continuous feedback, and incremental delivery.

We’ll see more leaders asking:

  • “What value are we delivering this sprint?”
  • “What’s getting in our way?”
  • “How do we make it simpler?”

Those are the questions that keep agility human — and sustainable.

2. AI as a Co-Pilot, Not a Replacement

The second major theme of this year was AI-driven agility, and this trend will only accelerate in 2026.

We’ve moved beyond the novelty phase. AI isn’t just assisting developers or automating testing — it’s helping coaches, product managers, and entire teams make better decisions.

In my own work, I’ve used ChatGPT to generate epics and user stories from raw ideas, saving hours of prep time and giving my team a strong foundation for backlog refinement. I’ve also piloted this with development and HR tech teams — and the results were impressive.

In 2026, I expect this to become common practice. AI will be a collaborator in the agile process — helping us synthesize data, predict risks, and visualize flow — while humans focus on context, creativity, and connection.

The real opportunity isn’t in automation. It’s in augmentation — using AI to free us from the busywork so we can spend more time on meaningful work.

3. Platform Engineering and the Rise of Outcome-Driven Ops

Another trend reshaping Agile delivery is the evolution of DevOps into Platform Engineering.

In 2025, this shift began to take hold — dedicated platform teams building self-service environments that empower developers and accelerate flow. In 2026, I believe we’ll see this model become the norm for large enterprises.

The key difference is cultural: Platform Engineering isn’t just about infrastructure — it’s about creating leverage. It’s how organizations ensure teams can deliver independently without sacrificing governance or security.

The best platform teams measure success not by uptime or deployments, but by developer experience and time to value — the outcomes that matter most.

4. Value Stream Thinking — The True “Definition of Done”

In 2025, we started reframing “done” to mean value realized, not just code shipped.

That mindset shift — from output to outcome — is profound. It requires courage from leadership and patience from teams. It also demands systems that make value visible, from idea to delivery to customer impact.

In 2026, I believe more organizations will adopt Value Stream Management as a strategic discipline. We’ll see metrics evolve from velocity charts to value metrics — like cycle efficiency, customer satisfaction, and innovation throughput.

The companies that think beyond quarterly numbers will continue to lead. As Simon Sinek reminds us in The Infinite Game, the ones that play for long-term impact are the ones that truly change their industries.

5. The Hybrid Future of Development

The debate between Agile vs. Spec-Driven Development (SDD) is fading. In its place, we’re seeing hybrid models emerge — blending the structure of SDD with the flexibility of Agile.

In 2026, I expect this hybridization to accelerate, especially as AI helps automate specification creation, traceability, and documentation.

It’s not about choosing sides anymore. It’s about choosing what works — a theme that runs through every part of agility’s evolution.

6. Hyper-Agility and Real-Time Collaboration

Teams are becoming faster, more visual, and more connected.

In my teams, we use Lucidspark over Zoom to run real-time collaboration sessions — mapping value streams, visualizing customer journeys, and creating epics on the spot. Lucidspark integrates with Jira and Confluence, allowing us to maintain a single source of truth from ideation to delivery.

In 2026, expect to see more teams working this way — embracing asynchronous collaboration tools powered by AI, and creating seamless bridges between brainstorming and execution.

We’re finally closing the gap between thinking and doing.

7. The Embedded Agile Coach

Finally, we’ve seen the role of the Agile Coach transform.

As I shared in the last post, moving from Scrum Master to embedded coach changed how I viewed the system. Instead of coaching teams in isolation, we began to coach the organization itself — surfacing systemic blockers, aligning strategy to delivery, and enabling agility at scale.

This trend will deepen in 2026. Agile Coaches will become strategic partners, helping shape culture, leadership behaviors, and operating models. They’ll use data, empathy, and AI insights to guide decisions that stick.

The future of coaching isn’t about enforcing ceremonies — it’s about cultivating environments where agility can grow naturally.

So, What’s Next?

If 2025 was the year of rediscovery — of returning to values, rethinking roles, and rehumanizing agility — then 2026 will be the year of integration.

Agility won’t live in a corner of the org chart anymore. It will be embedded in leadership, technology, culture, and operations. AI will be a partner. Platform teams will be enablers. Coaches will be catalysts.

And simplicity — the value we started with — will remain the north star.

As we move into this next era, I’ll continue to ask the same guiding question that’s defined my journey so far:

“What actually works for us, right now, in our context?”

Because that’s the heart of agility — not dogma, not frameworks, but discovery.

Here’s to 2026 — the year we stop talking about doing Agile and start fully being Agile.

Spec-Driven Development Meets Agile: A Hybrid Approach

Agile has always prided itself on flexibility — responding to change over following a plan. But as organizations have matured, the pendulum has swung between two extremes: unstructured agility on one end and rigid governance on the other.

Now, we’re seeing a convergence — a hybrid future where Spec-Driven Development (SDD) and Agile meet to balance clarity with creativity. It’s a model that honors Agile’s adaptability while embracing the discipline needed for large-scale systems, compliance-heavy industries, and multi-team coordination.

The challenge? Doing it without losing the essence of agility.

Why the Shift Is Happening

For years, Agile was the antidote to traditional waterfall methods that locked teams into fixed requirements. But as Agile scaled, new complexities emerged: multiple teams, shared dependencies, and overlapping product domains.

Suddenly, “just-in-time” requirements weren’t always enough. Teams needed stronger alignment, clearer boundaries, and predictable delivery models — especially when integrating with systems that demanded regulatory precision or safety validation.

That’s where Spec-Driven Development began to re-enter the conversation.

SDD emphasizes clear specifications, structured documentation, and traceable requirements. When applied thoughtfully, it doesn’t slow teams down — it creates shared understanding. The problem has never been the spec itself; it’s been treating the spec as static rather than living.

The hybrid model keeps the structure but invites agility into how that structure evolves.

Where Agile Still Wins

Agile remains unbeatable when it comes to adaptability, collaboration, and learning through iteration. It’s rooted in human feedback and fast loops — qualities that keep teams responsive to real customer needs.

In a purely spec-driven environment, teams risk overconfidence in the plan. In a purely Agile one, they can fall into chaos without shared direction. The hybrid model ensures we don’t sacrifice either.

It says: Define enough to align, but not so much that you eliminate discovery.

Agile wins when uncertainty is high — when you’re breaking new ground or solving novel problems. Specs win when the work is repeatable, regulated, or safety-critical. Blending the two allows leaders to allocate structure strategically, instead of applying one-size-fits-all methods.

How Hybrid Delivery Works in Practice

At its best, a hybrid delivery model builds a spec for stability and uses agility for innovation.

Here’s how it plays out across a product lifecycle:

  1. Define the constants.
    Establish what’s non-negotiable — the regulatory requirements, security constraints, and architectural foundations that create stability. These form your “spec-driven” backbone.
  2. Iterate on the unknowns.
    Use Agile principles to explore customer problems, prototype solutions, and validate assumptions quickly. The areas of uncertainty should remain flexible, open to learning and adaptation.
  3. Keep the spec living.
    Treat specifications like user stories — always evolving as you learn. A living spec creates traceability and adaptability.
  4. Integrate feedback loops.
    Every iteration should refine not just the product, but the spec itself. This turns documentation into a tool for discovery rather than a relic of planning.
  5. Use AI to bridge the two worlds.
    AI tools can analyze changes across systems, generate traceable documentation automatically, and surface where evolving code has drifted from the original design intent. This is where structure meets speed.

AI doesn’t just automate documentation — it enhances alignment. Imagine an intelligent assistant that flags when a user story’s acceptance criteria conflict with a system constraint, or one that keeps design specs synchronized with code repositories.

That’s not theoretical anymore. Tools from GitHub Copilot to Atlassian Intelligence are beginning to make this hybrid agility real.

The Cultural Bridge: Governance with Growth

Hybrid models require more than process adjustments — they demand cultural balance.

Traditional governance often feels like control. Agile governance, on the other hand, feels like enablement — creating safety to experiment within understood boundaries.

The best organizations understand that discipline is not the opposite of agility; it’s a prerequisite for scaling it responsibly.

In Agile culture, we want teams to experiment, but not in isolation. We want to minimize bureaucracy, but not at the cost of quality or compliance. Hybrid delivery achieves this by aligning everyone on outcomes while still giving teams autonomy in how they achieve them.

That alignment comes from shared language and mutual trust — not more meetings or heavier documentation.

When I’ve coached organizations through this transition, I’ve found that the biggest barrier isn’t process—it’s fear. Teams fear losing autonomy. Leaders fear losing visibility. The hybrid approach, done right, replaces both with confidence—a clear view of what matters and freedom to deliver it.

Rethinking Success: Outcomes Over Outputs

Hybrid delivery models can only succeed when success is defined by outcomes, not outputs.

This is where many companies get it wrong. They fall back into spec-driven metrics—how many documents completed, milestones hit, or hours logged. But none of those guarantee impact.

Instead, hybrid agility demands a focus on outcomes:

  • Did the product solve the intended customer problem?
  • Did it deliver measurable business value?
  • Did the team learn something that improves future delivery?

This shift connects directly to value stream thinking — looking beyond the completion of tasks to the flow of customer value through the system.

Agile and SDD can coexist beautifully when guided by shared purpose and metrics that matter.

Why Hybrid Is the Future

The reality is this: most organizations already operate in a hybrid world, even if they don’t call it that. They’ve combined elements of SAFe, Scrum, Kanban, and systems engineering.

What’s changing in 2025 is intentionality — leaders are starting to design hybrid models consciously, not accidentally.

We’re seeing it in regulated industries like healthcare and finance, where compliance requires traceability but innovation demands speed. We’re seeing it in global tech companies integrating AI into core products.

Hybrid agility gives teams the freedom to innovate responsibly. It acknowledges that agility without alignment leads to chaos, and alignment without agility leads to stagnation.

The future isn’t about picking sides between “spec” and “scrum.” It’s about creating a system where structure supports discovery—not suffocates it.

Bringing It All Together

In the early days of Agile, the manifesto asked us to value working software over comprehensive documentation. That principle still holds. But in a complex, interconnected world, some documentation isn’t just valuable — it’s vital.

The difference today is that our documentation can live, breathe, and evolve. It can become a conversation instead of a contract.

That’s what this hybrid future represents: a return to purpose-driven structure, where plans exist to guide learning, not restrict it.

When done right, it’s not Agile vs. Spec-Driven — it’s Agile and Spec-Driven, aligned around shared outcomes, supported by intelligent systems, and driven by teams who understand both the “why” and the “how.”

That’s not a compromise. That’s maturity.

References

  • Gartner, Agile Outlook 2025: Balancing Speed and Stability
  • Atlassian, Intelligent Collaboration and the Hybrid Future of Agile (2024)
  • DORA, Accelerate: State of DevOps Report (2024)
  • McKinsey Digital, Engineering Excellence and the Future of Hybrid Delivery (2024)

Redefining ‘Done’: Embracing Value Stream Thinking

For as long as Agile has been around, teams have measured progress by velocity, burndown, and sprint completion. We celebrate when work is “done.” But over the years, “done” has become one of those words that means everything—and nothing.

It’s time we redefine it.

In 2025, “done” isn’t about completing work. It’s about creating value—measurable, meaningful, and sustainable value that improves outcomes for customers, teams, and organizations.

That’s where Value Stream Thinking comes in.

The Evolution of “Done”

In the early days of Agile, the Definition of Done was simple and tactical: code committed, tested, deployed, documented. It gave teams clarity and accountability. But as organizations scaled, that definition became limited.

Teams were hitting their sprint goals, yet customers weren’t always happier. Projects were finishing on time, but outcomes weren’t improving. We were producing more, but not necessarily better.

I’ve worked in multiple companies where success was measured almost entirely by output—number of features shipped, tickets closed, or sprints completed. Those metrics may look good on dashboards, but they don’t tell you if you’re solving the right problems.

Value Stream Thinking challenges that. It forces us to zoom out from the backlog to the big picture—to focus on flow, impact, and purpose.

What Is Value Stream Thinking?

A value stream is the entire flow of work from idea to outcome—everything it takes to deliver value to a customer.

It’s not just development or delivery. It includes strategy, design, operations, feedback, and learning. Value stream thinking asks us to map that entire system, identify friction points, and optimize the flow of value across it.

Lean and DevOps communities have long embraced this concept, but its relevance to Agile has never been stronger.

When teams think in terms of value streams instead of functions or projects, they break down silos. They start asking questions like:

  • Where does work get stuck?
  • How long does it take for an idea to become customer value?
  • What steps actually add value—and which ones just create busywork?

Those questions don’t just improve delivery. They change the conversation from what are we building? to why are we building it?

Mindshift: From Output to Outcome

To truly adopt value stream thinking, we need a mindset change—and this is where many organizations stumble.

Too many still prioritize activity over impact. They’re driven by quarterly numbers, stakeholder demands, and delivery checkboxes. But optimizing for output creates a false sense of progress. You can ship 100 features that make no difference to your users.

Outcome-driven organizations measure success differently. They focus on customer satisfaction, reduced friction, increased retention, and business adaptability.

In my experience, the hardest part of this transition isn’t the tooling—it’s the thinking. You can’t transform your value streams if leadership still rewards teams for volume instead of value.

Those companies that look beyond quarterly metrics are the ones that change their industries for good.

Simon Sinek describes this perfectly in The Infinite Game when he says,

“Finite players play to beat the people around them. Infinite players play to be better than themselves.”

Companies like Apple, Patagonia, and Costco didn’t win because they moved faster than competitors. They won because they focused on why they existed, who they served, and how they could improve lives—not just balance sheets.

Sinek’s Start With Why, Leaders Eat Last, and The Infinite Game are all essential reads for anyone leading Agile transformation today. He tells the stories of organizations that stopped measuring success by competition and started measuring it by contribution. That’s the essence of value stream thinking.

The Three Pillars of Value Stream Thinking

1. Visibility

You can’t improve what you can’t see. Value stream mapping provides a visual representation of how work flows—and where it doesn’t.

By identifying handoffs, bottlenecks, and redundancies, organizations gain a shared understanding of where time and value are lost.

But visibility isn’t just about data dashboards. It’s about transparency of intent. Everyone—from leadership to engineers—should understand how their work connects to business and customer outcomes.

When teams see how their contributions fit into the larger system, engagement skyrockets.

2. Flow

Flow isn’t just about moving faster. It’s about removing friction and waste so value moves smoothly from idea to delivery.

AI is becoming a valuable ally here. Intelligent observability and workflow tools can now analyze flow efficiency, predict bottlenecks, and recommend optimizations automatically.

For example, I use AI in my own Agile coaching practice to generate and refine epics and user stories for my team. That automation saves time and allows us to focus on what matters, not just how we structure it.

Platform and delivery teams can do the same—using AI to highlight inefficiencies or automate routine steps so humans can focus on creative problem-solving.

That’s the power of pairing flow with focus.

3. Feedback

Every value stream needs feedback loops that connect customer outcomes back to the teams delivering them.

That means looking beyond project retrospectives or sprint reviews—it means continuous measurement of real-world impact.

Are customers adopting the feature we built? Did it improve their experience? Did it align with our purpose?

When teams measure outcomes this way, they start designing with empathy and strategy, not just deadlines.

Why This Requires Cultural Alignment

Value stream thinking can’t thrive in a culture that prizes speed over substance.

It requires psychological safety to question the status quo. It requires leaders who prioritize long-term outcomes over short-term optics. And it requires shared accountability across departments—not “engineering vs. product,” but “we’re all part of the same flow.”

The best organizations I’ve seen practice value stream thinking not as a framework, but as a philosophy. They understand that agility isn’t about delivering faster; it’s about delivering better.

They empower teams to challenge wasteful processes. They reward learning, not just delivery. They understand that simplicity and purpose drive innovation far more than complex frameworks ever could.

The New Definition of Done

If “done” used to mean something is shipped, the new definition should be this:

“Done means we’ve delivered measurable value to the customer—and learned something that helps us deliver even more next time.”

That’s a subtle shift, but it’s everything. It turns Agile back into what it was always meant to be: a feedback-driven, purpose-centered way of working.

And when leaders embrace that mindset—when they stop chasing quarterly wins and start playing the infinite game—they don’t just improve their teams. They transform their industries.

Because in the end, output ends when the sprint ends. Outcome endures.

References

  • Simon Sinek, Start With Why (2009)
  • Simon Sinek, Leaders Eat Last (2014)
  • Simon Sinek, The Infinite Game (2019)
  • Gartner, Agile Outlook 2025: The Age of Contextual Agility
  • DevOps Research and Assessment (DORA), Accelerate State of DevOps Report 2024
  • McKinsey & Company, Value Stream Excellence in Digital Transformation (2024)

Back to Agile Basics: Why Simplicity Is the New Competitive Edge

Simple is Better

If you’ve followed my writing for any length of time, you’ve probably noticed that I tend to come back—again and again—to Agile basics. It’s not because I’m nostalgic for 2001 or trying to relive the early days of software delivery. It’s because somewhere along the way, we’ve drifted from the core of what made Agile powerful in the first place.

We’ve layered frameworks on top of frameworks. We’ve created certifications, roles, and processes that often do more to complicate delivery than to simplify it. And ironically, in our quest to scale agility, many organizations have ended up recreating the very bureaucracy Agile was designed to dismantle.

As we finish up 2025 and head into 2026, I’m convinced that the teams who will thrive in this new era are the ones who deliberately go back to basics—teams that rediscover simplicity, focus on delivering value, and adapt based on feedback rather than ritual.

Because here’s the truth: simplicity isn’t a step backward. It’s a competitive edge.

Remember Why Agile Worked in the First Place

Let’s go back to the Agile Manifesto for a moment. It’s twenty-four years old now, and yet its principles read like a breath of fresh air in an industry drowning in process.

“Simplicity—the art of maximizing the amount of work not done—is essential.”

That single line might be the most misunderstood (and most ignored) principle in modern Agile. When the manifesto was written, simplicity wasn’t a side note—it was a foundation. The early Agile movement wasn’t about ceremonies or roles or maturity models. It was about removing waste and increasing flow.

Agile worked because it was lean, empirical, and human-centered. Teams focused on delivering small slices of value, inspecting the results, and adapting quickly. They didn’t need an org chart of roles to do that; they needed clarity of purpose, empowered people, and fast feedback loops.

Over time, though, we started codifying and scaling that success. Frameworks like SAFe, LeSS (I like LeSS, BTW. Look for a post on that in the future.), and Scrum@Scale tried to make Agile more predictable at enterprise levels—which wasn’t inherently bad. But somewhere between “inspect and adapt” and “follow the framework,” the spirit of agility got lost.

Complexity Creep: How We Overcomplicated Agility

I’ve seen it firsthand across organizations of every size: teams struggling under the weight of processes that don’t serve them. Instead of agility being a mindset, it’s become a checklist.

  • Every meeting is prescribed.
  • Every artifact is templated.
  • Every role is defined down to the hour.

We’ve replaced thinking with following.

And ironically, that rigidity creates the very pain we’re trying to avoid:

  • Long feedback cycles.
  • Confusion about ownership.
  • Teams “doing Agile” instead of being Agile.

As Agile coach Barry Overeem once put it, “When a framework becomes the goal instead of the means, agility dies.”

This doesn’t mean frameworks are bad. Frameworks can be incredibly helpful starting points—they give structure, consistency, and a shared vocabulary. But they were never meant to be the destination. They’re scaffolding, not architecture.

The Simplicity Mindset

So what does it mean to return to simplicity? It’s not about stripping away everything and declaring “no process.” It’s about adopting a simplicity mindset—an intentional effort to reduce friction, focus on what matters, and make space for learning.

Here’s what that looks like in practice:

  1. Start with your current reality.
    Too often, teams adopt frameworks wholesale rather than examining what actually needs improvement. Start by asking, “What’s causing pain in our flow?” and “What’s blocking value delivery?” Then build from there—incrementally.
  2. Keep ceremonies purposeful.
    If a meeting doesn’t drive learning or decision-making, shorten it or eliminate it. The goal isn’t to follow Scrum to the letter; it’s to enable communication, transparency, and improvement.
  3. Optimize for feedback, not process.
    The faster you can learn from users, the faster you can adapt. Focus on shortening feedback loops—through demos, experiments, or even simple stakeholder check-ins.
  4. Empower teams to adapt.
    Give teams the freedom to tailor their own ways of working. Encourage them to experiment, simplify, and evolve their process based on evidence—not dogma.
  5. Measure outcomes, not outputs.
    Shift focus from how many story points you’ve completed to what value you’ve delivered. Are customers happier? Are users getting what they need faster?

When simplicity becomes the foundation, everything else gets easier. Predictability improves. Quality increases. Teams communicate more clearly. Leaders make better decisions because they’re closer to reality.

Why Simplicity Is a Strategic Advantage

In a world defined by uncertainty and AI-driven acceleration, complexity is the enemy of adaptability.

Organizations that simplify can move faster because their decision loops are shorter. They can pivot when markets change. They can innovate without being bogged down by process debt.

Research from McKinsey (2024) supports this: companies that streamline their delivery systems and reduce handoffs are 40% more likely to meet time-to-market goals and twice as likely to report high team morale. Similarly, Gartner’s 2025 Agile Outlook emphasizes “contextual agility” — tailoring practices to fit the environment rather than adopting a one-size-fits-all framework.

In other words, simplicity scales. Not because it’s less work, but because it focuses teams on what actually matters.

A Personal Observation

In my own experience coaching teams and leaders, the highest-performing ones aren’t those with the most mature framework or the most polished Jira dashboards. They’re the ones who understand their purpose, make decisions quickly, and keep communication open and honest.

When teams cut out what doesn’t serve them—extra layers of process, unnecessary approvals, redundant reports—they create the space for meaningful work.

And perhaps more importantly, they rediscover why they’re working that way in the first place.

That’s what simplicity gives us: clarity, focus, and alignment.

Getting Started: Your Simplicity Reset

If your team is feeling stuck, overwhelmed, or weighed down by ceremony, try this exercise:

  1. List every meeting, report, or ritual you perform in a sprint.
  2. For each, ask:
    • What value does this add?
    • What would happen if we removed or shortened it?
    • Is there a simpler way to achieve the same goal?
  3. Experiment with one simplification per sprint and inspect the results.

You don’t need to overhaul your process overnight. Small simplifications—done consistently—create compounding gains over time.

Final Thoughts

Agile has always been about people and outcomes over process and tools. Somewhere along the line, we inverted that.

But the good news is: we can find our way back.

If we start small, stay curious, and keep the simplicity mindset at the center of how we work, we can reduce friction, increase value, and build organizations that are genuinely adaptive—not just performatively Agile.

As we move into this next era of work—where AI, distributed teams, and constant change are the norm—the most resilient organizations won’t be the ones with the most elaborate systems.

They’ll be the ones that choose simplicity, clarity, and continuous learning.

Because in 2026, simple = sustainable.

References:

  • Beck et al., Manifesto for Agile Software Development (2001)
  • McKinsey & Company, The State of Agile Delivery in 2024
  • Gartner, Agile Outlook 2025: The Age of Contextual Agility
  • Overeem, Barry. Scrum.org Blog: “Revisiting the Agile Manifesto in 2024”

Bridging the Gap: From Doing Agile to Being Agile

In our last post, we revisited the Agile Manifesto and asked a simple—but critical—question: are we living these principles, or merely following a process?

Today, we’re going to turn reflection into action. Let’s explore how teams and leadership can identify where they’re stuck in “doing” and start moving toward truly being agile.

Step 1: Map Your Practices to Principles

Start by taking the 12 Agile principles and asking your team to rate current adherence:

  • ✅ “We actively practice this principle”
  • ⚠️ “We sometimes practice it, inconsistently”
  • ❌ “We don’t practice this at all”

This exercise exposes gaps between philosophy and practice. It also sparks conversation about why some principles are harder to live than others.

Example Question:

  • Principle 4: Business people and developers must work together daily throughout the project.
  • Do we collaborate daily, or do handoffs dominate our workflow?

Step 2: Identify “Doing Agile” Behaviors

Next, list behaviors or rituals that are performed for the sake of Agile, rather than its intent.

Common examples include:

  • Filling Jira fields just to satisfy reporting requirements
  • Conducting daily stand-ups as status updates instead of collaboration
  • Strictly following a framework despite team context or constraints

Ask: Which activities feel like checkboxes? Which ones genuinely improve delivery, collaboration, or learning?

Step 3: Leadership Reflection

Agility starts at the top. Leaders should reflect on:

  • Are we trusting teams to self-organize?
  • Do we encourage experimentation, or do we punish failure?
  • Are metrics used to inform decisions, or to assign blame?

Even one small change in leadership behavior—like removing a reporting requirement that doesn’t add value—can dramatically improve team agility.

Step 4: Create an Action Plan

Once gaps are identified, teams should:

  1. Pick one principle to focus on for the next sprint or month.
  2. Define specific behaviors or experiments that demonstrate true adherence.
  3. Inspect the results at the next retrospective and adapt accordingly.

Example: If teams struggle with Principle 3 (frequent delivery), the experiment might be to deliver smaller, usable increments weekly instead of waiting for a “big bang” release.

Step 5: Make Reflection a Habit

Finally, make this practice part of your regular cadence:

  • Quarterly “Agility Health Checks”
  • Retrospectives focused on principles rather than just deliverables
  • Leadership check-ins reviewing how teams are being agile, not just doing agile

Agility isn’t a one-time project. It’s continuous reflection, adjustment, and alignment with core principles.

Take It to Your Team

  1. Principle Mapping Exercise – Spend 30–45 minutes mapping practices to principles and rating adherence.
  2. Behavior Audit – Identify one ritual that is “doing agile” without delivering value.
  3. Experiment Sprint – Pick one principle to focus on and define an experiment to live it more fully.

Agility is a practice, not a checklist. By reflecting honestly and taking targeted action, teams and leaders can close the gap between being agile and doing agile—and start seeing real benefits in collaboration, delivery, and learning.

Being_Agile_vs_Doing_Agile_WorksheetDownload

Revisiting the Agile Manifesto: Are We Truly Being Agile?

It’s been over two decades since 17 developers met in Utah to draft the Agile Manifesto. They weren’t trying to create a rulebook—they were trying to articulate a better way of working, a philosophy for software development that emphasized people, collaboration, adaptability, and delivering value.

And yet, if you look around today, I can’t help but wonder: how many organizations are truly living these principles, rather than just following a methodology?

What Industry Leaders Are Saying

Kent Beck, one of the co-authors of the Agile Manifesto, recently reflected on his career and the evolution of development practices. Even with decades of experience, he finds excitement in experimenting with modern tools and approaches, emphasizing continuous learning and adaptation as core to being agile rather than doing agile (Business Insider).

Agile consultant Niall O’Keeffe stresses that the core values of Agile remain relevant, but that today’s context has changed. He calls for a reassessment of how principles are applied in modern teams (LinkedIn).

Similarly, Joe Van Os, in his piece Revisiting the Principles of Being Agile, notes that while the principles themselves are timeless, many organizations struggle to adapt them to new technologies and modern challenges (Medium).

Even organizations like the Scrum Alliance remind us that Agile principles should guide behavior, not dictate process. They emphasize that teams should revisit these principles regularly to ensure they remain relevant and effective (Scrum Alliance).

My Take: BE Agile, Don’t Just DO Agile

Here’s where I see a huge gap. So many companies have latched onto methodologies, frameworks, and metrics without understanding the why behind the Agile Manifesto. They track data, enforce strict workflows, and later blame teams when the “process” isn’t followed perfectly.

But the manifesto never commands. It doesn’t tell teams to track every metric or enforce a specific way of working. Its message is simple: focus on individuals and interactions, working software, customer collaboration, and responding to change.

The problem is that many organizations confuse being agile with doing agile. They try to execute rituals, dashboards, and reports, but miss the essence: adapting to change, delivering value continuously, and empowering people. True agility is a mindset, not a set of rules.

Why This Matters Today

We live in a world of constant change. Markets, customers, and technology evolve at a pace no rigid process can keep up with. Agile principles were designed to help teams navigate complexity with flexibility and purpose. When organizations ignore these principles in favor of strict adherence to methodology, they sacrifice:

  • Innovation: Teams stop experimenting and learning.
  • Collaboration: Interactions become transactional and process-driven.
  • Value Delivery: Focus shifts to output and metrics, not outcomes.

If we want to see real agility, we need to return to the basics. Revisit the principles. Ask why we do what we do. And remind teams and leadership that Agile is a philosophy, not a performance review tool.

Take It to Your Team

For your next sprint or retrospective, try this:

  1. Ask: Which Agile principles are we actually practicing today? Which ones are we ignoring or bending?
  2. Reflect on whether your team is being agile or just doing agile.
  3. Pick one principle to focus on in the next sprint—then inspect and adapt how it changes your workflow, collaboration, or delivery.

Agility isn’t about checking boxes. It’s about living the values, continuously learning, and adapting. If we forget that, the Agile Manifesto becomes nothing more than words on a page.

Master Agile Principles: The Power of Regular Reflection

Back to Basics Series – Principle 12

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

https://agilemanifesto.org/principles.html

What Does It Mean?

Agile isn’t about sticking rigidly to a plan or blindly following a process. Continuous improvement is baked into the methodology itself. Regular reflection allows teams to inspect what’s working, identify what isn’t, and make changes that actually improve outcomes.

This principle emphasizes rhythm over perfection. It’s not a one-time event; it’s a recurring habit that keeps the team evolving and learning.

My Experience

I’ve seen teams sprint after sprint without pausing to reflect. They executed flawlessly on paper, but recurring issues—missed dependencies, unclear requirements, process inefficiencies—kept cropping up.

When I introduced structured retrospectives and reflection practices, even small adjustments had a huge impact. One team identified that their daily stand-ups were too long and unfocused. By tightening the format and focusing on blockers, they shaved 30 minutes per day off their meetings and surfaced issues faster.

The key is not to wait for a crisis. Reflection should be proactive and continuous, allowing the team to adapt before problems escalate.

Why This Matters

Regular reflection enables teams to:

  • Identify and eliminate inefficiencies
  • Strengthen collaboration and communication
  • Improve quality and delivery speed
  • Adapt to changing circumstances proactively

Teams that skip reflection risk repeating mistakes, building frustration, and stalling improvement. Agile isn’t just about speed—it’s about learning and evolving.

Take It to Your Team

For your next retrospective or sprint review:

  • Ask: What worked well this sprint? What didn’t?
  • Identify one process or habit to experiment with in the next sprint.
  • Set a short feedback loop: Check in mid-sprint to see if the adjustment is helping.

Reflection isn’t optional—it’s the mechanism that transforms good teams into great, adaptable, high-performing teams.

Empowering Self-Organizing Teams for Agile Success

Back to Basics Series – Principle 11

The best architectures, requirements, and designs emerge from self-organizing teams.

https://agilemanifesto.org/principles.html

What Does It Mean?

Self-organizing teams are empowered to make decisions about how they work, how they solve problems, and how they deliver value. Agile trusts that the people closest to the work are best equipped to determine the approach—without being micromanaged from above.

This principle doesn’t mean chaos or lack of accountability. It means giving skilled, motivated teams the environment, tools, and trust to organize themselves. When teams take ownership, innovation, creativity, and efficiency naturally follow.

My Experience

I’ve worked with teams where every decision had to be approved by a manager or architect. Progress was slow, morale was low, and opportunities for innovation were lost.

Contrast that with a self-organizing team I coached in a fintech environment. They defined their own workflow, took ownership of dependencies, and collaboratively solved bottlenecks. Managers and stakeholders provided support, guidance, and trust—but didn’t dictate day-to-day execution. The team delivered faster, made smarter decisions, and produced higher-quality software.

The difference? Ownership. When teams feel accountable and empowered, they step up in ways that no process or document can enforce.

Why This Matters

Self-organization enables:

  • Faster problem-solving and decision-making
  • Ownership and accountability
  • Creative, innovative solutions

Teams that aren’t self-organizing risk:

  • Bottlenecks in approvals
  • Reduced morale and motivation
  • Solutions that don’t leverage the full expertise of the team

Agility is about enabling people, not controlling them. Self-organization is the engine that drives innovation and responsiveness.

Take It to Your Team

In your next retrospective or planning session:

  • Ask: Where did the team wait for direction this sprint?
  • Identify one area where the team could take ownership next sprint.
  • Encourage reflection: How can we remove bottlenecks or approvals that slow our decision-making?

Empowering the team to self-organize doesn’t mean stepping back completely—it means providing support, guidance, and trust so they can deliver their best work.

Maximizing Value through Simplicity in Agile

Back to Basics Series – Principle 10

Simplicity—the art of maximizing the amount of work not done—is essential.

https://agilemanifesto.org/principles.html

What Does It Mean?

Simplicity isn’t just a design goal—it’s a mindset. Agile encourages us to focus on what really matters and cut out what doesn’t. Every unnecessary feature, report, or process step consumes energy, introduces risk, and slows delivery.

The art of maximizing work not done is about prioritizing value over busywork. It’s about trimming the fat so the team can focus on delivering outcomes that truly matter to customers.

My Experience

I’ve coached teams that overloaded their sprints with “nice-to-have” work—features that looked impressive but added little real value. Progress was slow, frustration mounted, and the team lost sight of what the customer really needed.

In another case, a team took a ruthless approach to simplicity. Every user story had to answer one question: Does this deliver clear value to the customer? Work that didn’t meet that standard was deferred or removed. The result? Faster delivery, less rework, and higher satisfaction—for both the team and the customer.

Simplicity also applies to processes. I’ve seen retros, planning sessions, and reporting rituals get bloated with unnecessary steps. Streamlining these often frees time for what really counts: delivering and improving working software.

Why This Matters

Ignoring simplicity leads to:

  • Overcomplicated software
  • Longer delivery cycles
  • Frustrated teams and customers

Embracing simplicity enables:

  • Faster, more focused delivery
  • Easier adaptation to change
  • Clearer focus on value

Agility is not about doing more—it’s about doing what matters and doing it well.

Take It to Your Team

In your next retrospective, try this:

  • Ask: What work did we do this sprint that added little or no customer value?
  • Brainstorm: What can we remove or simplify in the next sprint?
  • Challenge each story, feature, or process step: Does this maximize value or just add complexity?

Remember: every bit of complexity you eliminate is time and energy the team can spend on delivering real value.

Why Sustainable Development is Key to Agile Success

Back to Basics Series – Principle 8

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

https://agilemanifesto.org/principles.html

What Does It Mean?

This principle is simple, but too often ignored: Agile isn’t a race to exhaustion. Teams should be able to maintain a steady, predictable pace without burning out. Sustainable development isn’t about slowing down—it’s about balancing delivery with long-term productivity and well-being.

Agile recognizes that overworked teams produce lower quality, higher defect rates, and less innovation. True agility comes from consistency, not frantic sprints of heroics.

My Experience

I’ve coached teams that were stuck in “crunch mode” culture, sprint after sprint. The result? Stress, mistakes, and disengagement. People were exhausted, and velocity began to fluctuate wildly. Management assumed effort equaled progress—but it didn’t.

In contrast, I’ve also worked with teams that embraced a sustainable pace. One team deliberately sized work for a realistic, maintainable sprint, included buffer time for unexpected issues, and respected weekends and personal time. Over a few quarters, productivity stabilized, quality improved, and morale soared. They weren’t faster on day one—but they delivered more reliably over the long term.

Why This Matters

Sustainable pace is not optional—it’s essential. Without it:

  • Teams risk burnout and turnover.
  • Defects and technical debt grow.
  • Innovation slows to a crawl.

With sustainable pace:

  • Teams maintain focus and energy.
  • Delivery is predictable and consistent.
  • Trust and morale improve.

Agile isn’t about heroics—it’s about creating a rhythm of work the organization can maintain indefinitely.

Take It to Your Team

In your next retrospective, ask:

  • Did anyone feel sprint goals were unrealistic or overwhelming?
  • Where did we overcommit, and where did we leave buffer for uncertainty?
  • Brainstorm one change to improve the team’s pace for the next sprint (e.g., realistic story sizing, planned slack, or stricter prioritization).

Sustainable pace isn’t a shortcut—it’s the foundation for long-term success.