Rebooting the Agile Manifesto – Part 3

Before I finish crawling out on this limb, let me first say I am a practitioner of Scrum and Kanban, the two most common Agile methodologies, and my inflammatory comments below are a result of experience, not resistance. Feel free to discount my opinions as the rantings of someone who just doesn’t get it. Possibly true. I’m still going to get this off my chest.

I’m sure you already know you can find the Agile Manifesto and Agile Principles at I’ve quoted it here. Refresh your memory and join me below.

Manifesto for Agile Software Development

We are uncovering better ways of developing software by doing it and helping others do it.

Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more.

Let’s start with the epilogue at the bottom, which states that we value the left side of the statements above more than the right side. Note that it does not fully reject the right in favor of the left. This is where the Agile legions often go astray. It makes no sense to discuss the application of the AM without acknowledging that its declarations represent emphasis and not replacement. It’s not the AM’s actual ideals that bother me; it’s their misinterpretation.


Some Agile practitioners believe that we need to free ourselves from arbitrary constraints and acknowledge that our work is fundamentally unpredictable. Only dinosaurs cling to outdated crutches like schedules and deadlines.

What painful memories and shattered dreams led to this revolution, which seeks to free software development from the mundane constraints of predictable results in favor of communal free expression?

It’s not so difficult to comprehend why overworked and undervalued coders and testers everywhere have succumbed to the Agile Manifesto’s succubus. However, the purists’ righteousness cloaks condescension by proffering only the Manifesto’s libertarian benefits, captivating to the technical proletariat, who impose it upon their stakeholders by siege. While the Manifesto’s message masquerades as empathy for the beleaguered business owner, if you read between the lines it says, “Commitments are useless. Trust us.”

That’s why I’m not refuting the Manifesto’s four declarations outright, which would make me guilty of preaching anti-dogmatic dogma. Dogma is dogma. I only want to soften the rhetoric. I’ve addressed the AM’s first two principles with greater detail in the two preceding articles, and the fourth in still greater detail in my four part series on Date-Driven Agile. Here’s a summary of my own observations:

  1. People do matter, and structured communication, often labeled pejoratively as “unnecessary process” reduces confusion and stress. Precise communication is a foundation of civilization, and ask any judge or trial lawyer how easily our words and deeds are misconstrued when we rely on casual, informal exchange of ideas. See Rebooting the Agile Manifesto – Part 1.
  2. Comprehensive documentation, meaning a specification complete in every last detail, isn’t usually necessary.  Informative will suffice. However, let’s remember that engineering, including software engineering, is a design discipline. See Rebooting the Agile Manifesto – Part 2.
  3. Contract negotiations? This is the most presumptive of the four declarations. Stakeholders, whether external paying customers or internal users, must continually evaluate ROI. The only way to compare return with investment is to know cost, at least within reasonable variance. The purpose of a contract is to assure, to the greatest degree possible, that the parties understand the exchange of value to which they are committing. Open ended software development projects usually end of their own accord. In disaster. With broken hearts, broken dreams, and broken budgets.
  4. Planning is common sense. Hardly any collaborative pursuit of consequence has ever been completed without a plan. Most of us wouldn’t even take a vacation without some sort of plan, yet we think it’s unnecessary when we’re spending thousands or millions of dollars to develop software. Sure, requirements do change midstream, for many reasons. A plan enables us to measure the anticipated impact of those changes so we can make informed decisions. See Plan for Change.

Not all software development projects are alike. A consumer Web application, such as Facebook or Amazon or Angie’s List can advance incrementally at whatever pace fits the team and budget. These companies don’t promise make-or-break features to their consumer customers. Innovation may increase Amazon’s customer engagement, but there are no externally enforced deadlines or requirements. Agile methods, especially Scrum and Kanban are ideal for these products.

At the other end of the spectrum are the mission-critical business applications. I’m not talking about “horizontal,” general-purpose enterprise systems, such as ERP and CRM, but essential applications defined by unique business models, like those required to operate airlines, banks, factories, hospitals, etc. Unlike on-line consumer services, most “vertical” enterprise applications must perform essential, pre-determined business functions. Often they must match or exceed the capabilities of the legacy systems they’re replacing. Vendors win business in these markets by offering specific features at specific costs, and most importantly, in time to seize emerging opportunities or to meet regulatory deadlines. Their applications must fulfill contractual requirements at known costs. No IT executive in their right mind will accept an open-ended vendor contract with no milestones or guarantees, especially not for a multi-million dollar system that can make or break their company. What’s the Minimum Viable Product for the control systems in a jumbo jet? Sometimes we need to commit to a rich feature set.

When you’re outfitting your team for a complex initiative, I recommend you deconstruct the assumptions embedded in the AM and the Agile Principles, and build back up, not to immutable, gospel truth, but to a sturdy selection of tools you can apply, as appropriate, according to the unique goals and constraints of the project at hand.

In a future post, I’ll look at the flip side of my own argument, with a tour of the twelve Agile Principles and how most of them lead to greater efficiency, quality, and just as importantly, job satisfaction.