Full disclosure – I am an Agile project manager. I’m also a “traditional” project manager. I’ve spent 30+ years in the IT Services industry and have been responsible for leading dozens, if not hundreds, of projects, global strategic programs and more “initiatives” than I can count.
The “traditional” approach to Project Management, which focused on deliverables, milestones, schedule and budget variance has been given a bad reputation in many circles these days but none so strongly as in the IT world. It has been argued that this approach takes too long, that the benefits are not realized until the end, it is difficult to coarse-correct, business moves and changes too fast and that it is simply and anachronism that has reached its natural end-of-life.
The newest solution to all problems and those associated with traditional project management lies in adopting the Agile approach, or so we are told. Agile is the latest of many business trends we’ve seen come and go over the years. We are told by Agile proponents we should focus on deliverables, not process. We should provide iterative benefits and that speed trumps everything else. In this brave new world, the triple constraint of time, cost and quality is now only time and cost. Quality be damned! Or in Agile terms, “quality” becomes, “backlog”.
Also, in the nirvana-like world of Agile, all project participants are highly skilled, highly motivated employees that will always tell the truth about their progress towards completing the sprint, will always deliver on time and with the requisite quality. They will tell you they are too smart, too creative, to be held to complete specific tasks on time and budget. “Just hold me accountable for the deliverables” is the mantra; “tell me what you need not how to do it”. And, of course a favorite among IT staff, “it’s complicated, I really can’t explain it to you but we’ll get it done when you need it”. And, oh, by the way, if we don’t, we’ll just put the unfinished work in “backlog” and finish it “eventually” and “DON’T ASK ME TO DOCUMENT ANYTHING.”
So, we hold the team accountable for the deliverables, but hold the project manager accountable for overall success/failure of product/service being developed. And, critical project elements that do not provide “visible business value” and cannot be compromised (e.g. enterprise network, data and application architecture and interoperability) don’t always fit nicely into the Agile approach. If these critical elements are not given proper attention, scalability, reliability and solution redesign become a perpetual list of backlog items.
The entire process serves to put up a vail of proficiency and competence that is not always deserved. It serves to enhance the IT priesthood with a “pay no attention to the man behind the curtain” attitude.
Don’t get me wrong, like any methodology, Agile (or for that matter, traditional project management) has its strengths and can be successfully used to get work done. But Agile should not be seen as the silver bullet that will solve all development and implementation problems.
Agile works when you have a team of very skilled, highly motivated, autonomous and disciplined employees that can truly take the ball and run with it with flawless communication inside and outside the team. It also assumes that workers will be totally forth-coming and honest in each day’s scrum and that constraints and issues will be resolved quickly. It assumes a highly informed and educated internal customer that will actively participate in the scrums and sprints and will provide valuable input and guidance to the project team as needed. But, if these conditions are not present in the environment, Agile can be used as a smoke screen to hide the team’s inability to work under direction and meet specific deliverables on-time, on budget. Without proper governance and the right team, Agile can become the new corporate con game.
Let us know what you think. We’re always interested in hearing people’s thoughts.