Why The Manifesto For Half-Arsed Agile Software Development Is Actually Important But Not Enough

Reading time ~ < 1 minutes

“That is, while the items on the left sound nice
in theory, we’re an enterprise company, and there’s
no way we’re letting go of the items on the right.”


Not mine but this resonates strongly with my experiences. I’ve seen varying levels of agile interpretation including this during my career so far. (By contrast, the team closest to the original principles that I worked with hadn’t even given their working practices and culture a name.)

The sad fact is that it’s all too easy to fall into the checkbook agile, control & distrust trap in large organizations. What I like about this spoof is that it captures Ron Jeffries thinking from this article in a concrete and direct way that even the most disconnected exec should recognize what their teams are doing wrong.

It also uses a subtle but powerful tool that makes this worth paying attention to rather than just reading, chuckling and inwardly despairing.

In trying to understand what you should do it’s important to understand what you should not do. The original manifesto is vague. Many of the myths that cause execs to distrust agile when they first read the manifesto are made manifest due to its vagueness. Similarly, developers that see a get out of jail free card on having to do anything but cut code in the manifesto are able to do so.

The negative ad-libs at the end of each point in this cynical version provide a clear “bad” marker; a new, tangible triangulation point to avoid.

What we need are equivalent “good” triangulation points based on business reality for large-scale software development rather than a noble vision so that we can help our teams and managers do the right thing.

Leave a Reply

Your email address will not be published. Required fields are marked *