The Agile Manifesto was written in 2001, when the focus of Agile was on the team. The intentions of the Manifesto are timeless. With FLEX’s focus is on business agility, however, it is worth looking at the Manifesto within this new context. This article clarifies how to interpret the Manifesto in the context of the full value. There is no implication that the Manifesto is less than it should have been.  However, since many people are still using it as a guide, discussing it in the context of business agility is useful.

The world we have created is a product of our thinking; it cannot be changed without changing our thinking.  ~Albert Einstein

We cannot solve our problems with the same thinking we used when we created them. – Albert Einstein

Our insights of today become our dogma of tomorrow – Al Shalloway

We elaborate on the Manifesto in the following form:

A statement from the Agile Manifesto

Our comments on the Manifesto

---

We are uncovering better ways of developing software by doing it and helping others do it. 

The focus now needs to be on realizing value for our customers. Software is only one aspect of that.

Through this work we have come to value:

Individuals and interactions over processes and tools

It is important to remember they wrote the Manifesto during a time when management imposed processes on people and Lean-Thinking was mostly unknown in the Agile space. The intent of this statement is valid within that context. Lean introduces a different perspective on process – that of explicit workflow created by the team to support the team. In this context, process, or ‘workflow’ as it’s often called in Lean is very important and has a multiplicative effect on people’s effectiveness.

Working software over comprehensive documentation

This is still true. But it’s only part of the story now since we’re focusing on more than software.

Customer collaboration over contract negotiation

Agile recognizes that we don’t know everything at the start. We need to be partners with our customers and work together to determine what they really need.

Responding to change over following a plan

Agility means to do the right thing at the right time in the right way. As our understanding improves, we must adjust accordingly.

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

Principles behind the Agile Manifesto

We follow these principles:

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

We must now focus on everything needed to realize value by the customer. This likely includes more than just software.

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

While requirements do often change, much of the time it is our understanding of what’s needed is changing. Discovering these early is good, but we should expect to discover them continuously.

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

The Manifesto was created when theories of flow, Lean and Kanban were little understood. A method of delivering continuously was unknown.

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

One must expand ‘developers’ to all involved now in business agility. This would include product management, Ops, marketing, documentation for customers, etc.

5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

This is timeless.

6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

This is certainly true. But it ignores the reality of today where the roles involved have expanded beyond the development team and that even the teams are often distributed. So, while true, it does not address the needs of how to communicate in the present distributed environment.

7. Working software is the primary measure of progress.

While true when our focus was on the team, this needs to shift ‘working software’ to ‘value realized’. But there are different levels of progress. This statement best understood when stated as:

1. Value realized is the primary measure of progress.

2. Working software is the primary measure of a team’s progress  

8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

This is timeless.

9. Continuous attention to technical excellence and good design enhances agility.

This is perhaps more important today than in 2001 when the team focus kept this in front of people.

10. Simplicity–the art of maximizing the amount of work not done–is essential.

The intent of this statement is correct. But it is often mis-interpreted. What we are going after is ‘elegance’ – satisfying the need with the right amount of effort. Going for ‘simplicity’ often leads to simplistic. Not to mention that what is simple for one person may not be simple for another. ‘Work not done’ should also explicit include ‘work not attempted to be done’ – meaning don’t give teams items of lesser value.

11. The best architectures, requirements, and designs emerge from self-organizing teams.

While true at the team level, at the organization level it often requires people beyond the team to create the right environment to encourage flow. But within that context, this is right on.

12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

This is timeless.

In Summation

The Agile Manifesto is arguably the most important document in the history of software development. Virtually each of its statements provide important insights and guidance. However, software development changes at a rate beyond any other endeavor. Bringing the Agile Manifesto into the context of business agility makes it even more useful.