Follow discussions in any online PM community over a couple of weeks and you’ll run across at least one discussion thread vilifying agile project management.
Whereas a few years back supporters clearly outnumbered the naysayers, the balance appears to be shifting in the opposite direction.
This resistance might arise as a consequence of the failures a number of companies have had in successfully implementing agile methodologies coupled with the very understandable fatigue of listening to one too many fanatics preach its virtues.
However, I’m not quite ready to throw the baby out with the bath water.
Agile is just one tool in the utility belt of an experienced project manager, but like any tool, it needs to be used the right way and for the right purpose.
To that end, I’d like to debunk just a few of the more common misconceptions held by those who have either never worked on agile projects, or those who have experienced agile gone horribly wrong.
- Agile means undisciplined: In order to deliver products or services frequently and to be able to meet customer expectations within fixed cost or schedule constraints, teams need to apply more rather than less discipline. A lack of quality in producing key deliverables impacts velocity through unnecessary rework and a good self-managing team will take swift steps to ensure such defects will not recur. Well-run retrospectives help to identify ideas for the team to implement in future iterations to be more productive – this cannot be achieved by the undisciplined. Finally, well designed architectures and risk-driven design are also hallmarks of well-run agile projects – again, not evident in undisciplined environments.
- Agile means no documentation: Agile, like lean, attempts to eliminate waste which does not add value to the customer. While an agile project might generate less documentation than a traditionally-managed one, documentation which is essential to producing high quality deliverables will still be created.
- Agile means no measurements: The total number of different project status elements captured might be reduced, but the remaining ones are sufficient to gauge progress. Instead of having teams subjectively assess percentage complete or work effort remaining, each sprint or iteration will end with teams identifying which work items were completed. This in turn enables regular calculation of velocity which can be used to forecast completion of work item backlogs.
Agile is not for every organization or for every project.
Specific practices can have broad applicability, but the behavioral, cultural, quality & resource changes required to successfully implement a specific agile methodology takes real commitment and follow-through.
However, the same can be said about implementing PMOs, and organizations continue to set those up, this should not be taken to mean that failure is inevitable or that agile has had its fifteen minutes of fame.