The Evolution of The Agile Manifesto, Part 1
Updated: Dec 22, 2021
As everyone knows, the original text of the Agile Manifesto was written in 2001. Many years have passed since then: the business environment, methods, and the way we work have substantially changed. What seemed revolutionary 20 years ago now looks commonplace or even a hygiene development factor.
A working product? Come on, how is it possible to develop something that does not work properly? Who will buy it? People and interactions? Every second team member is an agile coach or facilitator. We discuss all the improvements during retrospectives. We are ready for changes even in the middle of an iteration under certain conditions (see, for example, the Scrum framework).
Most of you know or think you know what Agile is. Many have already tried to implement the principles of agile software development. Today, I will not go into detail on all 12 principles (this has already been successfully done by many great specialists). I will limit myself to only 4 values. I will try to analyze how holistic the Agile value model is, how it has transformed, and why it’s often difficult to implement in an organization.
The Agile Concept
Agile Manifesto: The Course Сode
Let's start with the basics and cite the original source of the Manifesto for Agile Software Development.
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools.
Working software over comprehensive documentation.
Customer collaboration over contract negotiation.
Responding to change over following a plan.
That is, while there is value in the items on the right, we value the items on the left more.
These 4 statements are commonly referred to as Agile values. Combined with the 12 principles published on the Manifesto's website, they form a specific mindset required for successful software development. Many insist that there is a whole new culture or even a philosophy of doing modern business hidden behind this concept. But, as I said earlier, for now, we will limit ourselves to only these four values.
For our further analysis, it is worth paying attention to the word OVER. It is vital to mention that the items on the left do not cancel the items on the right. The interactions between people are impossible without processes and tools and won't allow the business to develop a working product.
Agile Manifesto 2.1
More interesting from the analytical point of view is the so-called Agile Manifesto 2.1. The original text is not available anymore, but the Internet remembers everything. Although this version wasn't signed as the original one it was vividly discussed in the IT community and, in general, seems to me, was received positively. Here is his text:
Teamwork and responsibility over individuals and interaction.
Business value over working software.
Partnership elaboration over customer collaboration.
Prepare for change over responding to change.
As in the case of the original text, the left item does not cancel the right one but emphasizes new values, establishing the shifts in the mindset required for successful software development at the time when this version of the Manifesto was written (2011).
In addition to this version, there have been other very similar attempts to rethink the values of Agile: MoreAgile Manifesto in Xebia, Reworking the Agile Manifesto in IBM. Subsequently, the word "OVER" was replaced by the ">" sign. The final wording can be read as follows.
Teamwork and responsibility > Individuals and interactions > Processes and tools
Business value > Working software > Comprehensive documentation
Partnership elaboration > Customer collaboration > Contract negotiation
Prepare for change > Responding to change > Following a plan
What viral changes can be noted here? At the beginning of the century, it was relevant to abandon the old mechanistic management paradigm, giving the humanistic management approach the top priority.
Then after a dozen years, it has already become clear that it is impossible to release complex products requiring joint efforts only by individuals, no matter how good they are. We require well-coordinated teams that can take responsibility not only for the end result but also for the organization of interaction, processes, and management principles.
The first manifesto stated that software should be released regularly and as often as possible. There was a very long development cycle, which could include several stages of verification and approvement, as well as the release of raw versions (alpha, beta, etc.). Now, something else is important: instead of delivering a working but often useless product, it is necessary to focus on delivering business value, successfully solving specific problems, and meeting the needs both of users and business.
Speaking of the cooperation with the customer — the parties were “fighting” trying to prescribe the most beneficial conditions for themselves in the contract. And after the project was delivered, they were looking for condition violations to blame the other party and win some more benefits. The new wording brings these relations to a new level of mutually beneficial partnership and implies the very same “win-win” situation.
And the last point, perhaps the most important one, as it reflects the very essence of the approach. It was believed that the product would no longer be relevant due to changes in the market by the end of the development. Therefore, the concept of flexibility and responsiveness to changes was proclaimed, which was called "Agile".
So, in conditions of uncertainty dictated by external circumstances, we do not blindly follow the plan, but adaptively react to changes in it. However, this approach is still reactive and barely useful: in case of sharp turns, after making a strategic decision about crucial changes, we discard either the technical implementation of the product, or part of its functionality, and possibly the product concept itself. And after that, we begin to improve the outcomes of unjustified hypotheses, which affect costs. Therefore, the preparation for changes postulates the emergence of a new proactive approach. It requires both moral and technological readiness for changes. The tech readiness might be assured by implementing new approaches in software engineering: Microservices, DevOps, Cloud computing, low-code / no-code platforms. It will be a basis for new flexible software architecture.
Why doesn’t Agile always work?
Why do we talk so much about Agile? Numerous reports and studies show that Agile is already being successfully used. And not only in the IT industry. Companies that didn't try it yet are looking towards transforming into agile organizations by embedding adaptability in the foundation of their corporate culture. However, businesses often forget that Agile is a way of thinking, a mindset of the entire organization, not just a methodology (which it is not) or an innovative project of the IT department. An organization does not become “agile” simply by changing its structure, introducing new roles, installing “Agile software,” or practicing certain techniques. It is not enough to simply apply certain practices, tools, or rituals and think that you are Agile. It is a long-term process of building culture at all levels.
The organizational culture is among the top answers to the question "What are the most significant barriers to adopting Agile in your organization?" in the annual State of Agile Report.
Why does it happen? Trying to implement Agile, many companies overlook the values and principles of the Manifesto. Instead of thinking flexibly, they implement practices according to specific guidelines and build processes to perform in a strictly defined way. It doesn't work that way! It's not enough to install Jira. It is not enough to rename the Project Manager to Scrum Master.
Companies that focus only on practices and rituals have difficulties in working in an Agile way. Companies that are committed to adhering to the values and principles of Agile, notice that the new way of working, processes, tools, and rituals adapt flexibly to the needs of the organization. It is all influenced by the newly formed mindset.
This effect is well described by Wilfried Kruger's iceberg model. Usually, we pay attention only to a small visible part of a general problem or phenomenon, while the most significant part remains out of sight, which determines the result of changes.
We can build a similar iceberg model for Agile that will describe the internal evolution of the concept. On the very top, we usually see stickers, boards, daily meetings, retrospectives, burndown charts, planning poker cards, etc. All these fancy artifacts on top of the iceberg do not help if companies use them for copying someone else's activities. This phenomenon is called "Cargo cult". This is what we usually call "to do Agile".
On the other hand, there is an invisible force that is hidden underwater and has stronger influence over the entire organization. It is a mindset based on the values and principles of the Agile Manifesto. And it determines what practices, processes, tools, rituals, and artifacts will be useful for this organization. To "be Agile" the whole organization and the people within it have to have an Agile mindset. A bold implementation of specific processes won't work as they should and can be valued only as a homage to fashion.
To be continued
In the first part of my research, I decided not to conclude but only to outline the evolution of the Agile Manifesto. In the following articles on the Manifesto transformation, we will look at it through the concept of the integral theory. To be continued...