The Agile methodology is great for getting turgid development teams to start working faster and more coherently. With Agile, which focuses on more rapid, incremental deliverables and cross-departmental collaboration, the bureaucratic plaque is flushed from the information technology groups’ arteries. But there is a dark side to Agile approaches.
More often than we would like, Agile gets confused with a just-do-it-and-just-meet-the-date approach. The Agile ideas just become lip service; people spew Agile terms while completely ignoring the intent of the Agile Manifesto (www.agilealliance.org/the-alliance/the-agile-?manifesto), instead doing bad short-cuts, side-stepping quality, and avoiding the time-consuming tasks related to understanding the business users and the solution under construction.
In such a “get ’er-done” context, the “successful” Agile team (perhaps, better stated as “NoAgile”) ideally interacts with the organization via leaders who can tap dance well and justify to their benefactors why meeting those dates requires drastically altering scope. These pied pipers work at convincing management that the altered scope and direction are good; whatever is delivered is sufficient; and users should be glad to receive just what it is IT can deliver versus what was originally agreed upon. Clearly, delivering something is more important than delivering the right thing. It is a Jedi skill, similar to convincing the imperial storm troopers, “These are not the droids you are looking for.”
Another NoAgile attribute is a severe disregard for specializing and specialists; project managers, business analysts, and even data modelers are considered not helpful to the process or potential bottleneck creators. Instead, the embraced view is that anyone can do anything, and doing everything by consensus via short meetings is preferred. All the human capital is divided into two groups: the smart guys and the not-so-smart guys. The smart guys get labeled architect-of-one-flavor-or-another while the not-so-smart guys get dumped into any other role. The focus of the team is either solely on the project, or perhaps even solely on a single sprint. Thus, any concern for an enterprise view is lost. What is good for the sprint becomes what is good for the enterprise, right or wrong. As long as dates are met, there is success, or at least that which will be sold as success.
One of the flaws with this NoAgile approach is that the resulting solutions are stove-piped and isolated, while also isolating the organization’s IT ecosystem components. Even the documentation reflects this stove-piping (i.e., there is no solution documentation, only project documentation). If multiple projects touch the same solution, no comprehensive and current overview of the solution exists. The earlier disregarded specialists might have helped address the now missing enterprise. Those feared bottlenecks might actually have been important issues that needed to be evaluated. Skilled business analysts, data modelers, and project managers enhance every project they work on. The NoAgile approach overlooks the idea that both IT and business teams must embrace being Agile, which means that business cannot avoid issues and hope they go away. Instead, business must be as actively engaged in positive decision making and action, as is everyone else.
These NoAgile implementations are returning their practitioners to an older age of nightmares. The NoAgile contingent forgets that being quick is not better than being good. The goal is to be both good and quick. Quality is crucial and should not be the baby tossed out with the bath water. Often it appears that this NoAgile approach arises due to a combination of Agile novice IT staff and a business team that still considers IT as a “them” and not an “us.” NoAgile is the IT attempt to deliver something while business avoids working with IT as much as possible. To prevent this anti-pattern, business leadership must embrace IT as a vital element of the organizational team, and they must commit to working through however many iterations of a solution that it may take for that solution to become the optimal solution.