This tongue-in-cheek article highlights how inverse versions of the Agile Manifesto and the 12 Principles of Agile Software Development actually line up with standard software project management practice. Unfortunately, many of the contradictions stated below are common throughout “Agile” projects as well.
The Anti-Agile Manifesto
In the interest of controlling how software development teams develop software, management values:
Processes and tools over individuals and interactions
Comprehensive documentation over working software
Contract negotiation over customer collaboration
Following a plan over responding to change
That is, while we may, if pressed, acknowledge that there is value in the items on the right, we value the items on the left almost exclusively.
The 12 Principles of Anti-Agile Software Development
We follow these principles:
- Our highest priority is to ensure developers are on track to finish all of the work defined in the contract, on time, and within budget. Customer satisfaction is a desired outcome but not required to meet contractual obligations.
- Prevent requirements changes, as much as possible, to ensure adherence to the plan. Adherence to the constraints of the “Iron Triangle” is more important than advancing the customer’s competitive advantage.
- Deliver working software infrequently, from months to years, with a preference for the longer timescale.
- Business people and developers avoid working together throughout the project. Communication is mediated through copious documentation and requirements gathering proxies.
- Sap project members’ motivation and their urge to self-organize. Make them responsible for results without providing direction, resources, support, trust, or authority to get the job done.
- The ways of conveying information best aligned with top-down control of software projects are highly-detailed documentation and continuous status reporting through multiple organizational levels.
- Percentage completion of project tasks is the primary measure of progress.
- Higher levels of worker productivity are best achieved through arbitrary deadlines and making everything a high priority. Reward individual heroics and blame poor performance on individuals rather than fixing systemic problems. Project and business priorities should drive the pace of software development, not the ability of sponsors, developers, and users to keep pace.
- Attention to technical excellence and good design can be ignored when schedule pressures mount.
- Simplicity–the art of maximizing the amount of work not done–is lazy and runs counter to maximizing resource (employee) utilization metrics.
- The best architectures, requirements, and designs emerge from senior engineers, architects, and business people prescribing the project’s engineering approach upfront.
- Teams work best when they follow highly-prescriptive processes and procedures imposed on them from above. Adjusting behavior based on demonstrated results (empiricism) leads to loss of management control.
Conclusion
Turning a concept on its head can help us view it from a different perspective. While it is not the intent of management to establish and perpetuate cultures that stifle agility, traditional project management practices often do. It is proper to define the culture we want to foster however, understanding what we want to avoid is just as important.
Last Updated on February 2, 2022