Why Technical Excellence is Crucial for Agile Success

Back to Basics Series – Principle 9

Continuous attention to technical excellence and good design enhances agility.

https://agilemanifesto.org/principles.html

What Does It Mean?

This principle is often overlooked in the rush to deliver. Agile isn’t just about speed—it’s about sustainable, high-quality delivery. Technical excellence and thoughtful design aren’t “nice-to-haves.” They’re essential for creating software that can evolve, adapt, and respond to change without collapsing under its own complexity.

In short: quality fuels agility. Without it, you can’t iterate quickly, safely, or reliably.

My Experience

I’ve coached teams under tremendous pressure to ship features fast. In one case, they repeatedly cut corners on testing and refactoring. At first, it seemed like they were “going fast,” but soon bugs piled up, deployment slowed, and technical debt became a drag on every sprint.

Conversely, I’ve seen teams embrace technical excellence from the start: automated testing, code reviews, modular design, and refactoring as part of their rhythm. They delivered consistently, and when change arrived, they adapted quickly without rewriting everything. It’s not about perfection—it’s about creating software that can keep up with change.

Why This Matters

Neglecting technical excellence has costs:

Increased defects and rework
Slower response to changing requirements
Frustrated teams and customers

Prioritizing it has benefits:

Faster, safer delivery
Confidence in making changes
Long-term maintainability

Agility isn’t just speed—it’s the ability to respond without breaking the system. Technical excellence and good design are the foundation for that ability.

Take It to Your Team

In your next retrospective, ask:

Where did we compromise on quality or design this sprint?
What small practices could we adopt to improve technical excellence? (e.g., pair programming, automated testing, incremental refactoring)
How can we make technical excellence part of our definition of done?

Remember: delivering quickly without quality isn’t Agile—it’s debt accumulation.

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.

Effective Strategies for Remote Agile Meetings

Hybrid & Remote Agile: Reimagining Meetings

I’m breaking from my normal Tuesday/Friday posting schedule, because I think this topic is timely and needed. Currently, I work for a remote-first global company, but we do have offices. From time to time, I go in for gatherings, planning sessions, etc. I can tell you from experience that we ALL need to do better when it comes to meetings and communication. But how?

When Agile first took root, most teams were co-located. You could huddle around a whiteboard, grab someone in the hallway, or brainstorm over sticky notes. Then remote work exploded — and with it, our ceremonies and rituals were forced into little digital boxes.

Today, many organizations are hybrid: some people in the office, some remote, and everyone juggling multiple time zones. Agile hasn’t gone away, but our meetings have to evolve.

Recent research from Ericsson found that retrospectives and brainstorming sessions work best in person, while larger information-sharing meetings are more effective online. The lesson is clear: different types of collaboration thrive in different environments. The challenge for Agile leaders is designing meetings that respect those dynamics — while keeping teams connected no matter where they sit.

1. Be Intentional About Format

Too many teams default to “all-remote” or “all-in-person” without asking what the meeting needs. Instead, design the format around the purpose:

Is this about creativity and energy? → If possible, bring people together physically.
Is this about updates and alignment? → Keep it remote and async-friendly.
Is this about reflection and trust? → Hybrid can work, but only if remote participants are fully included (no second-class citizens on the screen).

2. Respect Human Energy

Hybrid meetings can be draining. Coaches and Scrum Masters should keep a close eye on team energy. A few practical tips:

Keep meetings shorter; use breakout groups for depth.
Rotate times to balance the burden across time zones.
Protect focus time by batching ceremonies instead of scattering them.

Agile isn’t about squeezing every minute into a calendar — it’s about creating the space for valuable conversations.

3. Make Inclusion Visible

Nothing kills a hybrid meeting faster than side conversations among the in-person group while remote teammates stare silently at a screen. Leaders can counter this by:

Using a “remote-first” rule: everyone joins from their own laptop, even in the office.
Nominating a facilitator buddy to monitor chat and hand-raises.
Leveraging collaborative tools (Miro, MURAL, FigJam, Lucidspark) so everyone’s input shows up in the same digital space.

Inclusion doesn’t happen by accident. It has to be designed.

4. Reimagine, Don’t Just Replicate

The biggest trap is trying to replicate in-person practices online. A three-hour workshop with sticky notes doesn’t translate well to Zoom. Instead, reimagine the format:

Break long sessions into shorter, async-friendly sprints.
Replace daily standups with a mix of quick check-ins and async status updates.
Use digital boards not just as mirrors of physical ones, but as living spaces for collaboration.

Hybrid is an opportunity to redesign how we meet, not just to copy old habits onto new platforms.

Closing Thought

Hybrid and remote work aren’t going away. For Agile leaders, the question isn’t how to force old ceremonies into new contexts — it’s how to honor Agile’s intent: meaningful collaboration, transparency, and adaptability.

When we design meetings that respect purpose, energy, and inclusion, we don’t just “make hybrid work.” We create teams that feel connected, valued, and ready to deliver — no matter where they are.

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.

The Power of Frequent Software Delivery

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

https://agilemanifesto.org/principles.html

What Does It Mean?

This one seems obvious, right? Deliver frequently, learn, improve. And yet, I still find myself in conversations about quarterly releases, long stabilization phases, and “big bang” launches. Delivering frequently doesn’t just mean shipping faster—it means building a cadence where feedback can flow back into the product.

Think of it as shortening the distance between building something and learning whether it actually works for the customer. The shorter that loop, the less risk we carry and the more relevant our product becomes.

My Experience

I’ve seen both sides of this coin. On one hand, I’ve coached teams that release every sprint (or even multiple times a sprint) and thrive on the immediate feedback. On the other hand, I’ve also worked in environments where quarterly releases were the “standard.” In those cases, the teams didn’t lack talent or effort—they lacked opportunity.

The backlog filled up with assumptions. Dependencies piled higher with every sprint. By the time the release finally rolled out, some of the features were already outdated, and others didn’t work quite as intended. The team had spent months working in the dark, only to discover the light switch was in the wrong room.

Frequent delivery doesn’t guarantee success, but it does guarantee learning sooner. And learning sooner is almost always cheaper than learning later.

Why This Matters

Cadence matters more than calendar. When teams deliver frequently, they don’t just check a box—they build a rhythm of feedback, improvement, and adaptation.

Contrast that with the “big bang” approach:

Risk piles up quietly until it explodes at release time.
Feedback arrives too late to do anything about it.
Teams end up in crunch mode, patching problems instead of preventing them.

Frequent delivery flips that script. Small, frequent releases reduce risk, increase customer confidence, and create momentum. They also force us to prioritize what’s really valuable instead of endlessly polishing what’s “next.”

Take It to Your Team

In your next retrospective, ask:

How often do we release working software today?
What’s the biggest barrier keeping us from releasing more frequently?
If we had to deliver something every sprint, what would need to change?

Even if you don’t move to every-sprint releases tomorrow, surfacing the barriers is the first step toward breaking them down.

Embracing Change in Agile: A Competitive Advantage – Principle 2

Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

https://agilemanifesto.org/principles.html

What Does It Mean?

Let’s be honest—no one really likes change when it shows up uninvited. Change usually means rework, replanning, and maybe a few uncomfortable conversations. But this principle reminds us that change isn’t failure. In fact, change is opportunity. It means we’ve learned something. It means the customer’s needs have shifted – or OUR needs have shifted – and we have a chance to respond.

Organizations that resist change usually pay the price. They deliver something shiny, new, and already irrelevant. Worse, they frustrate their customers, who wonder why they’re paying for something that doesn’t solve their actual problem.

Agile doesn’t promise stability; it promises adaptability. And adaptability is how we deliver competitive advantage.

My Experience: Dependency “Contracts”

A recent experience brought this principle home for me. I’ve been working (with varying degrees of success) to get teams to better track their dependencies with one another. I’ve tried everything—fields in Jira, slick dashboards, automation rules—you name it. But many folks in the company insisted on writing what they called “Dependency Contracts.”

On the surface, these contracts were actually quite good. They were detailed, thorough, and well-documented. The problem? They lived in Confluence and just sat there. Static. Out of date as soon as they were published. And since teams weren’t actually putting the dependent work into their backlogs, the dependencies were missed altogether.

Guess what? I was right. Work slipped, dependencies got overlooked, and suddenly those carefully-crafted contracts didn’t look so helpful. Now, we’re back at the drawing board—but here’s the positive: there’s far more openness to change. I have a team of agile coaches working on a more dynamic approach to dependency management right now. Hopefully, we’ll see fruit soon.

Why This Matters

The “Dependency Contract” story is a perfect example of what happens when we cling to rigid documents instead of embracing change. Contracts gave the illusion of certainty, but the reality was much messier. Requirements shifted, priorities shifted, and the teams needed a way to adapt—not a static agreement filed away in Confluence.

By welcoming change—acknowledging that dependencies evolve, just like requirements do—we set ourselves up to respond faster and more effectively. And in today’s environment, the ability to respond is the real competitive advantage.

Embracing Change = Embracing Reality

Here’s the truth: change is going to happen whether we like it or not. We can either treat it as a disruption or harness it as fuel. Agile calls us to do the latter.

To wrap it up, this principle is not giving us permission to move the goalposts endlessly. It’s reminding us that adaptability is the point. Embracing change is not weakness—it’s resilience. It’s how we keep delivering value, even when the world refuses to stand still.

Take It to Your Team

In your next retrospective, try this:

Ask the team to recall the last time a change came in late—new requirement, shifting dependency, or customer feedback.
Discuss: Did we treat it as a disruption or as an opportunity? What was the impact?
Brainstorm: What lightweight practice could we try to spot and adapt to change faster next time? (e.g., dependency huddles, backlog refinement tweaks, or simply surfacing assumptions earlier.)

The goal isn’t to prevent change—it’s to build muscle for responding to it.

Back to Basics Series – Picking It Up Again

Six years ago, I set out to write a series of posts exploring the Agile Principles. I only made it through the first one (customer satisfaction through early and continuous delivery of valuable software) before life and work pulled me in a dozen different directions. That’s the reality of being in the trenches—sometimes the practice of agility takes priority over writing about it.

But lately, I’ve been thinking a lot about those principles again. Not in a nostalgic, “wasn’t Agile cool back in the day” sort of way, but in a very practical, “we need this more than ever” sort of way.

Why Now?
The work I’m doing today has surfaced a hard truth: too often, organizations are obsessed with frameworks, tooling, and process compliance while completely missing the spirit of agility. I see teams burning out under heavy governance, leaders mistaking Jira dashboards for real outcomes, and “transformation programs” collapsing under their own weight. Sound familiar?

When I step back, I realize the answers aren’t in some new scaled framework or silver-bullet tool. They’re right where they’ve always been—sitting quietly on agilemanifesto.org. The 12 principles. The basics.

Getting Back to Basics
That’s why I want to revisit this series. Not to make grand revelations or coin new buzzwords, but to remind myself (and maybe you, too) what really matters. These principles have guided us for over two decades, but they only matter if we actively practice them.

So over the coming weeks, I’ll continue breaking down each principle, just as I started before. I’ll share where I see it show up in my work today, the traps I see organizations falling into, and hopefully spark conversations you can take back to your own teams.

Agile isn’t about ceremony. It isn’t about tools. It isn’t about your particular flavor of framework. It’s about principles. And when we drift too far from them, we lose the very thing that made agility powerful in the first place.

It feels like the right time to go back to basics again.