Over the years, I have heard a lot of people refer to Scrum as an “Agile Project Management Framework.” Scrum is a way to plan scope and schedule and derive cost, but that is not where it ends as an Agile Project Management Framework. There are nine areas of the Project Management Body of Knowledge (PMBOK), which is the standard for the Project Management Institute (PMI). The nine areas of project management include:
- Integration Management
- Scope Management
- Time Management
- Cost Management
- Quality Management
- Human Resource Management
- Communications Management
- Risk Management
- Procurement Management
We will be covering those nine areas over the next few blog postings. The founders of Scrum created a new language when they created Scrum because they wanted to emphasize that it is different than traditional software development. Mapping the PMBOK to Scrum was not part of introducing Scrum. Keeping it simple has been a core Agile principle: Simplicity – the art of maximizing the amount of work not done – is essential. I believe this principle helped guide the amount of work done for introducing Scrum to give people enough to start delivering working software incrementally.
I have seen people take the “literal” stance of ignoring traditional project management principles when using Scrum. Don’t be stupid on purpose. The essence of the nine areas of PMBOK are present in Scrum – who, what, when, where, why, and how they are done is the difference. My goal with this blog is to create awareness for adapting the essence of the PMBOK into Scrum.
Although Risk Management is not the starting point in the PMBOK or traditional project management approaches, I believe it is exactly where we must begin as we discuss how project management principles are alive and well in Scrum.
Tom DeMarco and Tim Lister identify five risk areas found on most projects in their book, Waltzing with Bears:
- Intrinsic Schedule Flaw
- Specification Breakdown
- Scope Creep
- Personnel Loss
- Productivity Variance
How does Agile address these particular five areas of risk? Let’s discuss…
- Mitigating schedule flaw is the biggest risk out of the five risks in terms of its planned versus actual performance. Estimating is a guess, a forecast. It is not an exact science. Scrum provides feedback loops to mitigate invalid guesses. Teams update the release plan at the end of every sprint with the emerging information gained from their last sprint timebox. Traditional projects take an estimate early in the project and don’t look back as they trot to the finish line – even when the guess (estimate) is discovered to be wrong. Agile gives you the feedback loops to refine the plan as the project moves along through prioritizing the product backlog to deliver value sooner (based on value, not time) by looking for early release opportunities (combining value with time).
- Mitigating Specification Breakdown is resolved in agile by having a product owner to communicate the customer needs and decisions about what the product should do. Stakeholder expectations can be overwhelming for delivery teams if they don’t have a dedicated product owner to help point them toward what the customer needs. A scrum delivery team will work collaboratively with the product owner to ensure alignment between what is requested and how it can be delivered.
- Mitigating Scope Creep is part of every scrum ceremony. The product owner, and other stakeholders, will discover new things to include in the product as they see progress from the delivery team throughout the sprint. During the demo at the end of the sprint, feedback from attendees will generate new backlog items. The product owner will evaluate the new product backlog items and decide what action to take: add, delete, trade-out in priority with other product backlog items.
- Mitigating Personnel Loss on agile projects involves having self-organizing teams involved in focusing on work and problems to solve, thus resulting in higher morale. Traditional projects that focus on “death marches” to deliver the work experience with low morale and a higher risk for turnover. Working in persistent teams does not mean that you are signing a contract for life to never leave the team. There will be turnover in any team. I am saying the turnover will not be based on traditional project “death march” criteria – low morale.
- Mitigating Productivity Variation is the difference between the assumed and actual performance of the team. In agile projects, we extend this variation to include the performance of the product. Scrum delivery teams address the performance of the team at the end of every sprint as part of the sprint review. Mitigating or correcting the difference variation happens in the next sprint. If a team is failing to meet its commitment, they will look to commit to less work on the next iteration. If the product is failing to meet the customer’s needs, those issues will be corrected through the product owner’s managing of the product backlog. Teams guess on how much work they can do in their first iteration. After three or four iterations, teams establish a low confidence, medium confidence, and higher confidence velocity. Velocity – the amount of work done – for an agile team acts as an indicator that teams can use to forecast work past a single iteration and can be used to help mitigate productivity variation.
In my next post, I’ll compare risk management practices between traditional/”waterfall” project management and Scrum.
This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 United States License.