The dictionary defines hoodwink as:
1. to deceive by false appearance, to fool someone
2. Someone who is deceived fooled or duped by another
Agile advocates have hoodwinked and deceived us for over 2 decades! The square peg of Agile methods does not fit into the round hole of Software Engineering. Moreover, Agile has been the rage for over 20 years. It started in 2001, when a group of Yahoos met at The Lodge at Solitude Ski Resort, in Utah. The purpose of this meeting: to find common ground - and revenue - among a group of like-minded practitioners. The Agile Alliance asserted a need for an alternative to the prevailing management methods for software engineering projects. They decried the heavyweight software development method (Waterfall Methodology), They criticized Waterfall as too heavy-weight and inflexible. Their work product, "Agile", caught on like gangbusters, but didn't we install “a new boss, the same as the old boss?” The result: a different approach with all of the same challenges that we had before. Worse yet, we created new challenges that we did not have in the first place.
Here's the key problem. Software ages. software becomes obsolete. Specific technologies fail to keep up with modern languages, tools, and techniques. The academic literature on software obsolescence is extensive. All software must be rewritten, roughly every 5 years. How can a team of engineers achieve the needed rewrite absent a comprehensive test suite? Keep in mind that the test suite requires a rewrite, in whole or in part, in the same timeframe With no comprehensive documentation of the system and its features, how will the team members determine how the software must function? Reverse-engineering a test suite is prohibitively time-consuming.
We observe the focus on NBUA (No Big Upfront Anything) as a fatal fallacy in Agile Methods. Slowly, but surely, an anti-Agile community is emerging from the ashes of myriad failed Agile projects. Anti-Agilists are posting on various boards and communities. Anti-Agilists exclaim their frustration with agile methods. We are living in the wake of much carnage in the software engineering profession. Anti-Agilists bemoan the failure of smart people to behave as rational engineers, in the wake of this carnage.
Executives experience consternation: why is software so expensive to build and manage? In response, Agilists sell Agile Transformation projects and products like hotcakes. The pitch: "Agile increases productivity and lowers the costs of Software Engineering." Unfortunately, the cost of an Agile Transformation is never communicated to these executives. Panic ensues. The knee-jerk reaction: blame the software engineers and their first-line managers. Layoffs ensue, but this is a fool's paradise. No one wants to believe that they've purchased nothing more than snake oil!
Some advocate, "We'd be better off implementing eXtreme Go Horse (XGH)" "My God!" you say, "What is XGH? How do I get it?" Do not stress yourself. XGH is a completely fictitious methodology that originates from Brazilian Software Engineering Communities. Rumor has it that some marquee corporations adopted XGH within some of their teams. This pinpoints the level of insanity that is at work amongst agile adopters.
Let's jump off the crazy train
Why is it that Agile methods have persisted for over 2 decades? Consider that prior methodologies aged out in similar timeframes. The evolution of Software engineering methods is innovation. Innovations generally leapfrog what has come before. I daresay that Agile has brought with it some significant innovations. I chalk it up to "necessity as the mother of invention." Agile seems immune to leapfrogging. Software engineers are complacent as a rule. Thus the software engineering community is complacent relative to Agile methods.
Okay, but be mindful that Agile results in at least as much failure as other methods. Can't we envision something better?
Agile, especially SCRUM, and Kanban methods result in "The Blind leading the Blind". Yet Agilists have persuaded executives that all is well.
The Agile Deception
SCRUM and KANBAN are not effective, except in very targeted environments. The sweet spot is Startups with little or no legacy code. These methods do not work well in companies that have grown beyond the SMB threshold. As a company grows, the software owned by the Company tends to out-grow juvenile approaches to Software Engineering. So, we conclude that even Startups are cautioned not to get sucked into Agile.
A Right-sized Design and Architecture
There is a right-sized design and architecture for any software application. Instead, Agile drives the software towards a fallacy. The result is the fallacy of local-minimum and local-maximum designs. This outcome lacks the requisite stability, and sustainability, for durable and supportable software.
Another pitfall of Agile is local-minimum and local-maximum designs and implementations. The Agile "fail-fast" maxim results in this fallacy.
Unsuspecting managers trust the mandate: "We will be agile." Why not report objectively? They would rather change the measure than report metrics that yield unbiased findings. Software engineers pick up terrible habits as they drive to meet arbitrary cadences. Overall design and architectural integrity lack requisite governance across sprints.
Many large enterprises resort to setting up centralized software architecture teams. The sense is that there is goodness in company-wide standards. In time they come to realize the futility of such undertakings. The strategy fails even across a modest portfolio of software applications.
On realizing the error, the enterprise reverts to distributed architecture teams. The change is to no avail, The company experiences irreparable damage.
Agile dupes all parties into adhering to abusive timelines. These are timelines that a reasonable Software engineer would reject out of pocket. Well-intentioned SCRUM Masters and Kanban Leads are accountable only to cadence. These individuals lack relevant understanding of the relevant software requirements. That facet of the work belongs to the engineer assigned to a user story. The result: blindness to design and architectural integrity. It takes time to analyze the right-sized technical design for any software application. Likewise, it takes time to govern design. It also takes time to govern architectural decisions encountered when implementing user stories. User stories cannot await such governance.
It is important to take into account the impacts on large legacy applications. It may take years to prepare the required prerequisites for Agile development. To validate any changes to the software, comprehensive test suites are mandatory. Without this important capital, the wheels fall off the bus. Progress stalls. This halt arises from a mass of unanticipated defects in the assembled solution. This exposes the tunnel-visioned nature of Agile methods.
We conclude that Agile Methods have hoodwinked the Software Engineering Community. We've had our expertise assaulted by herd mentality and fad culture. In the end, aren't we falling prey to a fallacy of extremes? Waterfall methods seem too inflexible. We learn too late that the software doesn't work, With Agile, no one knows if the software broke, or if it will break. In an agile regime, we always find failures and retool as needed. There are factual limits to what can and what cannot be re-tooled. Often, the functional requirements of the software are not well-documented. Agile methods aggravate this problem. Functional requirements are not well documented within an agile regime.
If we focused on this one issue, wouldn't we achieve a better outcome.? Agile is short-sighted. Agile fails to address critical lifecycle considerations of software. Worse still, it tends to obscure that needed perspective. Agile tends to aggravate the lack of suitable and sustainable software documentation. In the end, there is no path to a comprehensive rewrite. Thus, Agile introduces prohibitive costs over the long term. These costs are far less extreme with non-Agile methods. Agilists omit this fact when selling the Agile Transformation initiatives.
