Thanks Kevin. People spend years (or even lifetimes) devoted to the study of project management. I have a project manager sitting behind me as I type this – and I know he wouldn’t take the approach that ubiquitous rules are the only rules. We have to be adaptable. Agile comes in many flavors, and nobody does it the “right” way 😉

One of the things I always encourage when talking about “Agile” is “flexible” – you have to make the process/methodology work within the team and constraints you’re a part of. One size fits all never works. And creates enemies. The most critical aspect, still, to me – is a prioritized backlog. Whether or not estimation plays a role in that prioritization has to depend on the teams doing the work. But if the backlog isn’t unified and prioritized, the rest of the communication breaks down horribly.

Indeed, but whatever methodology you’re using (or not), it’s always been a question (at least in my mind) as to how to measure the benefits of a methodology. IMHO, nothing replaces continual estimate review and good communication. The need for a formal methodology is like laws — they’re there because otherwise people don’t do them.

Clever. 🙂 “Agile enough” sure is a hard thing to measure, isn’t it?

There’s no silver bullets. Thanks for making that point.

Your article is doing nothing to help agile as unfortunately most larger companies seem to believe that agile = scrum which it is not & in a lot of ways scrum practices alone will not help a company move towards being truely agile.

You’ve focused on the purely project related facets of the the methodologies and mentioned nothing around the technical or product practices and when it comes to the Phoenix Project appear you write as if you have missed the point entirely that it is about lean prinicples & practices and moving towards an devops culture.