E

The Agile Manifesto revisited: part 1
A constructive critique
25416

The Agile Manifesto was written in February 2001, signed by a set of ‘Founding Fathers’ and effectively laid the foundation of a worldwide movement towards more agile software development. Its historical significance is not in doubt, it set things moving and was highly successful because of that.

We live in 2019 now. Agile has become widespread in software development, tools and processes support agile. What does the Agile Manifesto still mean, and can it be the basis for the current Agile Movement? I intend to examine that question in a number of blogs…

Individuals and interactions over processes and tools

You need to understand that The Agile Manifesto is shorthand for its real title: Manifesto for agile software development. It was written in 2001, when the state of the art of software development essentially was that a functional and technical analyst delivered detailed specifications and programmers just needed to write the code, ideally only based on the delivered document, so that it could later serve as documentation. In fact, in the early years 1990, the holy grail was CASE, Computer Aided Software Engineering. CASE-tools allowed modeling the requirements and generate code based on the model, and aimed at eliminating programmers, or at least coding, altogether. Failed badly.

The Agile Manifesto is a revolt against that idea. Programmers of the world, unite: we are creative people. Rightly so, of course.

That is what ‘individuals’ means: programmers are human.

Imagine the surprise among senior management when somebody first mentioned that the life-form they hired to program stuff was actually human – gasp – and interacted among themselves and even wanted to interact with business people – GASP – instead of just reading the documents and coding the stuff. I have lived those days: my first assignment was exactly that: write such a document and then have the programmer tactfully explain to me what was missing for him to translate it into code.

There is a reason that the processes and tools part is written smaller. The principle really says:

“There is more value in individuals and interactions than in processes and tools.”

Even though I respect where this comes from, this is woefully inadequate.

Compare it to the following statement and you will get the point:

“4. Organisation - Cultivate a strong sense of belonging and organise around accountable teams; avoid hierarchical control and bureaucracy.”

This statement comes from Beyond Budgeting, an agile like movement in management that pre-dates the Agile Manifesto (although, to be fair, the quoted text is the third version of the principle).

Individuals and interactions” is far too weak to describe the essence of what agile really means. Agility is not about interacting individuals. It is not even about ‘people and relations’, an improvement on the Agile Manifesto that I have read before. No, agility builds on self-organizing multi-functional teams, and hierarchical control and bureaucracy are indeed the main obstacles to realizing such ‘accountable’ teams.

Agility is not about individuals. The essence of a team is that it is not just the sum of the individuals in it. Some individuality needs to be set aside even in order to create a great team. The ‘interactions’ are not neutral, either. You need transparency, trust, vulnerability, openness, willingness to disagree, courage, commitment, sharing …

Beyond Budgeting adds one more: a sense of belonging. Beyond Budgeting has Scandinavian roots, where the desire to belong to a group can be more openly mentioned than is possible in a US environment that is more fiercely individualistic. An interesting cultural dimension worth thinking about.

And then: processes and tools.

Let us agree that we want good teams. What about processes and tools then. The only sensible thing I can think of about processes is that you would need to have processes that reinforce the team-work. The Beyond Budgeting statement: “avoid hierarchical control and bureaucracy” seems a pretty good starting point. I think you would like good and simple processes such as Scrum and DevOps, in order to help your teams. Same for tools really. If you have a team, you want them to have good tools. Period.

So, there we are. The first principle of agile should not be about individuals and interactions, but about self-organizing multi-functional teams. Processes can be quite valuable for agility if they actually help the teams to function better; the same goes for tools. There is no intrinsic value or lack of value in either.

People on the one hand, processes and tools on the other: it just makes no sense. Let us adopt the Beyond Budgetting one instead:

Cultivate a strong sense of belonging and organise around accountable teams; avoid hierarchical control and bureaucracy.


Read on for the second principle.

Sign in to leave a comment

E

Lean-agile Portfolio Management
Comparing prioritization in waterfall, agile and lean-agile