Agile methodology: Why faster doesn’t mean better


Over countless years and projects, Project Managers (PMs) have been working to define a better, faster, and easier way to deal with the need for structure. From this work comes most methodologies and standards that are in existence today. One major problem that often gets PMs in trouble during a project concerns the discrepancy between their understanding and the executive’s understanding of how fast a project can be executed when utilizing Agile methodologies.

First, before we go any further with this article, I want to say that I have nothing against Agile methodologies. Some of the best PMs I know use Agile very successfully for the delivery of their projects. As with anything, the decision to use Agile methodologies needs to be made for the correct project, and that is what I have an issue with. It is not a silver bullet and definitely not suited for every project that comes along.

Agile in its different shapes, forms and variations have been around for quite some time, but it has made leaping bounces forward into the project management environment over the last 5 – 10 years more so over the last five years when PMI decided to add it to their certification roaster. PMI took advantage of the fractions of Agile followers in disagreement over how to rally themselves into a cohesive group and created the PMI-ACP certification which is still the fastest-growing certification for PMI.

In making it to the mainstream, it became a darling of the project management world with countless articles, books, and training offerings. What also happened is that the word Agile in a lot of Executives’ minds became synonymous with flexible and fast, without the planning rigors of other methodologies. Some have even been convinced that Agile did away with most of the documentation needs found with other methodologies. Another thing that convinced people that there was too much wasted time in working any other way.

The race was one to get this new shiny “toy.” A lot of organizations had to have it and jumped on the bandwagon. It wasn’t until a few months later that a lot of them realized that properly working on an Agile project did not necessarily mean faster and we still need to master some of the basics that get us in trouble in the first place on projects.

A problem that still exists, Agile or not is the fact that requirements remain elusive, and getting a complete set of requirements early is still the number one issue for most. Having good results is as always based on having a valid set of requirements. If we do succeed in getting a good set early, we often falter in our ability to schedule their delivery based on our available resources.

1 2Next page

Leave a Reply

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

Back to top button