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:

Pick one principle to focus on for the next sprint or month.
Define specific behaviors or experiments that demonstrate true adherence.
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

Principle Mapping Exercise – Spend 30–45 minutes mapping practices to principles and rating adherence.
Behavior Audit – Identify one ritual that is “doing agile” without delivering value.
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_Worksheet Download

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:

Ask: Which Agile principles are we actually practicing today? Which ones are we ignoring or bending?
Reflect on whether your team is being agile or just doing agile.
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.

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.

Daily Collaboration: Bridging Business and Development

Back to Basics Series – Principle 4

Business people and developers must work together daily throughout the project.

https://agilemanifesto.org/principles.html

What Does It Mean?

When the Agile Manifesto was written back in 2001, this was a radical idea. Business and technology working together daily? For many organizations, those groups lived on opposite sides of the wall: business tossed requirements over, and IT tossed timelines back.

This principle is about tearing down that wall. It doesn’t say “once a month status update” or “quarterly alignment session.” It says daily. That’s how important collaboration is. Because when business and developers collaborate continuously, we don’t just build faster—we build the right thing.

My Experience

I’ve coached in organizations where this principle was ignored, and the result was predictable: business teams spent months dreaming up requirements, while developers built exactly what was asked—only to discover it wasn’t actually what the business needed.

I’ve also seen the opposite. In one case, a product team invited developers into every early-stage product conversation. Instead of being “order takers,” developers became creative partners. They brought up technical possibilities and risks early, saving weeks of rework later. The business side loved it because ideas got sharper faster, and developers loved it because they weren’t just building blindly.

It wasn’t always smooth—there were debates, even arguments—but the end product was far stronger.

Why This Matters

When business and developers collaborate daily:

Assumptions surface sooner.
Misunderstandings shrink.
Trust grows.
The product evolves in real-time to meet customer needs.

When they don’t:

Requirements rot in documents.
Developers become order processors instead of problem-solvers.
Products miss the mark, even if they ship “on time.”

The truth is, daily collaboration isn’t about meetings. It’s about partnership. Agile isn’t just a delivery method—it’s a way of connecting business value with technical expertise in a continuous loop.

Take It to Your Team

Try this in your next retro:

Ask: When was the last time business stakeholders and developers sat down together outside of a formal meeting?
Explore: What’s stopping daily collaboration? (Time zones? Culture? Org structure?)
Experiment: Pick one lightweight practice to bridge the gap—maybe a shared Slack channel, a daily 10-minute “business + dev sync,” or inviting business partners into sprint reviews more actively.

The principle isn’t about adding ceremony—it’s about removing walls.

Navigating the Project Seas: Unraveling the Roles of Technical Program Managers and Scrum Masters

In the fast-paced and ever-evolving landscape of project management within agile businesses, the roles of Technical Program Managers and Scrum Masters stand out as crucial components for driving successful project outcomes. Both positions offer unique skill sets and carry specific responsibilities that contribute to the overall efficiency and success of a project. In a recent scenario within my company, the need arose to explicitly define and highlight the individual functions and spheres of influence associated with each role. This served as a means to enhance the comprehension of our contributions and the pivotal value we bring to the projects we manage.

Let’s start with the similarities:

1. Leadership and Facilitation:
– TPMs: Excel in guiding teams through the complexities of large-scale projects, providing strategic direction. They usually do this across multiple, cross-functional teams, often facilitating meetings to coordinate dependencies, risks, and issues.
– Scrum Masters: Facilitate Agile ceremonies, ensuring the team adheres to Scrum principles and practices. They are usually responsible for team performance. They, too, coordinate dependencies, risks, and issues.

2. Communication:
– TPMs: Act as the bridge between technical teams and stakeholders, ensuring effective communication. This takes shape in the form of information radiators (reports, Confluence pages, etc.) and fosters transparency across the org.
– Scrum Masters: Foster open communication within the Scrum team, removing impediments and encouraging collaboration. They also use information radiators through reports or through tools like Jellyfish.

3. Problem Solving:
– TPMs: Tackle overarching project challenges, addressing risks and finding solutions.
– Scrum Masters: Focus on immediate impediments, helping the team overcome day-to-day hurdles.

Now let’s discuss the differences:

1. Scope:
– TPMs: Handle end-to-end project management, considering budget, timelines, and overall success.
– Scrum Masters: Concentrate on the Scrum process, emphasizing iterative development and continuous improvement.

2. Focus on Details:
– TPMs: Dive into the nitty-gritty details of project planning, risk mitigation, and resource allocation.
– Scrum Masters: Concentrate on the details of the Agile framework, ensuring the team adheres to Scrum rituals and principles.

3. Responsibility Level:
– TPMs: Often have a higher organizational impact, dealing with cross-functional teams and aligning projects with business objectives.
– Scrum Masters: Primarily focus on the team level, ensuring that Agile practices are followed for efficient development.

Where there is synergy:

1. Clear Communication Channels:
– Establishing transparent communication channels between TPMs and Scrum Masters is crucial for aligning strategic goals with day-to-day tasks. Scrum Masters have the unique position of being directly involved with their teams and can then communicate in real-time when blockers occur. TPMs can take this information and help the wider org make intelligent decisions.

2. Balancing Priorities:
– TPMs can support Scrum Masters in prioritizing tasks aligned with the overall project objectives, maintaining a balance between short-term goals and long-term vision. Scrum Masters can provide data such as velocity and capacity to TPMs so that project plans are more realistic.

3. Continuous Improvement:
– Scrum Masters contribute to continuous improvement by providing feedback on processes, while TPMs ensure these improvements align with overarching project goals.

The collaboration between Technical Program Managers and Scrum Masters is truly akin to a well-choreographed dance, each party bringing their distinctive strengths to the table, ultimately culminating in a harmonious project management symphony. This seamless partnership intertwines the structured approach and strategic oversight of the Technical Program Manager with the agile methodology and team-focused guidance of the Scrum Master. Recognizing the complementarity and disparities inherent in these roles is pivotal to unlocking their full potential and harnessing their collective capabilities to propel projects toward success. By fostering a deep understanding of the nuanced interplay between these roles, teams can optimize their processes, streamline communication, and adapt swiftly to the evolving demands of complex projects.