Agile, What Is It Good For
During 3 days of February 2001, 17 software development practitioners and enthusiasts who called themselves the Agile Alliance, and who observed the increasing need for an alternative to the existing Waterfall software development process, got together at The Lodge at Snowbird ski resort in Utah. We cannot guarantee that there was not heavy drinking involved, though we know that members of the initial alliance were experienced in software development and even more in the business entrepreneurship. So, they produced four principles that they called “Manifesto for Agile Software Development,” listed below:
As many later stated, the manifesto was clearly addressing for Agile Software Development issues, in contrast to until then a prevalent Waterfall Methodology, in the guise of statement “that is, while there is value in the items on the right, we value the items on the left more.” Very soon, the always eager American entrepreneurship jumped to the new business opportunity, and all break loose. Today we have over two hundred Agile certifications, all commercially competing for the chank of the Agile market. What was supposed to be a simple project methodology with couple of agile software development frameworks, it turned into a bizarre way of money making with all the hallmarks of a cult, a religion and dogma. The market is bombarded with new “agile” methodologies, tons of worthless books, disciples taking no value “how to become agile expert in a day” from a remote certification mills and waving their shiny new agile certifications, and "agile" evangelists.
What is even worse, the new fake “agile” mindset also saturated corporate environments, with every shallow CIO drooling for the “agile” magic to solve their disastrous enterprise strategy and time to markets. And very soon that kind of “agile” also got into the government ministries and clusters, with each agile “progressive” manager boasting to his boss that “we are doing agile.” Though people take that position because on paper, Agile looks brilliant, the Agile that was manifestoed in 2001, it has become a skewed version of what it is today, and that is this reality version of Agile. Just to add more salt to the misery, Jeff Sutherland (one of the creators of Scrum, a framework for product management) claims that Agile can achieve “Twice the Work in Half the Time”. One could be amazed how a lone social drinking in a remote lodge become a planetary disaster.
In the Harvard Business Review article “Have We Taken Agile Too Far?”, former Amazon executives, Colin Bryar and Bill Carr address how the “agile”, along with its close cousin “lean,” has spread far beyond its product development to areas as budgeting, talent management, marketing, and I say you name it. The authors state that how agile companies get ahead of themselves. This “getting ahead yourself” phenomenon becomes even worse when professionals get suck into the trend and join the cause. Very soon, every project in an enterprise “doing agile” gets infested with people who buy stacks of books on the “agile” subject, they love it, they suck it all up, they obsess over the minutiae of how to implement scrum, retrospectives, and sprints. As stated before, it becomes a religion, and as one famous man said ““religion is the opium of the people.”
I can say that I am exceptionally good Agile disciple, embracing Agile methodology back in 2005, and have been delivering tons of successful Agile projects. At the same time, I keep seeing “agile” projects and teams consistently failing to deliver, though those failures never count, I always read how Agile boost productivity more than any other methodology. “Agile” methodology fails dramatically, but nobody wants to admit the failure because that goes against the dogma. One way to get away with the failure is declare the basic Minimum Viable Product (MVP) as the measure of success. I doesn’t matter that the stakeholders making implementation decisions in ivory towers (instead of following the principle “Business people and developers must work together daily throughout the project”), developers being told to not implement some functions because it's out of scope (and it's out of scope because the design people forgot to design it, though everybody else pretends it's meant to be like that). And God forbid if you happen to point to it and call it failure, you may be out of the job thereafter. I have seen “agile” project teams pretending software works and everything is good in the la-la-land when in in reality it fails miserably, but no worry we are going to fix it in production since we work incrementally DevOps, or because everything looks nice and pretty in Jira dashboard. And I have never seen “self-organized” agile team that works together for years and have inherent constructive collaboration to work Agile. It is just bunch of cross-functional developers moving from project to project with no true commitment to “goals and objectives” to any, and crowds of "digital squad" consultants looking to deliver the minimum required work and move to another job opportunity.
I heard and read so many times from “agile” apologists how “Agile is better than Waterfall.” Well, it may be better for the niche discipline of the Software Development, which was the original premise of the Agile Manifesto, and following the agreed upon methodology principles. But let one of these Agile evangelists try building a bridge, a skyscraper or even his own bathroom in the “agile” fashion and see where that is going to get them. There are no cutting corners, no MVP or developing “just enough” design documentation when building a bridge, because it will collapse for sure.
Back in 2012, the US based analyst firm “Be aware that the Agile movement might very well just be either a developer rebellion against unwanted tasks and schedules or just an opportunity to sell Agile services including certificates and training,” high number of participants (40%) said, reporting no success with Agile.” From Voke's article “The Agile Dilemma” I learned that what matters in a real life is that there are good project managers and bad project managers, good designers and architects and bad ones, good developers and testers and bad ones. And in a stretch, good people, and bad people. I conclude, with compelling arguments, that after more than two decades after Agile Manifesto, Agile Methodology remains elusive.
