Agile does NOT mean no planning or testing!!

I have never been a fan of agile project management and software development methodologies like XP, Scrum, etc… Not because they don’t have merit, for in fact, in theory they are fantastic. And in the hands of competent people, it can facilitate wonderful working code without making the lives of team members miserable. If you read through the “12 principles in the Agile Manifesto”, how can one disagree? Just looking at the authors of the manifesto, industry fathers such as Alistair Cockburn and Martin Fowler, you know this movement is credible.These are folks that have worked on the largest software projects in the Fortune 100 and DOD. No doubt the administrative bureaucracy of contracts, gateways, reviews and documentation frequently thwarts creativity, efficiency, and in many cases common sense.

Yet the problem with Agile is its adoption by smaller organizations that have no discipline or structure whatsoever. It is often championed by IT managers with little knowledge of structured practices who simply want to gain the favor of business management by promising lower costs through elimination of pesky planning activities, costly testing, and silly rules. They typically do not understand structured best practices and are intimidated by them, so they latch on to “agile” methods to free themselves from accountability. What follows is cowboy coding, poor (or no) testing, chaos, and software releases followed by several “emergency fixes”. Isn’t Agile Principle #7 “Working software is the primary measure of progress.”?

These people just don’t get it. Their misuse of the strategy is ruining Agile’s reputation.

I point people to the literature written by the Agile Manifesto authors themselves as they respond to these applied misinterpretations. Take Cockburn’s own Agile Software Development: The Cooperative Game (2nd Edition). In the section, “Misconstruing the Message”, he states “Over the last five years, people have been quoting agile rhetoric without adopting the elements that make the agile approach work.” He then lists and refutes the “harmful misquotations of the agile manifesto” including.

  • “Agile teams don’t need plans”
  • “Architecture is dead; refactoring is all you need”
  • We don’t need no *%@! managers!”
  • “Agile development is low in discipline”

Martin Fowler writes:

The agile methodology movement is not anti-methodology; in fact, many of us want to restore credibility to the word. We also want to restore a balance: We embrace modeling, but not merely to file some diagram in a dusty corporate repository. We embrace documentation, but not to waste reams of paper in never-maintained and rarely-used tomes. We plan, but recognize the limits of planning in a turbulent environment.

In Kevin Tate’s Sustainable Software Development: An Agile Perspective, he states “Unfortunately, there are teams who have adopted XP because they believe it frees them from having to do design. XP is not a license to hack. Just because the emphasis is on working software and simple design does not remove the need to do design”.