The Agile Manifesto Has Eight Open Bugs
It’s time to move on from the Agile Manifesto.
Over the past twenty years, the Agile Manifesto has guided and governed software development. By governing software development, the manifesto has impacted bigger picture activities such as project management and innovation. The manifesto aimed to improve on the common methodology of that time – circa 2001, especially Waterfall. Twenty years has passed. Project failure rates are still high. Often, the employee experience is not great. The manifesto has not aged well. It doesn’t serve your innovation work well. As time passes, you incur methodology debt. This blog post explains eight problems in the Agile Manifesto and why it’s time to move on.
1) The methodology emphasizes software, presumably at the expense of people. Software is not what makes innovation difficult. What makes innovation difficult is people – how we interact, collaborate, compete, and govern each other. You need a methodology that improves the people-oriented work. You must improve these three activities of interaction, collaboration, and governance.
2) The manifesto favors software over comprehensive documentation. The alternative to comprehensive documentation is talk and email. When you don’t document something, those decisions don’t just disappear. The decisions reside in people’s heads and increases tribal knowledge. The decisions reside in people’s email, stagnant and unshared with other stakeholders. Comprehensive documentation is valuable since the right documentation doesn’t lose value. Documentation has a low cost when sharing with a new stakeholder. Documentation has a low barrier to revise when things change.
In this decade of the 20s, the customer story matters. The manifesto favors software over story. It favors continuous delivery of software over getting the customer story right. You must get the customer story right. That is difficult on its own, and once you get that right, getting the software right is comparatively easy.
3) The manifesto welcomes changing requirements, even late in development. When your go-live dates are two weeks apart, there is no such thing as “late.” When a customer changes requirements – changes their story – that just has to ripple through the documentation. The manifesto wants to avoid go-live dates that are 6, 12, and 18 months apart – great! The transparency of documentation fosters small, short projects. Keep your projects modest to minimize vulnerability to new information mid-project. But don’t encourage customers to change their story “late.” Encourage your customers to get it right as early as possible. Then establish an innovation rhythm that easily accepts new information. “Late in development” is not a constructive term. It lets the Business off the hook and undermines their ownership and accountability. If a customer wants to change their story every week, consider not coding at all, because the changes result in whiplash for downstream stakeholders. Turning the salmon too much destroys the salmon.
4) The manifesto mandates that businesspeople and developers work together daily throughout the project. This fosters the meeting fatigue that so many organizations have. If you have a structured, paced schedule for collaboration, a mandate to force a daily interaction is disruptive – interruptive.
5) The manifesto urges you to build projects around motivated individuals. No. A call for “motivated individuals” hints of personal agendas and intra-team competition. It calls for “people who want to get out of bed.” This is a low bar. Instead, build projects around a shared purpose. A shared purpose inspires people to get out of bed, it neutralizes personal agendas, and defuses intra-team competition.
6) The manifesto proposes that working software is the primary measure of progress. No. This statement ignores the numerous small wins that teams have before they touch software. Small wins are the best measure of progress. Small wins consist of small agreements – small, documented agreements among the right stakeholders. This is why the metaphor of an Agreement Factory is so valuable. Every major success consists of 1001 smaller successes. Working software is one of a few dozen agreements that a team must reach.
7) The manifesto emphasizes “continuous attention to technical excellence.” Technical excellence must take a back seat to story elegance. Favoring technical excellence over story elegance is like a movie with great special effects but a terrible plot. Instead, give continuous attention to “story elegance.” Story over software.
8) The manifesto states that simplicity is essential. Agreed! However, the manifesto defines simplicity as “the art of maximizing the amount of work not done.” The right term for that is “procrastination.” My teenager better not tell me they are keeping things simple through “the art of maximizing the amount of work not done.” The spirit of the manifesto’s statement is to avoid boiling the ocean at any given time. What the manifesto surely means is that you avoid a project with a large scope.
The manifesto appeared in 2001 because in the few years preceding that, the sense of urgency in innovation increased so much that Waterfall fell out-of-favor. The manifesto served innovation teams respectably for the past couple decades. But it doesn’t serve teams well anymore. Agile is not agile. The manifesto has bugs. It’s time to move on from it. Innovate how you innovate.