I liked agile as it was practiced in the “Extreme Programming” days.

• Rather than attempt to design the perfect system from the get-go, you accept that software architecture is a living, moving target that needs to evolve as your understanding of the problem evolves.

• Rather than stare down a mountain of ill-defined work, you have neat little user stories that can be completed in a few days at most and you just move around some Kanban cards instead of feeding a soul-sucking bureaucratic ticketing, time tracking and monitoring system.

• Rather than sweat and enter crunch mode for deadlines, the project owners see how many user stories (or story points or perfect hours) the team completes per week and can use a velocity graph / burndown chart to estimate when all work will be completed.

.

But it’s just a corporate buzzword now. “We’re agile” often enough means “we have no plan, take no responsibility and expect the team to wing it somehow” or “we cargo cult a few agile ideas that feel good to management, like endless meetings with infinite course changes where everyone gives feel-good responses to the managers.”

Having a goal, a specification, a release plan, a vision and someone who is responsible and approachable (the “project owner”) are all part of the agile manifesto, not something it tries to do away with. I would be sad if agile faces the same fate as the waterfall model back in its time and even sadder if we return to the time-tracking-ticket-system-with-Gantt-chart hell as the default.

Maybe we need a new term or an “agility index” to separate the cases of “incompetent manager uses buzzword to cover up messy planning” from the cases of “project owner with a clearly defined goal creates a low-bureaucracy work environment for his team.” :)

One standout statistic was that projects with clear requirements documented before development started were 97 percent more likely to succeed. In comparison, one of the four pillars of the Agile Manifesto is “Working Software over Comprehensive Documentation.”

Requirements ≠ Documentation. Any project with CLEAR requirements will be most likely to succeed. The hard part is the clear requirements, and not deviating.

One Agile developer criticized the daily stand-up element, describing it to The Register as “a feast of regurgitation.”

The inability of management to conduct productive meetings is even more well-known than their inability to conduct a decent hiring process, and we all know how broken that is.

The study’s sample and methodology are not linked so I suspect a huge bias, in that the projects succeeding sans-Agile have been successful without it long term, while the Agile projects chose Agile because they were unsuccessful pre-adoption — you don’t adopt agile if you were already successfully delivering projects.

Note that this is failure to deliver on time, not failure to deliver full stop.

I also think a lot of places claim to be agile, but don’t follow or understand the principles at all. Another commenter here is the perfect example of that where they say the opposite of what’s in the agile manifesto and claim that it’s a representation of what it says.

Maybe that’s a fundamental problem with agile. It’s just a set of loose principles rather than a concrete methodology being pushed for by a company and it has therefore been bastardised by consulting companies and scrum masters claiming to teach the checklist of practices that will make your company agile. Such a checklist does not exist, it’s just a set of ideas to keep in mind while you work out the detailed processes or lack thereof that work for you.

For anyone that wants to refresh their memory on the agile manifesto:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.