The Agile Manifesto Principles Revisited – Part 1

When I teach classes in agile, one of the topics we cover is the Agile Manifesto. The values drive how we do our work, but the principles in the manifesto provide guidance on how. Even experienced agilists sometimes forget the principles, so I thought it might be good to revisit them. This will be part one of a three-part series on the agile manifesto principles. So let’s jump in!

The Agile Manifesto Principles

Some people don’t even know that the agile manifesto has several principles associated with it. There’s a link below the values on the main website, but if you don’t know it’s there, you might miss it. The authors of the manifesto┬áprovided twelve total; today we’ll tackle the first four.

Principle #1

The first principle in the Agile Manifesto is:

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

When we talk about agile, we want to achieve a state of “done” that isn’t “done but not done-done”, but rather that our software is “release ready”. And in some newer methodologies, like CI/CD and DevOps, it may actually be released as soon as it’s checked into source control.

The intent of this principle is to get feedback from the customer as quickly as possible as to the solution we provided. Did we meet their immediate needs? Did we fail to deliver on something key? And where should we be focusing our attention next? By getting a product into our customer’s hands early, we may get some direct compensation, either financially or by extending a contract. And it helps us ensure that we’re building the right product for them.

Principle #2

eXtreme Programming Cover
eXtreme Programming Explained

The manifesto’s second principle is:

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

This was the subtitle of Kent Beck’s eXtreme Programming book. There are two linked concepts here. The first is that we need to recognize that we can’t have perfect foreknowledge. In an internal study at Standish Group, the researchers found that nearly 45% of their features were rarely or never used. That’s a lot of time, energy, and money being spent to build something no one needs or wants. Would you rather spend almost half of your budget building things no one needs or spend that half building the next thing that people do need?

It shouldn’t be a difficult business decision, but for some reason, we struggle to separate our “common sense” from empirical data. If we look at the real data, we find that delaying some of these decisions until later lets us build better products that better meet our customers’ needs.

Principle #3

PDCA Cycle
PDCA Cycle

The third principle is:

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

Many of the frameworks we use in agile, like eXtreme Programming or Scrum, build this in with timeboxing work. By focusing our efforts on short bursts of whole and complete work, we are able to meet the first principle of the manifesto. Lean tells us that we should complete work in small batches to improve productivity.

The second piece is the focus on the shorter timescale. As discussed in principle #1, we want to get feedback quickly. The shorter the cycle, the more adaptable we can be in development. It requires backlog items that support the shorter timescale, but the right backlog can help a team be incredibly successful. The danger of a longer timescale is that we may not know until we’ve spent a lot of time and money whether what we’ve built meets our customer’s needs. Shorter cycles are better.

Principle #4

And the last principle we’ll be discussing this week is:

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

This is sometimes the hardest thing for many organizations to adopt. Many, many people believe that agile adoption is just the IT team. I wrote about this previously, but the changes are deeper than many people expect and result in disconnects between IT and the rest of the company.

The key element here is that the business is responsible for the relationship with the customer. They understand the customer needs and the delivery team needs the business people to guide their efforts. It’s important that the team work on the items that provide the maximum value to the customer. Only the business can determine what that is. And continued, constant guidance is what’s needed. In short, the business needs to work with the delivery team daily.

Closing Thoughts

The manifesto is the starting point for all agile transformations. Whether that transformation is small-scale, say the team level, or at the enterprise level with hundreds or thousands of people, the manifesto guides our efforts. The values tell us how we should look at our approach to transformations. The principles give us some specific guidelines on how to implement. Regardless of your process, the manifesto guides our efforts to not just do agile but to be agile. And that is a better place for all of us.

Feliz entrenamiento, mis amigos! (Happy coaching, my friends!)

Have questions?

Bill DeVoe