Some people have difficulty living up to the values and principles of the Agile Manifesto. Should we improve the Manifesto? Raise your game: we meant what we said.
Successful large enterprises (and less successful or smaller ones) often have practices and policies which make it difficult or impossible to follow Agile values and principles. For example, they may choose to outsource software development to low-cost inexperienced high-turnover developers on other continents or other planets. They may wish to compensate for this by providing software templates for these people to follow and learn from.
It's a good idea ...
Now on the one hand, if one is stuck with inexperienced developers on Mars, providing them with strict guidelines could be part of a valid approach, and providing those guidelines in the form of running tested software would surely be a good way to communicate.
And it's not so very Agile ...
On the other hand, there’s a good chance that this approach actually pushes against the notions behind Agility. The basic practice of extraterrestrial software development might seem counter to the Agile principles that “business people and developers must work together daily”. Providing direction in the form of software templates might seem counter to the notion that “most efficient and effective method of conveying information to and within a development team is face-to-face conversation”.
It’s true, of course, that an organization could value those principles, and the others that this practice seems opposed to, and still find value in providing these templates. Certainly if I want to show people something about programming, I often show them examples. The template idea may not be any different.
But the question comes: should we update the Manifesto so as to open the door wider to ideas such as this one, and to the many other ideas that people have about how to do something like Agile within their “real world” organizations?
My answer is: No. We should not broaden the Manifesto in this kind of way. Here’s why:
The Manifesto is an Historical Document
Seventeen individuals who shared some common ideas got together for a few days, and wrote down the values and principles they shared. It was a moment in time, documenting what those seventeen people believed. It doesn’t make sense to rewrite history.
The Manifesto is a Manifesto
We wrote a manifesto: a public declaration of our opinions, objectives, and motives. We did not write a constitution for an organization or a set of laws for a group to follow. A manifesto is not subject to updates in the way that a constitution or body of laws might be.
The Manifesto is Definitional
As Tim Ottinger put it on the XP list, the manifesto is definitional: it defines our meaning of the term “Agile” at that moment in time. We might revise it if we discovered that it didn’t express what we thought. If it does express what we thought, we cannot revise it.
The Manifesto is Already Too Broad
As I look back on the fifteen years I’ve been doing this, and the decade since the Manifesto, I see more and more people wanting to fly the Agile banner without living the Agile values and principles. On my most charitable day, I might feel that they are trying to become more Agile. On my least charitable day, it’s hard to see that, because the sum of their actions seems so blatantly counter to what we teach.
One cause of this, in my view, is that the values and principles are perforce a bit vague. In the values, we value both sides: the question is how much. In the principles, we value things like face to face communication: the question is how much.
Sources of Trouble in Applying Agile
Going too far?
In principle, it is probably possible to follow any Agile value or principle too far.
We might favor individuals and interactions over processes and tools so much that we wrote all of our code in binary. That would usually be inappropriate.
We might favor face to face conversation so much that we never wrote anything down. That would usually be inappropriate.
In principle, therefore, an organization might apply too much Agile. However, there are checks and balances in there, such as the requirement to “deliver working software frequently”, and “to satisfy the customer”, and to “reflect on how to become more productive”. A team that did those things is not likely to code in binary for very long.
Not going far enough
In practice, I have never seen or heard of a team that truly followed the Agile values and principles too far. I do know of teams who adopted a kind of faux-Agile and adhered to their flawed definition in the face of delivering no software, and making no customer happy. That’s not too much Agile, that’s too little.
On the other side of the balance, I have seen many teams who get very little advantage from Agile, because they are doing very little of it. These teams find ways to weasel within the principles. A common variant is “We value face to face conversations highly, we really do. But the reality is that our developers are on Mars.”
Well, guess what. If your developers are on Mars, and you can’t be with them, you’re not going to get the benefits of doing Agile – because you are bloody not doing Agile very well!
Sorry. Changing the definition of Agile will not make Mars-based development work any better. The Agile values and principles are just fine. They state an ideal, and they state it pretty darn well when you consider the fools who wrote them.
Probably you’re not living up to the ideal. I often fall short of my ideals as well, in Agile, and in life. That doesn’t mean I should set lower ideals. It means I should raise my game.
Raise your game, successful large enterprise. We meant what we said.