Previously, I have exposed some significant drawbacks to the agile development process that include a lack of planning, internal QC testing, minimal documentation, the false perception of accepting changes from the stakeholders with a smile late in the process. The most critical issue with agile is perhaps philosophical. Historically, many movements that prescribe to a “Manifesto” have demonstrated that such group fervor centered solely on core principles can lead to unhappy outcomes, eh Comrades?
One such unhappy agile outcome in which I was a participant involved nearly two years of development, 25+ developers, project managers, subject expert consultants and an assortment of replaceable scrum masters. All expense paid focus groups sessions were held at the Arizona Biltmore Resort with a dozen IT directors from tier one merchants to gain direct insight into what the next generation POS app should possess. As a surprising result, the project started with a deeply detailed specification (200+pages) provided by industry experts and paid for by management.
Agilers being agile however, refused to read the spec because it was way too long. Instead they began developing with the app feature briefs handwritten on index cards, having no POS experience and no understanding of how one index card feature might impact another. The development sprint cycles were two weeks with an additional week of inbred testing. The sprints were performed under the watchful eye of a certified scrum master who had never written a line of code. Nor did this professional pedagogue understand that he would soon be responsible for creating a new definition for the acronym POS.
What could go wrong here? Well I’ll tell you. After a humiliating year of development without even basic functioning software, I queried the scrum master, “Why don’t we have anything that works?” His classic response was, I can give you speed or quality, which do you want?” My reply was, “I want a new scrum master!” The company being totally committed to agile, doubled down and hired two scrum masters to replace him. Two is always better than one right?
The project painfully continued for nearly another year because the stakeholders and errant scrumsters misled management about their phony progress. They held to the agile principles at an ultimate cost to the company of nearly $9M. Management finally gave up and bought a POS company to get something to market. At the end, both scrum masters and every developer engaged on the project was externally repurposed. Months later, with empty workstations, grease pen notes on all four walls, and the Agile Manifesto was still written on high, the empty scrum room took on a Chernobyl likeness.
I mention this example of Agile “gone bad” because this is what happens when the process becomes more important than the outcome. While this team started off with fresh-faced idealism for using agile’s sprint principles for faster results, they lost the race. Twenty-five plus developers all working from feature index cards with no focus on the core was doomed from the start. Sprints are great for small projects, but major applications are marathons.
Clearly, agile and traditional waterfall development methods each have their respective merits depending on the type of project requirements. Large applications require more pre-planning than basic apps and upgrades. Developers should use the methods that work best for a given project and forget about the “manifesto” hype-de jour. Hiding behind agile principles to eliminate documentation at every level is not a plan for success. The same goes for adequate QC testing. Bringing a quality application to market is what ultimately matters. Perhaps we could launch a new manifesto-less developer movement that focused on the outcome and not the process.