Learn about how and when to use Agile methodology. 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. How and when to use Agile methodology is key. 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.
Until we get better at the requirements integrity and resources allocation within our means, there is no methodology out there that can help make things magically better or faster.
It is my firm belief that what we need to concentrate on does not reside at the lower end of our processes but rather way earlier and this would be project prioritization.
In order for this to happen, you first need to put an emphasis on how the projects are prioritized and delivered keeping resources optimization as a top priority. This assists in giving plenty of time to elicit requirements so that we have a good set to start the development and deployment processes.
Only trying to find ways to go faster and faster it does not make us better at what we do, it just makes us head towards disaster sooner. Knowing how and when to use Agile methodology is essential to achieving success. At some point slowing down just a tad makes us look closer and think better.
Similar Content:
-
Comparing agile frameworks
-
A starter’s guide to agile project management
-
Using risk-based thinking to reduce deviation from planned results
