agile manifesto

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.

Measuring Progress: The Value of Working Software

Back to Basics Series – Principle 7

Working software is the primary measure of progress.

https://agilemanifesto.org/principles.html

What Does It Mean?

This principle is deceptively simple: the best way to know if we’re making progress is by seeing real, usable software in the hands of users. It’s not about counting story points, tracking velocity, or completing checklists. Progress is tangible when the software actually works and delivers value.

Agile flips the traditional notion of “progress reporting” on its head. Instead of dashboards or status reports, the measure is real outcomes.

My Experience

I’ve worked with companies obsessed with metrics like velocity and burndown charts. Those numbers looked great on paper, but when the release finally hit users, the feedback wasn’t flattering. Features were incomplete, misaligned with user needs, or never even made it into production.

On the flip side, I coached a team that prioritized delivering a minimal, working version of each feature every sprint. Even if it wasn’t fully polished, they got feedback early, fixed issues, and iterated. By the end of the quarter, they had software that actually solved problems for users—progress they could see, measure, and celebrate.

Why This Matters

Focusing on working software keeps teams aligned with what truly matters: value delivered to customers. When we fixate on metrics, process, or artifacts instead, we risk losing sight of the end goal.

Teams that measure progress by working software:

  • Identify problems early.
  • Adapt features to actual user needs.
  • Avoid wasted effort on deliverables that don’t matter.

Teams that measure progress by points or documents:

  • Chase the wrong targets.
  • Celebrate work completed, not work that matters.
  • Risk delivering irrelevant or low-value features.

The principle is a reminder: if it’s not working software, it’s not progress.

Take It to Your Team

For your next retrospective or sprint review:

  • Look at the work delivered in the last sprint. Did it produce working software?
  • Ask: How do we know this actually delivers value to the customer?
  • Brainstorm one small change to ensure that every sprint includes something tangible and usable for users.

This isn’t about shipping unfinished products—it’s about using working software as your true north for measuring progress.

Maximize Team Communication with Face-to-Face Conversations

Back to Basics Series – Principle 6

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

https://agilemanifesto.org/principles.html

What Does It Mean?

When the Agile Manifesto was written in 2001, this principle made perfect sense—most teams sat together, and hallway conversations or quick huddles solved problems faster than a chain of documents or emails ever could.

Fast forward to today: distributed and remote-first teams are the norm. Does that mean this principle is outdated? Not at all. The spirit of it still applies: real-time, direct communication beats slow, layered communication every time.

Face-to-face isn’t about physical presence—it’s about clarity, speed, and connection.

My Experience

I’ve seen both sides of this. At one company, a dependency issue took weeks to resolve because teams were trading Jira comments and Confluence updates back and forth, but no one actually talked to each other. Once they finally got on a Zoom call, the problem was solved in 20 minutes.

At another organization, we made it a habit that if a Slack thread hit more than five messages without resolution, the next step was: “Jump on a quick call.” That small nudge shifted the culture. Misunderstandings dropped, trust grew, and blockers moved faster.

It’s not about forcing more meetings. It’s about knowing when asynchronous communication isn’t enough and valuing direct conversation as a first-class tool.

Why This Matters

Written words are powerful, but they’re also easy to misinterpret. Real-time conversation adds tone, nuance, and empathy. It builds relationships, not just documentation.

When teams lean only on tickets, emails, or documents:

  • Issues drag out.
  • Context gets lost.
  • Frustrations build.

When they embrace real-time conversation:

  • Questions get answered faster.
  • Trust and collaboration improve.
  • Teams spend less time “managing” communication and more time delivering value.

Take It to Your Team

Try this as an experiment:

  • In your next sprint, agree as a team on a “conversation trigger.” For example: “If an issue isn’t moving after 24 hours of async updates, we’ll schedule a 15-minute real-time chat.”
  • At the end of the sprint, reflect: Did conversations accelerate progress? Did they reduce misunderstandings?

You don’t need to meet more—you need to connect better.

Cultivating Team Motivation in Agile Projects

Back to Basics Series – Principle 5

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

https://agilemanifesto.org/principles.html

What Does It Mean?

This principle is deceptively simple: find motivated people, support them, and trust them. That’s it. No heavy processes, no micromanagement, no command-and-control.

Agile isn’t about squeezing productivity out of people—it’s about unleashing it. And the best way to do that is to build an environment where motivated individuals can thrive. That means psychological safety, clarity of purpose, and a culture that values outcomes over output.

My Experience

Over the years, I’ve seen what happens when this principle is ignored. I’ve coached teams where leadership claimed to “trust the team” but then second-guessed every decision, rewrote stories in the backlog, or imposed unrealistic deadlines. Motivation tanked. The team stopped taking initiative because they knew their work would just get reworked or dismissed.

On the flip side, I’ve also seen environments where leaders truly gave teams space. One team I worked with was experimenting with automation to cut down on manual testing. Instead of demanding a business case or ROI analysis, leadership said, “Go for it. Show us what you learn.” Within a few sprints, the team had cut regression testing time in half. Their motivation soared because they were trusted to make decisions that mattered.

Why This Matters

Motivated individuals don’t just “do the work”—they own the work. They solve problems creatively, they support one another, and they find better ways forward.

When leaders fail to support and trust their teams, they may still get output—but it’s compliance-driven, not commitment-driven. The cost? Innovation stalls, burnout rises, and turnover climbs.

But when teams are motivated and trusted:

  • They take pride in quality.
  • They experiment and improve continuously.
  • They deliver outcomes that exceed expectations.

Motivation can’t be mandated, but it can be cultivated. And that’s where real agility comes alive.

Take It to Your Team

In your next retrospective, ask the team:

  • On a scale of 1–5, how motivated do you feel working on this project right now?
  • What’s giving you energy? What’s draining it?
  • What’s one thing leadership or the team could change to create a more supportive environment?

This isn’t about rating individuals—it’s about surfacing what fuels (or kills) motivation.