It has been almost 20 years since the publication of the Agile Manifesto and the 12 Principles of Agile that undergird it. During that time, the Manifesto has been a catalyst for profound changes in how we work, not in just software development, but across industries, governments, and nonprofits worldwide. Despite having attained such a level of influence, the Agile Manifesto is regularly misinterpreted in ways that undermine its intent.
This article sets the record straight. To do so, I walk through the Manifesto, line by line, provide context, and dispel a few myths. First, let’s read the Manifesto:
I’ll now go over each sentence starting with the first sentence:
The Agile Manifesto and the 12 Principles of Agile together serve as the foundation of Agile practices. Rather than prescribing how to “do” Agile, Agile describes ways of working that steer away from a bureaucratic, command-and-control style of management to a decentralized, self-organized, and adaptive approach to building and delivering software systems.
Agile is a bottom up approach to software development in which developers and other technical contributors manage and continually improve the systems or solutions they develop as well as how they develop them.
Next, I skip to the last sentence:
The Agile Manifesto states a preference for lightweight processes supported by face-to-face communication and sustained and meaningful engagement between technical teams, project sponsors and stakeholders, and customers and end users. It does not prohibit traditional project management practices such as communicating via documentation, instituting processes, leveraging tools, planning activities, and engaging in contract negotiations. Agile does not prohibit them because they are all necessary to some extent for any technical project to succeed. What Agile argues against is measuring progress based on accomplishing these internal project activities. Agile argues for determining project progress based on delivery of useful and valuable solution functionality and structuring both the work and how teams are organized to best incorporate changing requirements and lessons learned into emerging software solutions.
Now I continue with the first tenet:
Software development is a creative endeavor. As such, people are at the heart of it. Tools and processes should support open and direct collaboration between people, not serve as substitutes for it. Using what are often described as “Agile tools” such as JIRA or VersionOne does not equate to working in an Agile way. Processes do not make up for a lack of training and support for those who do the work. A focus on improving people and the teams they work in yields much greater dividends than instituting processes and using tools.
The second tenet:
The only real way to verify and validate solutions and gauge project progress is by developing and delivering working functionality. However, documentation is necessary, even in Agile projects.
The question is how much documentation is necessary and for what purposes? Too much documentation generates waste, slows down development, and fosters a false sense of progress. Too little documentation can lead to a loss of project knowledge, hampers the ability to manage projects, and may leave customers and end users without the information they need to use the resulting solutions.
There is no magic formula for striking the right balance. Collaboration between technical teams, sponsors, stakeholders, customers and end users will bring to light what documentation is necessary and to what level of detail. Just keep in mind that, when it comes to documentation, “less is more”.
It is also important to remember that documentation has inherent drawbacks. It is often out of date, its usefulness is often time limited, and it can be a source of confusion. Think hard over these drawbacks before engaging in documentation activities to ensure they are worth the effort.
The third tenet:
Traditional project management focuses on contract negotiation and enforcement, often to the detriment of collaboration. While Agile projects are also bound by contracts, the focus is on fostering a win-win atmosphere of collaboration between those who develop and deliver software and those who sponsor and use it. Collaboration in Agile occurs across the entire software development lifecycle.
The fourth tenet:
For most non-trivial software development projects, predictive planning is the wrong approach. Software is intangible and infinitely changeable. The opportunities to change a software system are as infinite as the number of reasons to change it. Predictive software development plans do not survive first contact with project reality.
Agile planning is adaptive planning. Project plans evolve as the project proceeds. This affords the flexibility to stop development when a solution satisfies the need or when the project is no longer viable. We also avoid over-engineering solutions and developing features that few, if any people, actually use. This allows us to control project cost and schedule, by managing scope, without sacrificing quality.
Conclusion
Saying that understanding the Agile Manifesto and its implications is necessary for conducting successful Agile projects and Agile organizational transformations is an understatement to say the least. Too many Agile implementations fail because people rush to learn and apply the mechanics of a particular Agile approach (e.g., Scrum, XP, Kanban) without understanding the principles behind it. Agile is not a methodology, a product you can buy, or a process. You cannot templatize and checklist your way into agility. Agile is a way of working born from a small set of principles. It is up to all of us to employ Agile best practices, and develop new ones, that align with those principles.
Last Updated on February 2, 2022