Recently, I’ve been seeing a
continuous flow of articles blaming Agility.
The relevance of the Agile word, its misuse and its role as a blanket
above approximate implementations is discussed. People also like making
themselves look important by announcing the failure of Agility and, by doing so, claiming themselves above the crowds.
Meanwhile, I’m often meeting people
at my job, within project teams or of course on the Net who say themselves
Agile because they are doing a stand-up, but who really have never been above
the Manifesto level.
The Agile Manifesto is no
bible
As its authors have said, the Agile
Manifesto is nothing but a snapshot…[2]
It is what a group of people has
identified as being the best practices to foster project success in the IT at a given point in time.
Nevertheless, for some, the AGILE
MANIFESTO has become the Agility’s bible. It
is carved in marble, 10 commandments’ style. It is written in capital
letter… A lot use it as a sword of truth and justify the least of their actions by
quoting it (often approximately). Most by the way only know the 4 values and
have forgotten about its 12 underlying principles. The crowds finally, “the
people”, believe that Agility is born in 2001.
No, we are no witness of Agility’s
failure. No the Agile word does not raise any issues. If there is a problem of
implementation, it is due to a careless reading of the Manifesto.
ScrumBut and AgileWashing have
already been denounced, but too often we blame these situations to a
non-literal respect of practices. Contrary to that, I believe that it is those
really practices and more precisely their portrayal in the AGILE MANIFESTO,
which, by taking away our freedom of
thought, prevents success in our projects.
Passing the Shu level
In Japanese martial arts, there is
the Shu-Ha-Ri concept.
 |
| Credits: Original design by N. Lochet |
I’m not the first to make the
comparison [3] between
those 3 stages in martial arts mastering and Agility but I find it very
appropriate. Today, whatever some may think, we largely stay at the Shu stage;
that is to say the learning of
fundamentals.
In the past, the Agile Manifesto has
been useful. By its simplicity and visibility, it was successful in attracting
attention. By its influence, it allowed a lot of people to consider new
approaches in project management.
Today, the
AGILE MANIFESTO is like the ball and chain of the convict as it is preventing
us to move at full speed. It established itself has a barrier, which hamper our
ability to access the above stage of the Ha (breaking with tradition) and
moreover the Ri (transcendence).
I’ll give you as a proof this only
example that you probably have witnessed yourself when a customer ask you the following:
- But
then, I cannot do documentation anymore?
Here, the Manifesto doesn’t help…
Most do not go behind the first part
of the proposition “working software” and think they are not allowed to do the
second part “comprehensive documentation”. In such times, I wish I could sweep
away the past (knowing that the situation is even worse in French due to the
ambiguous translation). Thus, not crystalizing reckoning around the Manifesto,
we could better move forward and finally progress towards the Ri.
Discarding the “command and
control” philosophy
I’ll say it differently. If the
Agile Manifesto has become a hindrance, it really is because it has been
deified. I’m not criticizing its content, but really this way of considering it
as a checklist that has to be done
without discussion…
 |
| Credits: Original design by N. Lochet |
As opium is fogging our senses, the
AGILE MANIFESTO is blinding us. Today, its omnipresence is such that as soon as
we touch it, people call to arms…
If we have come to that, it is
because we have to fight against the conditioning of 40 years of Waterfall-like
development. [4] It is
this “command and control” way to look
at projects, which conditioned us into accepting checklists as absolute
truths.
To succeed in our implementation of
Agility, we should stop to stupidly apply “administrative” behaviors induced by
our past practices. If they made sense before, in a “command and control”
approach, they no longer need to be in an “inspect and adapt” approach.
Agility behind the Manifesto
No, Agility cannot be reduced to the Manifesto. That would be whipping a dead horse
but we should nevertheless remind that Agility is not born in 2001. It is not
some kind of discovery that we would suddenly have done, but a history of
research in project management. An inheritance within which we could
selectively quote:
- The Mythical Man-Month (F. Brooks – 1975)
- No Silver Bullet – Essence and Accidents of Software Engineering (F. Brooks – 1986)
- The New New Product Development Game (H. Takeuchi, I Nonaka, Harvard Business Review – 1986)[5]
- Scrum introduction at OOPLSA in 1995
- Developing Products in Half the Time (P. G. Smith, D. G. Reinerstein – 1st Ed. 1995)
- The first use of XP in 1996 within the C3 project at Chrysler[6]
- This inheritance doesn’t stop in 2001, but is continuously growing with for instance:
- Kanban – Successful Evolutionary Change for your Technology Business (David Anderson – 2010)[7]
- The Lean Startup (how today’s entrepreneurs use continuous innovation to create radically successful businesses) (Eric Ries – 2011)
And so on and so forth…
The list is long and clearly shows
that a rich academic background
inspired Agility.
As for the word “Agile” itself,
which use we tie to the publication of the Manifesto, it can in fact be seen as
soon as in 1991 within a report ordered by the US government and called 21st Century Manufacturing
Enterprise Strategy.[8]
This report, published by the
Iacocca Institue, studies the difficulty of numerous American companies in
offering an industrial organization as flexible as the one from their Japanese
competitors.
There we find, applied to
manufacturing, a great many of the principles taken later into the Agile
Manifesto in IT. They are summed up there as early as within the introduction
of the report:
« The term « Agile Manufacturing »
describes a manufacturing system with extraordinary capability to meet the
rapidly changing needs of the marketplace, a system that can shift quickly
among product models or between product lines, ideally in real-time response to
customer demand. »
Being agnostic and thinking
by ourselves
Thus we should stop calling
ourselves from an AGILE MANIFESTO as we would be claiming ourselves from a
religion. We should learn to go behind,
to understand what are the foundations and goals of such or such practice. We
should consider the appropriateness of these practices within our context.
Rabelais in Pantagruel wrote, “Science
without conscience is but the ruin of the soul”. We should educate our conscience.
We can apply, we can adapt, but we do it consciously, with the knowledge of all
consequences.
- We should be lazy and only use the bare minimum of practices useful to us.
- We should iterate, not because it is one of the 12 principles of the Manifesto, but because we understand the benefit of reality checks.
- We should increment, not because it was asked of us, but because we understand we may not need everything, right now[9].
- We should communicate, not so that we stand by an Agile practice but because we value sharing information as soon as possible.
And above all, we mustn’t prevent ourselves from borrowing a specific technique or
tool from other fields or even to innovate because this isn’t in the AGILE
MANIFESTO.
Learning to be craftsmen of
continuous improvement
We shouldn’t be cooks who follow a recipe, but learn to be Master Chefs, able to mix sweet and salted, to
borrow to physics and chemistry to do molecular cuisine and thus reinventing
ourselves all along so that at last we can do continuous
improvement.
[1] Capital
letters are used on purpose, and I ask for your forgiveness, I have nothing
against the Agile Manifesto itself but against its display on a pedestal. I’m
thus opposing within this text the Agile Manifesto, which stands for the
genuine text, to the AGILE MANIFESTO, which is its deification.
[2] For more details, you should
look at Ron Jeffries article : Beyond Agile : New
Principles
[3] Personally, I have seen it first within Alistair Cockburn book Agile Software Development : The
Cooperative Game (you should read it, if you haven’t !)
[4] An all of this, because of a mistake since Winston Royce was already
denouncing the limits of the model within its very description in his 1970
article Managing the Development of Large
Software Systems
[5] Which inspired the Scrum framework and within which the Scrum
terminology is used for the first time
[6] Contrary to what we often see in France, Scrum really was presented
before XP.
[7] Following upon the Kanban systems implemented at Toyota as early as in
1953!
[8] The complete title of the report actually even is: 21st Century Manufacturing Enterprise Strategy An Industry Led View of
Agile Manufacturing
[9] We may never need it and by all means, in appliance of the
« Requirement Uncertainty Principle » of Watts S. Humphrey, we will
only be able to know after demonstration!
