Preface. I thought I could cover my ideas in a single post. That is not the case. Instead, I will post multiple articles about this topic so I can see the topic to its conclusion.
Time to adapt. The Agile Manifesto is an outdated relic. Agile practitioners must systematically overhaul it. As written, the manifesto constrains whole organizations from becoming truly agile.
The above paragraph is a radical proclamation sure to ruffle the feathers of many Agile purists. I did not arrive at that conclusion lightly. Years of studying and practicing Agile lead me to that conclusion.
But first, some context. In 2001, a group of software engineers gathered to talk about better ways to produce software. They recognized that the old ways of managing projects were suited to manufacturing and building physical things. Software is not a physical object. Software is a type of product that is amorphous and devoid of any real physical meaning. People do not really know what they want, regarding software, until they see it. That group of software engineers knew this, and so they created the Agile Manifesto as a way to work with ambiguity to build software products while people figure out what they want and do not want.
The Agile Manifesto is a document written entirely from the perspective of software development. This makes sense since the people who wrote it were software engineers. Those same engineers simply wanted a better approach to making software. They had a specific problem to solve and they gathered with a singular purpose.
Since 2001, Agile has exploded across the information technology (IT) landscape. Thousands of people and teams embraced agile concepts. Agile practitioners unleashed tremendous organizational change. Consultants turned entire companies on their heads through agile transformations, all so that IT teams could improve their overall performances.
The next agile wave. For an organization to become truly agile, agile transformations must not be constrained to IT alone. The entire organization must learn to become agile. I assume most agile practitioners agree with me on that point.
Organizational leaders recognize that to survive, their organizations must quickly adapt. Organizational leaders need to be adept at reading changing market conditions, anticipating customer needs, and developing disruptive products and services. IT will likely play a vital role in organizational adaptation, but IT is not the only player within an organization. All organizational teams need to be highly adaptive to industry change. To become highly adaptive means that organizations must embrace change.
There is one giant wall standing in the way of systematic organizational change—the Agile Manifesto. That simple document focuses on software development. Agile coaches around the world struggle to reinterpret the manifesto into business speak to win non-IT teams and leaders. It is straightforward to transform the four values of the manifesto, but that is only part of the problem. I believe the four values need to change as well, but more on that later. The main problem lies in the twelve principles.
The twelve principles. The twelve principles are titled the Twelve Principles of Agile Software. The principles do not discuss how to do other types of work such as marketing, sales, research and development, management, or law. They are specific to how an IT team, specifically a software development team, should behave.
Many agile practitioners gloss over the principles when working with non-IT teams. I have. I do. Why? Because the twelve principles are meaningless to people who do not build software.
What is a principle? Agile practitioners often fail at explaining the twelve principles. Many people attempt to explain them as fundamental truths that exist whether someone believes in them or not. While that is certainly a definition of the word principle, it is not the right definition for that word in the context of the twelve principles in the manifesto. The appropriate definition to use comes to us from Google.com that states “a rule or belief governing one’s personal behavior.”
If you do not like Google’s definition then Merriam-Webster offers a slightly different definition: “a rule or code of conduct.”
Consider the second principle of agile software.
“Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.”
It is a great principle. However, the problem is that it is not a fundamental truth. I can choose not to welcome changing requirements. Many agile teams do not simply welcome changing requirements as the manifesto implies. Most agile teams, at best, control changing requirements. In other words, this principle does not exist in its purest form on agile teams. The principle is not a fundamental truth; rather, it is a rule that guides behavior. The principle tells people, “Hey, don’t worry about new requirements. Accept that change happens, welcome the change, and figure out what to do about it by talking to people.”
Another example is the last principle.
“At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.”
Again, this is great practice, but it is not a fundamental truth existing outside of team members. The principle tells us how we should behave as a team. It describes what we should do as a team to improve.
There is one other problem with the twelve principles—they are too wordy. Principles should be pithy. Pithiness enhances a principle’s effectiveness and helps make them stick. They should be pithy so people remember them. If people remember them, then they can easily put them into practice. Consider some simple, yet effective, guiding principles:
Cleanliness is next to godliness. Do no harm. Adapt and overcome. Strength before dishonor. The customer is always right.
When a principle is simple and easy to understand people remember them. A simple principle guides behavior. When a person gets stuck and does not know what action to take, that person can reflect on their principles to guide how they should respond.
That is why we often call any principle worth their salt guiding principles. They guide our behavior and prepare us to take the right action when we feel lost. The twelve principles in the manifesto guide behavior, but only behavior for those who develop software. The manifesto, as written, abandons other types of teams that do not develop software.
If Agile practitioners are to influence organizational change and encourage all levels of an organization to embrace Agile, then a new manifesto is needed. One that applies to the entire organization while promoting the underlying ideas of the original Agile manifesto.
Next steps. What I’ve written here is not new. For the past few years, some agile practitioners wrote about their frustrations with Agile. Agile needs to take a page from its own manifesto and evolve. However, it is not my intention to pour fuel on a small fire and simply complain. I will share some additional thoughts on where I’d like to see things go from here in an upcoming post