agile manifesto

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.

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.

Back to Basics – Overview

About a year ago, Atlassian took to Twitter with their #RetroOnAgile campaign and asked followers to tweet something they liked and something they wished about agile. Under my @MomofXandM handle, I tweeted the following responses: “#ILike the Agile principles and values. #RetroOnAgile” and “#IWish more folks followed the Agile principles and values rather than trying to hammer away on process and methodology. #RetroOnAgile”

I still like the agile principles and values, and I still wish more folks would stick to the basics outlined in them. Instead, command-and-control runs rampant in Corporate America, and now more than ever we all seem beholden to process and methodology.

What should we do about this? As ScrumMasters it’s our job to coach our team to better practices, so I think a return to the basics might be well-warranted. I am therefore setting out to do a series of posts focusing on agile principles and values, so that I can re-center myself and my teams on the simplicity that matters. Let’s start with an overview.

Many know the story behind the Agile Manifesto. 17 developers met at a ski lodge in Utah to discuss the way software development seemed to be going at that time. They weren’t happy with the hyper focus on processes, tools, reems of documentation, and constant contract negotiation, so they penned the manifesto.

We are uncovering better ways of developing software by doing it and helping others do it.  Through this work we have come to value:


Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan


That is, while there is value in the items on the right, we value the items on the left more.


https://agilemanifesto.org/

There were 12 principles behind the manifesto. These coupled with the manifesto birthed the Agile movement. There were plenty of forerunners, but these are the principles the Agile community points back to regularly. Some even treat these words like gospel.

  1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
  2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
  3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
  4. Business people and developers must work together daily throughout the project.
  5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
  6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
  7. Working software is the primary measure of progress.
  8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
  9. Continuous attention to technical excellence and good design enhances agility.
  10. Simplicity–the art of maximizing the amount of work not done–is essential.
  11. The best architectures, requirements, and designs emerge from self-organizing teams.
  12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

In the coming weeks, I’ll explore each principle and value in more depth. I welcome feedback and conversation, and it’s my hope that you take these discussions back to your teams.