The Agile Manifesto is a historical artifact written in 2001, in response the how we deliver software and knowledge work. Which focused on values and principles.

---

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

The focus now needs to be on realising 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 that the Agile Manifesto was written during a very different time. Agile was the community’s response to better ways of working. During a time 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 the 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 products over comprehensive documentation

‘Products‘ not just software but this is still true. Software is only part of the picture.

Customer collaboration over contract negotiation

In knowledge work, we often don’t know everything at the start and Agile recognises this. We need to be co-create, collaborate and partner up with our ‘clients‘ or ‘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.

---

12 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 value.

We must now focus on everything needed to realize ‘value‘ by the customer. Not just software but anything valuable to customer’s or clients.

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 teams must work together daily throughout the project.

We need more than just ‘developers’ to all involved to deliver true value. This would include product management, operations, marketing, creative, video production, content specialists, legal, 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 teams 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 Valuable products is the primary measure of progress.

While true ‘valuable products’ to achieve an outcome should be the goal. This needs to be about ‘value’ not just ‘software’. But there are different levels of progress.

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

Maintain a sustainable pace there is more to life than just work.

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 misinterpreted. What we are going after is ‘elegance’ – satisfying the need with the right amount of effort. Going for ‘simplicity’ often leads to simplistic and simplicity is relative… simplicity relative to what?

‘Work not done’ should also explicit include ‘work not attempted to be done’ – meaning don’t give teams items of lesser value. I like to think about doing as little as possible to get the biggest impact.

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

When you empower people to solve the right problems you will have better alignment. At the team level 100%, this may require the organisation to create and cultivate the right environment to optimise this.

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

Kaizen (Continuous improvement) – Stop, pause, reflect and, repeat!

My thoughts

The Agile Manifesto is arguably the most important document in the history of software development and I don’t want to bastardise it. Bringing the Agile Manifesto into the context of modern-day business requires some minor adjustments to make it more useful.