Agile for PMs – Is the manifesto still relevant?
The “Agile for PMs” articles are written for experienced project managers who are interested in exploring how Agile development differs from classical project management.
In these articles, “Agile” is generally capitalised (and sometimes used as shorthand for “Agile development”).
It often seems like people fall back on “because it’s in the Agile Manifesto” as an argument. And it doesn’t feel a great answer. A bit too mystic maybe. A bunch of guys (yes, all men) in 2001 had a great party at the end of which they defined how software should be developed for all time. Does that work as an idea or is the Manifesto just an outdated fossil?
Software and software development has changed hugely since 2001. I’ve been involved in software development a long time and the technical discipline has evolved, management thinking has grown and ideas around planning and projects have also developed.
We’re not in 2001 any more
There are countless examples of radical change in how software is developed. Let’s consider some examples.
Remote work
In 2001, teams were physically located in an office. They were probably working on machines connected by a relatively slow link to a central server.
In 2024, an individual software team may be fully remote. They may be nearby or distributed globally, but beyond timezones their location is often unimportant. They have high-speed network links and sophisticated communication tools.
Cloud deployment
In 2001, software was deployed on a customer’s on-premise machines, generally with relatively infrequent releases. Release processes were heavyweight, taking days.
In 2024, software is likely to be deployed in the cloud. Individual changes can move from a developer to production in minutes. Effective CI/CD systems are standard good practice. DevSecOps is key to success and the first “DevOps Days” conference wasn’t until 2009.
Given these radical changes in how software is built, why do Agile leaders still go back to the Manifesto as a starting point? And why do I think it is still relevant today?
Outcomes and value
Today “outcome” is an widely used word, reminding us to focus on the benefits we achieve for the business over the creation of less useful items. Agile tends to use “value” in a similar context. The Agile Manifesto is a system of values and outcomes, not a map for how we get there.
Through this work we have come to value
Manifesto for Agile Software Development
Let’s remember that the Agile Manifesto is only 68 words long (about the same size as one verse of the US national anthem or at a rough guess 0.05% of the size of the PMBoK). It could not define how we should develop software, nor does it try.
There are many approaches, methodologies, frameworks (even certification) which promote Agile principles and suggest how we might deliver the Manifesto outcomes. And these approaches do change and evolve. For example, a discussion of the changes in the latest edition of Scrum can be found here.
Agile Values
The Agile Manifesto is defined in terms of Agile Values. Keeping things simple, there are only four of these. They are defined in pairs with the unusual (and misunderstood) structure below:
While there is value in the items on the right, we value the items on the left more
Manifesto for Agile Software Development
The Agile Manifesto is not saying “items on the right are bad”. I would go further and say it is stating “items on the right are important”. However, it suggests that the items on the left scale better. Once you have the items on the right in place (and only then), getting better suggests a focus on the items on the left.
For the Agile Manifesto to still perceived as relevant there must be a continued understanding that the “items on the right” are the places to focus to make a team stronger. Because the Manifesto is a value system, not an implementation guide, these are not highly dependent on how software is developed, and to a large degree are more about people and organisations.
Let’s quickly look at these four areas below and see if we still agree these are important in today’s software development. These are at the heart of what defines Agile development. Woiuld you agree that these are key areas to focus?
Individuals and interactions
Effective scaling of teams and organisations comes primarily from the culture and skills of the individuals and the way these individuals work together as self-managing teams.
Working software
Because complex environments see high levels of ongoing learning, we can progress best by experimentation, creating working software in small batches rather than trying to develop all the answers at the start.
Customer collaboration
Customer value is a priority for the business and we can deliver this best by working closely with the customer. This will maximise our understanding of customer needs and the customer’s understanding of the implementation and allow us to deliver an effective value stream.
Responding to change
Because complex environments see high levels of change, we should build in strategies to manage this. We should think carefully about what decisions we make and when these occur in the development.
Doing it and helping others do it
Although the Manifesto contains a statement of key values, I personally do not think that is the key. To me the most important statement is the much-overlooked first line:
We are uncovering better ways of developing software by doing it and helping others do it.
Manifesto for Agile Software Development
Agile development is about “doing it and helping others do it”. This is central to how I approach my own use of Agile and indeed this site. The Manifesto is not a “fossil”, because it sets the expectation of continued learning by doing. At no point is the manifesto presented as “final and complete”.
“Learning by doing” is the underlying approach. The implication is that we too, as readers, can “uncover better ways” by following the path of “doing it and helping others do it”. Support your teams in exploring and proposing the best ways.
Principles behind the Agile Manifesto
People may be unaware of the 12 Principles behind the Agile Manifesto which offer the next level of detail. These step back from outcomes to discuss the approach you need to achieve that result. Still at a very high level – principles not specific techniques.
The Principles have held up well over the years, but I think they allow a lot more discussion around the edges. You might argue that the selection is arbitrary and that others could have made the list. Some are perhaps beginning to show their age in the detail as for example the one below.
“Deliver working software frequently, from a couple of weeks to a couple of months”. “Frequently” is the principle. The example range of speeds may have worked in 2001, but it’s not intended to preclude deployment several times a day now that is possible.
Is there continued value in the Manifesto?
The Agile Manifesto gives a definition to Agile. Without it “Agile” would have no agreed meaning. Remember no-one “owns” Agile, so no-one can agree to evolve it. If the values cease to represent the needs of modern software development, it can and should be replaced with something new. Which would need a new name.
There is continuing discussion about what may be missing (should there be more explicit statements about Lean and Systems Thinking for example). However, until people see a definite mismatch between the Manifesto and the needs of software development, it forms a guiding set of values. Frameworks to implement those values will come, evolve and go.
The Agile Manifesto takes inspiration from many areas, some of which have also been around for a long time. “The New New Product Development Game” dates back to 1986. Lean Manufacturing dates back to the 1980s with roots in the 1950s. As the AgilePlays site emphasises, these all bring great ideas, but learning by “doing it and helping others do it” is the key.
Would I change anything in the Manifesto? We all have our personal beliefs, and like most people I would “improve” some areas. But as that’s not an option, I explain these instead.
- I would be more explicit with the value pairs. When we say “we value A over B” I would say “B is foundational, while A is more scalable”. Implement B then get great at A.
- I would replace the word “software” (which appears twice in the Manifesto and three times in the Principles). Agile has shown its applicability across complex environments involving knowledge work. And “software” has diversified and other fields (such as data science) become more “software like”.
- Above all, I would remind everyone that “doing it and helping others do it” is at the heart of the Manifesto and that Agile works best when explored by practitioners, not when seen as a rigid framework.
Leave a Reply