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.

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.

On Certifications

When I share with others what training I’ve had, I get questions like “Aren’t you just feeding the certification machine?” or “What do you think all those certifications will get you?” and “Aren’t all of certifications just a racket to take your money?” I guess I could maybe answer yes to two of those questions. As for what I think these certifications will get me… I think they get me a better seat at the table. The reality is this: these certifications mean something to SOMEONE, and many job listings require you to have at least one of them. If you want to advance – like I do – to become a trainer or an agile coach, then these certifications are necessary. However, the other very real benefit to me is maybe a little less tangible to others: I get a rush from learning with like-minded individuals. That rush then translates to real action when I get back to work, so I find these courses – certification or otherwise – valuable.

Still, there’s a cost.

As of the writing of this post, you can get certified as a scrum master through several entities: Scrum Alliance, Scrum.org, Agile Alliance, Project Management Institute (though the certification has a different name), and Scrum Study, just to name a few. Each entity also has a plethora of other certifications you can get to advance beyond CSM. They all mean similar things, and they all cost a considerable bundle for the initial course. Afterward, you need to pay a fee each year (or every two years depending on the entity) to maintain your certifications. It doesn’t take rocket science to figure out that if you hold multiple certifications then you’ll be paying a LOT over the years to keep them current.

In the last two years, I’ve gained three certifications: A-CSM, CSPO, and CS@SP. I intend to go for a few more in the near future. Why would I do this, you ask? I do it to further my career, even if the courses haven’t taught me much more than my nearly 15 years of experience has. These certification courses have reminded me of some values and principles and have given me a new perspective on others, but they were not life-altering. I can say, though, that they did breathe new life into my resolve and my passion for Scrum and all things Agile. For those reasons, the certifications were worth it to me, but I was curious as to what others thought.

I asked folks within my network how many certifications they held and whether or not they felt the certifications were worth it. Most of them agreed that these certifications were indeed worth it, but some were hesitant to continue renewing them. Manny Segarra, Agile Coach at Kaiser Permanente, said, “This may be the last year I renew my certs … I have been an Agile Coach for 10+ years now … If I can’t convince someone in 5 minutes that I am the real deal, that is on me … Not sure I need someone else to validate me, aren’t we supposed to validate ourselves?!” Wendell Bickford, Sr. ScrumMaster at Integral Ad Science, had this to say, “I have CSM, CSP, CAL, SPC4. I think they are important but I believe being selective is worth it. But getting the certificate is one thing, but immersing yourself in an environment and practicing daily the Agile framework and scrum process is key.” Chris Wistrom, Sr. Scrum Master at Billtrust, said she thinks certifications feed her “psychological conditioning of ‘leveling up.'” She also feels that “learning is worth the effort” but “one doesn’t need the cert for the learning.” She has seven certifications.

So, where did I go for my most recent certifications? I took the A-CSM class in May of 2018 with Angela Johnson. I’d seen her speak at the Global Scrum Gathering in San Diego, and I’d joined a few of her webinars. I liked her no-nonsense approach to what it means to be a ScrumMaster, so I signed up. I wasn’t disappointed. In December of 2018 my boss told me he had leftover training budget so I jumped on the opportunity to get my CSPO. I loved the perspective this gave and I enjoyed the interaction in the class. Brad Swanson gave very organized training and encouraged very interesting discussion. It drew me to the conclusion that if you have only your CSM or your CSPO, you should get certified in the OTHER one. Six months later, I took the Scrum@Scale class with Rob Frohman & Melanie St. James from CO8 Group. I really wanted to learn how to scale scrum without doing SAFe. I’d say I learned more in this class than I did in the previous two combined, and I brought a lot back to my teams.

As with most things, becoming a Certified Scrum Master – or Certified Anything, for that matter – is a personal choice. Renewing those certifications year after year is also a choice. I’m fortunate enough to work for an employer that reimburses me for those fees, but not everyone has that luxury. Overall, I think getting and maintaining certifications helps my career and keeps me current. I love the learning that comes with these endeavors, but I can learn on my own, as well. Isn’t learning what this is all about anyway?

Back to Basics Series – Principle 1

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

https://agilemanifesto.org/principles.html

What Does It Mean?

There are many interpretations of this principle, but this one is mine. Honestly, I’m not looking to make any ground-breaking revelations here. I’m looking to break it down to get back to basics. It means what it means. In the software world, the path to customer satisfaction should be delivering early and often, but things are not always that black and white. Let’s take an expository approach in evaluating this, the first agile value.

Our highest priority is to satisfy the customer.

This principle says that we will satisfy the customer through early and continuous delivery of valuable software. However, I think there’s a reason why the group at Snowbird listed customer satisfaction first. Without customer satisfaction, we have no business. Bottom line. According to the great (or not-so-great) collective that is Wikipedia, customer satisfaction “is a measure of how products and services supplied by a company meet or surpass customer expectation.” Whether or not the software you and your team work on is customer-facing, ultimately everything we build has an end-user. If that end-user is not satisfied (that’s a whole other blog topic), then we need to go back to the drawing board to make sure s/he is. Customer satisfaction is why we do what we do, and their continued satisfaction keeps the lights on.

Early & Continuous Delivery

I actually dreaded writing this entry because I’m currently stuck in quarterly release hell. My present reality provides no fabulous insights or special instructions to get your company (or mine, for that matter) releasing early or often.

But what does it mean? At the risk of sounding like Captain Obvious, delivering software early and often is just that. A better question is why should we do it? The sooner we deliver working software to our customers, then the sooner we get feedback. We can then inspect and adapt that feedback to better form what’s in our hopper (roadmap, battle plan, whatever you want to call it). We do this to keep our customers happy, so they continue to pay us, so we continue to stay in business. Yes? Yes. If we do this in regular, short cycles, then we’ll hopefully align ourselves with ever-fluctuating market demands. This actually points back to the “customer satisfaction” part of this principle.

Valuable Software

The final part of this principle is valuable software. According to Merriam-Webster dictionary, the definition of valuable is having desirable or esteemed characteristics or qualities OR is of great use or service. Google “valuable software” and a myriad of articles pop up on what actually constitutes value. Quality is obviously a factor (but that’s also listed in a later Agile Principle; we’ll cover that), but ultimately, the team needs to determine what is valuable to the customer. That could mean anything from an intuitive user interface to speedy access to data. If the customer finds no value in what you’ve delivered, then what’s the point? This part, too, points back to the “customer satisfaction” part of this principle.

Customer Satisfaction is Key

To wrap it up, customer satisfaction is the key. Early and continuous delivery provides the feedback loop that keeps us informed, and delivering valuable software keeps our customers happy.