Enrollment for the April 16 live virtual mini-workshop Creative vs Reactive Leadership is open . GET THE DETAILS
Those newly introduced to the Scrum framework often have the same first question: What’s the difference between Scrum and traditional project management? Most people are familiar with the basics of traditional project management, so the question is a great place to start for understanding Scrum and its benefits.
Traditional project management starts with upfront planning of all the work required to deliver the end desired result. Once we gather all the likely requirements and analyze what tasks to undertake to deliver the project, a project manager distributes those tasks to those with the specialized skills to do the work. Next comes an integration and testing phase where we bring all the completed work together to see if we achieved our desired outcomes.
Common metrics in traditional project management include things like monitoring the progress of activities and milestones achieved (e.g. design sign-off, percentage of tasks completed, actual hours versus remaining hours). Metrics often focus on the plan itself rather than tangible outcomes and direct indicators of value.
In Scrum, we start by gathering information about the desired outcomes (the value we plan to create in the product). Our team identifies what is likely to achieve the outcome and then begins building it iteratively and incrementally in short periods called Sprints that never surpass a month. This product Increment provides usable value. The Scrum framework enables us to know if what we’ve produced is on the right track (validation). If it’s not, we can alter our approach based on that information. We also have the option of releasing value to customers earlier to start getting a return on the investment.
So, within each Sprint, we’ve completed analysis, solution design, the build, integration, and quality assurance activities for a small piece of scope. We don’t do as much planning upfront because we want to remain flexible and learn from what we produce in each Sprint. This validation, learning and adaptation cycle is an empirical approach. Another of its benefits is guarding against potential waste by planning just enough. We often use the phrase “make decisions at the last responsible moment.”
The central metric in Scrum is whether we’ve delivered usable value at the end of each Sprint.
Traditional project management teams are usually organized by specialization. We might have independent analysis, development, testing, and quality assurance teams. In a linear fashion, one team hands-off the work to the next as tasks are completed.
Project managers assign tasks and monitor progress. Although these independent teams might collaborate and meet for a status update sometimes, it’s more often the case that they operate in isolation from each other and only see how their work comes together at the end of the project. Because teams don’t have visibility into the tangible progress of their work or much autonomy, they rely on detailed specifications that tell them what to do and how to do it.
Scrum Teams are cross-functional, meaning that all the skills required to produce the product are represented on the team. We’ve empowered team members to self-organize and figure out what work to do and how best to do it to meet desired outcomes. The team determines the quality standards required to call an increment of work completed (Definition of Done). Rather than individual team members owning work items, the Scrum Team as a whole is accountable. We can clearly see progress and emerging issues because everyone collaborates towards a shared goal and is involved in inspecting and adapting their work at least daily throughout each Sprint.
In traditional project management, making changes is more difficult and costly. We’ve based our intensive upfront planning on many assumptions and early decisions. Because we complete so much work in silos before integrating it into a final piece, any new ideas or emerging needs are difficult (i.e. more expensive) to accommodate because they often require a lot of re-work. We may not realize that our original understanding of the customer’s needs was inaccurate until we engage at the end for the “big reveal.”
Scrum is built to accommodate change and uncertainty. Short iterations of work delivering a usable product gives stakeholders, including the customers, many opportunities to see how the work is progressing and if it’s meeting their needs.
Consider the analogy of using GPS to navigate a road trip. As we’re driving, we frequently check to see where we are and where we need to go next. When the technology warns us of a traffic jam or road closure, we can reposition to find a better route.
Traditional project management carries a lot of risk because of the long interval before delivering value to the customer—or even having a product in a usable state. We can create all the risk management plans we want, but until we deliver and prove what we’ve delivered achieves the expected outcomes, it’s a high-stakes gamble.
In Scrum, we recognize that the only way to reduce our risk is through delivery and validation. Also, because the team organizes its work as it progresses, we can choose to learn about the riskier aspects of our work sooner. Risk can come in various forms. We might be working with new or unfamiliar technology, so we might order a smaller piece of work first to help us learn how best to use the technology (or pivot to a different one). Perhaps it’s a business risk we’re navigating. We might not be sure what we are building has a large enough market. Delivering a piece of product sooner allows us to validate our assumptions about the business opportunity sooner.
The Project Management Institute (PMI) defines a project as a temporary endeavor undertaken to achieve a unique result. So, a project has a start and end, and we’re not producing the same thing over and over again, such as building widgets on an assembly line.
Typically, a single project impacts one or multiple products, and multiple projects can impact a single product. The project is temporary, and the product lives on delivering value.
Scrum is a framework that helps people address complex problems creatively and productively, delivering products of the highest value possible. The Scrum Guide uses the word product throughout to keep the focus where it matters—delivering value to the customer. The project aspect of the work is temporary, whereas the product it generates lives on to create value. You can think of a Sprint as a project or a series of Sprints growing a product iteratively to reach project goals. The two concepts are compatible, and project managers do work effectively with Scrum Teams in some organizations. What creates conflict is how organizations incentivize and measure using a “project mindset” over a “product mindset.”
Products are vehicles for delivering value. They might be physical objects like a smartphone or a piece of software such as an app. Services can also be products and expand beyond the boundaries of a project. Examples of service products are marketing, financial planning, or human resources.
The Scrum framework is built for work in complex and uncertain environments. It has many benefits over traditional project management.
Taking the time to explain how and why Scrum differs from traditional project management when introducing the framework can help organizations and teams embrace a value-driven empirical approach to their work and tap into the business benefits of agility.
You can learn more about Scrum and the Scrum Master and Product Owner accountabilities by taking the Professional Scrum Master (PSM) or Professional Scrum Product Owner course. Get on the waitlist for an upcoming public class or contact me about private training.
