I’ve often had project managers ask me which certification they should pursue, the Agile Alliance’s Certified Scrum Master or the Project Management Institute’s Project Management Professional. The short answer is both, but I thought it was worth explaining why.
PMI is focused on traditional (or waterfall) project management. This approach plans the entire project at the beginning, which means you need to think carefully about the process. Because of this, the approach is focused heavily on detailing the different aspects of project management, including how to manage the project as a whole, but also managing time, scope, resources, costs, quality, communications, risk, procurement, and stakeholders.
Projects are complex and this approach helps individuals understand that complexity. But the traditional approach has some large shortcomings. All of the details have to be defined up front. This either takes a tremendous amount of time, or leaves out a lot of the needed details. It also forces the end users to define what they need before they’ve seen what can be done. Often this means that once they see the end product, they have a much better idea of what would be really useful. While this approach feels like there is a lot of certainty (since it produces detailed project plans that tell you what time, what day, and how long people will be working on items months from now), the truth is that there is a lot of estimating, and the farther out the estimates go, the harder it is to be accurate.
Scrum does an excellent job of helping to fill in many of these blanks. While you do need to have a product vision at the beginning, rather than planning all the details, Scrum focuses on breaking the project into 1-4 week iterations (called Sprints), getting a rough idea of how many Sprints are needed, and then focusing on detailed planning for each Sprint. Instead of a Project Manager who drives the project, there is a Scrum Master focused on making the team more effective (and moving responsibility down to the team). Work is planned at the beginning of each iteration, and throughout the iteration, the team has a short meeting daily (less than 15 minutes) to talk about how the work is progressing. At the end of the iteration, the team presents results to stakeholders and has a retrospective to think about what to improve. Since there is value delivered in each iteration, if a project is cancelled after a given number, the company still gets value from the effort.
There are so many advantages to this approach. Planning for 1-4 weeks is a lot easier than trying to plan for a 3 to 12 month project. It helps moves individuals from a group of people working on similar items (led by a project manager) to an actual team who own the results. Frequent feedbacks means there is constant communication with stakeholders and clear deadlines throughout when work needs to be delivered. End users can see the work and adjust what they want throughout the process.
However, Scrum came out of a world where everyone was familiar with this traditional approach. The focus was on delivering short quick wins. But some of the traditional project management topics, which will apply to any project, Scrum or traditional, aren’t covered. Scrum teams still need to think about the overall product they are delivering and what kind of dependencies there are. They need to make sure they have the right people with the right skills on the team. There are still risks that need to be reviewed.
So my argument is that if you are still a traditional project manager, go learn Scrum. There are important principles that will help you be far more productive, whatever type of project you are working on. Some projects aren’t iterable, we don’t deliver a house one room at a time, but many of the other concepts of breaking projects into smaller pieces, frequent updates, and improving team cohesion, are can be applied to any project. And if you are a Scrum Master, you should still understand traditional concepts. It will help you ask the right questions to keep the team thinking about items before they become negative surprises.
It often feels like people are arguing about whether a project should be Agile or traditional. Instead of worrying about which approach is better, we need to focus on how we can learn from both to make every project more successful.