Friday, November 6, 2015

Agile versus Traditional Project Management (somewhat) Explained.

So, what is an Agile project versus a Traditional project? First, a quick note on the roles in Agile, specifically the Scrum Master job which usually spawns the question. The Scrum Master is a role on an Agile project Team that is using the Scrum method for the execution of the work. The Scrum Master is not the Agile Project Manager (not to be confused with the Agile Coach). The Scrum Master and Agile Project Manager are two different roles with vastly different responsibilities. The Agile Project Manager’s responsibilities include all the responsibilities of the Traditional Project Manager (PMP®), and there is the added (new) verbiage that is commonly used to distinguish Agile from the Traditional projects. The Scrum Master (Associate Project Manager or Coordinator are similar roles on a Traditional project) is there to help the Agile Project Manager, and the Team, get it done. An Agile Project Manager may or may not have a Scrum Master for their project just as a Traditional Project Manager may or may not have a Coordinator. At the end of the day though, Agile is nothing new or really that radically different than a Traditional project. Agile is an iterative methodology and includes dozens of implementation methods, all of which – except Scrum – refer to the work period as an Iteration, just as it does in the PMBOK® Guide, the ANSI Standard for Project Management.

There are really only two differences between an Agile project and a Traditional one. First is at the core – Agile is change driven project management compared to Traditional project management which is plan driven at its foundation. Plan driven, as its name implies, plans everything out for the entire project duration before you begin work (usually). Agile takes that concept and modifies it to accommodate the adaptability required of being change driven (much like Rolling Wave planning in the Traditional world). Instead of a hard coded schedule broken into phases of 3-6 months, Agile projects have compose Product Backlogs with much shorter Iterations – 1-4 weeks (in Scrum they call it a Sprint), but the same basic paradigm applies. You still need to know what the work is that will be done (requirements) in a work period (a Work Package or Iteration Backlog) no matter how long it is, and that work will need to be prioritized (scheduled) and tracked (monitored) to completion. And don’t forget, all the other tenets of Traditional project management apply in Agile too. Agile projects need money (budget), stakeholder management and communications, risk management (not everything is organic in Agile), and you can bet there are going to be reports to be created and questions to be answered. Agile projects have much the same controls in place as Traditional project management with some added benefits, again to accommodate adaptability.

One benefit is the Scrum Master. Basically, they baby sit the team and facilitate the adaptability of an Agile method. Imagine, as a Traditional project manager you have a Coordinator that deals with the day to day interactions of the Team; communications in/out of the Team; chasing down the problems that hold up the project; and filtering all the chitter-chatter from those who qualify as a Stakeholder, etc. I’d love that! Think of all the time we’d save? “They” did - and then came the Agile Manifesto and the Scrum Master.

A second benefit is dealing with change, which was one of the driving factors in the development of Agile and the Agile Manifesto. In Traditional project management a great deal of time is spent on ‘non value-add’ activities around managing change. And in software development, where Agile methods were born – you’ve probably heard the story about 67% of an applications features are never used – well, given that rate of change, the Traditional methods couldn’t keep up – too much wasted time. In Agile, the Product Owner (Sponsor) can make changes in the requirements multiple times per day if they want and the process can accommodate it. There is no hard coded schedule.

So which way to go, PMP, Agile PM, or Scrum Master? Well, if you’re a serious Project Manager, you get the PMP, and because you are a serious Project Manager, you continuously add to your skills by mastering Agile, Scrum, and it wouldn’t hurt to throw in some process improvement with Six Sigma. In that case, you do the PMP, get Scrum Master, and pursue the PMI-Agile Certified Practitioner so you become an Agile PMP! In that order? Not necessarily. The PMP does have a 36 month, 4500 hour experiential component that you need to document to qualify for the exam, so if you have been a Project Manager for only a year or two, you can finish the Agile Certified Practitioner certification first which only requires 12 months of experience in the role.

There is one thing for certain. Agile project management is here to stay and will grow, I believe, to become the foundation of the project management standard. Project Management is evolving. Just understanding and using Traditional waterfall processes is not enough. Yes, there are a great many projects that by their nature must be done in a waterfall fashion. Construction is one that comes to mind readily. You don’t build the roof of a house before the walls are up. BUT, you can have the roof trusses made offsite and just lifted into place when the walls are ready. Agile is about eliminating wasted time (Lean Six Sigma plays a role here). If you aren’t up to date on the processes that are transforming Project Management, you may find it hard to get a job in the not too distant future.

“PMI”, “PMP”, “PMBOK Guide” are registered marks of the Project Management Institute