Comparing and Contrasting Scrum to Traditional Project Management
By Kevin Thompson, PhD
Comparing and Contrasting Scrum to Traditional Project Management
Scrum as Project Management
Experienced project managers, trained in the formal practice of project management, can be forgiven for feeling that they have entered the Twilight Zone on first encountering Scrum. While Scrum is a “process framework,” optimized for managing software projects, almost nothing about it seems familiar to someone with a PMP certification. And yet, if Scrum is about project management, its concepts should make sense to “classic” project managers. How can we resolve this paradox?
Scrum Revealed
The apparent discrepancy between Scrum concepts and standard project management concepts is due partly to unfamiliar terminology, and partly to unfamiliar tradeoffs. Let’s look first at the terminology.
Terminology
The terminology of Scrum reflects the practice of working in short, fixed-length cycles called Sprints, a set of which produces a Release of the product. With this understanding, we can translate Scrum terms into language more familiar to project managers:
The correspondence is straightforward. The burndown chart, for example, is just the graph of remaining planned work versus time, which should trend down to zero on the last day of the Sprint. The Sprint Backlog is the set of requirements (“Stories,” in Scrum) planned for implementation in a Sprint.
PM Term = Scrum Term
Schedule = Sprint (or Release)
Scope = Sprint Backlog
Work Breakdown Structure = Task Breakdown
Productivity = Velocity
Estimate to Complete = Burndown Chart
Tradeoffs
The key to understanding Scrum is to understand what success means for a software project, since the definition of success drives the process.
Project managers are familiar with the “iron triangle” of scope, schedule, and cost. For any project, changes to any of these affect the others. For example, if the scope (or effort needed to achieve it) was underestimated, cost and schedule may have to increase to achieve the scope.
The traditional definition of success requires implementing the planned scope, on schedule, and on budget. When this isn’t possible, the next best thing is to trade off, perhaps extending schedule, adding resources (cost), or reducing scope. In most cases, however, achieving the specified scope, or something close to it, is the most significant part of the definition of success for the project.
Software is different. Unlike houses, software products evolve incrementally, and modest increments of functionality can provide significant new value to customers. Moreover, customer needs can change rapidly, as some of today’s expectations turn out to be less important in six months than other needs that materialize three months out.
The definition of success for most software projects is not to deliver a fixed scope in six months, but to provide desired features quickly in response to urgent (and changing) customer needs. Responsiveness trumps scope as the most significant element of success.
The need to optimize responsiveness drives us to an agile concept of project management, characterized in Scrum by
- Enable quick delivery of urgent customer needs
- Allow frequent course corrections in response to changing customer needs
- Short cycles (Sprints)
- Fixed schedules (uniform length for Sprints)
- Guarantee reliable scheduling of release-quality code
- Completion of features in priority order within each Sprint
- Guarantees top-priority features will be completed even if actual effort for planned features exceeds estimates significantly
Scrum trades off between scope and schedule by freezing schedule and adjusting scope as necessary. The reason we do not fix scope is because effort estimates for new-feature development have consistently proven unreliable in the software industry, and rather than fight the losing battle for more accuracy, we optimize for what we can predict (schedule, which helps in planning delivery dates), rather than what we cannot (the delivered scope).
Conclusion
The apparent departure of Scrum projects from standard project-management concepts turns out to be an illusion. In fact, Scrum processes are tightly-choreographed and involve careful planning, as any successful project does. The illusion of otherness arises from the unfamiliar terminology, and an unfamiliar tradeoff of scope versus schedule. In the end, an effective Scrum project is indeed following sound project-management practices.
About the Author
Kevin Thompson, Ph.D., is a Certified Scrum Practitioner and Project Management Professional, and publisher of the Deep Scrum weblog. His Scrum in Practice workshop through Cprime (www.cprime.com/learning) trains teams, Program Managers, and PMO personnel on the nuts-and-bolts of how to implement Scrum for software development.
Other Frequently Viewed Articles
Agile Software Development with Scrum FAQ: Learn about Agile Software Development, Scrum, Stories, Roles and More…
Introduction to Scrum: Benefits and Practices to Agile Software Development with Scrum.
Scrum as Project Management: Comparing and Contrasting Agile Development Scrum from Traditional Project Management Methodologies.
Agile Development & Scrum Meets the PMP: Agile Development and How it Compares and Contrasts to the PMI’s Methodology.
Daily Scrums in a Distributed World: Formal Collaboration to Reduce Overhead.
Integration of Waterfall and Agile Development: Tips for integrating Waterfall and Agile Development Methodologies.
