TBT – Repost: Bastardizing Agile

A few days ago I wrote about the difficulties of software estimation. I’m on a personal vendetta to improve on this lacking area of the industry, but first…


I want to clarify from my former post that I did bastardize the word Agile. I made sweeping statements like, “If your project has a drop-dead due date and a hard budget, you’ll never deliver using Agile.”

And in all honesty, that’s not fair. While my statements are too often proven accurate — Agile is not the problem, and neither is scrum. The issue of planning using these methodologies are the symptoms they carry. But every process has symptoms. Further, symptoms are most often user error — not process error.

The Agile Manifesto outlines a handful of guiding principles. It doesn’t say that you have to hold daily scrum meetings, or scrum of scrum meetings, or work from a product backlog. It tells us to value working software over documentation. It tells us to value collaboration over tools and processes.


There isn’t a statement within the manifesto that I can argue against. Each statement is worth its weight in gold and should be applied to every project; waterfall or otherwise.


The point I’m making is that while I continue to believe that scrum is scapegoat for better planning, better leadership and effective execution; my bastardization of the word Agile was for effect, and not literal. Monday I’ll explain why I feel that scrum over other methodologies is farther from the way we should be planning than other approaches.