I entered my previous post on the subject when I had just begun Taleb’s book Antifragile. As I continue my reading I have run into some very specific passages which lead me to theorize that the reason Agile development works so well is that it is a living, breathing example of what Taleb would call “Antifragile.” I am also coming to the conclusion that Taleb is a truly great contemporary thinker. As I examine my own career, I plan to take to heart many of his suggestions on creating one that is Antifragile.
While I am no in any way paid to sell this book, I encourage all Agile folks to highly consider adding this to their reading list.
There are some particular passages in the book that I believe are spot on in relation to Agile development and inform the reasons behind success shown in proper Agile implementations.
I think that the following passage, for example, accurately depicts many of the waterfall development projects that I have personally witnessed or have heard of:
When constrained systems, those hungry for natural disorder, collapse, as they are eventually bound to, since they are fragile, failure is never seen as the result of fragility. Rather, such failure is interpreted as the product of poor forecasting. As with a crumbling sand pile, it would be unintelligent to attribute the collapse of a fragile bridge to the last truck that crossed it, and even more foolish to try to predict in advance which truck might bring it down. Yet it is done all too often.
Taleb, Nassim Nicholas (2012-11-27). Antifragile: Things That Gain from Disorder (p. 131). Random House, Inc.. Kindle Edition.
And, historically, as a result, project management and software development has reacted with waterfall development in the naive attempt to “predict” failure and mitigate it through big upfront design, as if, after a failure or string of failures, to say that, “If only we had spent more time on design and requirements then we would have known and anticipated all and thus would have avoided failure.” This type on Monday morning quarterbacking in dangerous not only because it incorrectly assumes that all is knowable beforehand, but also because any knowledge gained is so far downstream that this knowledge (which Taleb acknowledges is, in itself, Antifragile) in either un-actionable due to crystalline architecture or unfeasible economically.
True Agile processes like short iterations, test driven design, rapid prototyping, retrospectives, etc are all things that increase software Antifragility, mainly because they acknowledge the fact that failure is eminent and the sooner we get that out of the way the sooner we can build in increased resistance to catastrophic failure. In other words, Agile is honest in its alignment with reality as opposed to the “emperor has no clothes”, bury our heads in the sand and play high stakes chicken with our peers to see who will be the idiot to be first to acknowledge the 800 pound guerrilla in the room that is project wide failure.
While agile shines the harsh spotlight on failure in order to build a stronger overall (antifragile) system, project “management” through waterfall processes tries its best to hide its defects in a dark corner in hopes that they will either never be found, ones colleague’s defects will be more hideous when exposed or that one can structure their part of a project in such a way that when the nearly inevitable failure occurs (remember that Chaos Report shows the majority of Waterfall project will fail) they can hide behind layers of bureaucracy so that the finger can’t be pointed at them.
One other passage that I found of note states:
The error of thinking you know exactly where you are going and assuming that you know today what your preferences will be tomorrow has an associated one. It is the illusion of thinking that others, too, know where they are going, and that they would tell you what they want if you just asked them. Never ask people what they want, or where they want to go, or where they think they should go, or, worse, what they think they will desire tomorrow. The strength of the computer entrepreneur Steve Jobs was precisely in distrusting market research and focus groups— those based on asking people what they want— and following his own imagination. His modus was that people don’t know what they want until you provide them with it.
Taleb, Nassim Nicholas (2012-11-27). Antifragile: Things That Gain from Disorder (pp. 170-172). Random House, Inc.. Kindle Edition.
As a tech-heavy blog I had to include an obligatory nod to Steve Jobs (though I might quibble some with his place as a technical visionary. He knew a good idea when he saw one or appropriated one), but if you had made it this far into this particular entry I am certain that you can draw the parallel between Taleb’s truism and the Agile Scrum practice of code review with stakeholders. Yes, customers very often do not know what they want until they see it so I am always amazed at the “fragility” of a software development methodology or framework that does not insist, as the (Antifragile) Agile principles do, on “early and continuous delivery”, “welcome changing requirements”, “business people and developers must work together”, etc.
As I move forward with my Agile implementations I plan to give a well-deserved “No!” to Taleb and his revolutionary concept of Antifragility.