This article is an excerpt from the Shortform book guide to "Scrum" by Jeff Sutherland. Shortform has the world's best summaries and analyses of books you should be reading.
Like this article? Sign up for a free trial here .
What can you learn from Scrum by Jeff Sutherland? Why does the Scrum method work better than traditional management systems?
According to software developer and management expert Jeff Sutherland, the methods most companies use to build products are misguided and lead to inefficiency. Too much time is spent planning, too much energy is wasted on unimportant tasks, and not enough emphasis is placed on flexibility. That’s why he came up with the Scrum method.
Here’s a brief overview of Jeff Sutherland’s Scrum.
Scrum: The Art of Doing Twice the Work in Half the Time
The way the business world operates, according to software developer and management expert Jeff Sutherland, is fundamentally flawed. In Scrum, Jeff Sutherland explains the Scrum framework, which he positions as a better time-management system than the traditional top-down approach. By using the carefully structured yet open-ended Scrum framework, a company, or any project team, can become much more efficient and productive.
Jeff Sutherland is a software developer who co-created Scrum alongside fellow software developer Ken Schwaber. A former fighter pilot and Assistant Professor at the University of Colorado Medical School, Sutherland has since helped dozens of businesses implement Scrum into their development process.
What Is Scrum?
Scrum is a framework made to help people and organizations efficiently solve complex problems with creative solutions. Scrum is designed to be simple, and it’s based on a simple idea: When working on a project, check in regularly to make sure you’re heading in the right direction, and remove anything that might be slowing you down. The pillars of Scrum are incremental progress and adaptability rather than following a carefully prescribed plan. Applying the Scrum framework will help companies produce more value in less time by eliminating waste and maximizing time.
| How the Scrum Framework Remains Adaptable The Scrum framework emphasizes adaptability, and as such, the Scrum framework itself is constantly evolving along with the rapidly changing worlds of business and technology. Sutherland, along with Scrum co-creator Ken Schwaber, regularly updates the Scrum Guide, which they first wrote in 2010. Sutherland and Schwaber last updated the Scrum Guide in November 2020, and they reiterate the idea that the Scrum framework’s simplicity allows it to be adapted and used across multiple fields and domains. Furthermore, this simplicity and adaptability allow for flexibility within the framework. For example, software company LinearB offers a free software tool that helps you further increase productivity, shorten development time, and increase employee fulfillment, building on the basic Scrum framework and adjusting it to suit their specific needs. |
Scrum Versus a Traditional Management System
Within the Scrum framework, Sutherland advises that your team constantly inspect its methods and processes so that you can adapt to problems or changes in real time. This contrasts with a traditional project management style where you’d wait to finish a pre-planned stage and then review your results—by which time it’s often too late to fix issues.
(Shortform note: In general, it’s good practice to assess your work as you’re working on it. Waiting to review something until after it’s complete can waste a lot of time and energy. This can be used in your daily life as well. Instead of waiting until the end of the month or end of the quarter to review your own performance, why not do it every day? One expert recommends you write down your daily routine and go over it to determine how to better spend your time.)
Basic Scrum Framework
The basic techniques of the Scrum method that Sutherland outlines start with building an effective team. The next step is assessing and prioritizing the needed tasks, and then finally, approaching those tasks through Sprints—short, focused bursts of work.
Build and Maintain an Effective Team
In modern businesses, Sutherland insists, too much emphasis is put on individual achievements, rather than the team’s accomplishments. But he argues that the team, not individuals, is creating a product, so it’s important to focus on collective performance. This holistic approach to management, emphasizing teamwork, is a pillar of the Scrum framework.
Sutherland proposes three roles within a Scrum team:
- Product Manager
- Scrum Coach
- Developers
Product Manager
The Product Manager creates the overall vision for the product and makes sure the product is both viable and valuable. The Product Manager’s responsibilities include determining the goal of the project and what it should look like when it’s finished and creating the task list of everything that needs to be done to complete the project.
(Shortform note: In Inspired, Marty Cagan agrees with Sutherland’s basic framework of having a product manager direct the vision of the project and oversee its task list. Cagan emphasizes that the person in this role be clearly a project manager rather than a product manager—in other words, this person oversees the work and the process, not the technical details of the product itself. Although Sutherland uses the word “product” in his title for this role, he sees the role in the same way Cagan does.)
Scrum Coach
While the Product Manager is responsible for making the product valuable, the Scrum Coach is responsible for making sure the team is working as efficiently as possible. She coaches the team in the ways of Scrum and keeps the team working within the Scrum framework. The Scrum Coach does this by encouraging the team to self-organize and share knowledge and removing impediments to the team’s progress. She doesn’t assign specific tasks but instead ensures that communication is open and the team is making consistent progress.
(Shortform note: The 4 Disciplines of Execution discusses the way organizational coaches can help implement a company’s vision. An internal coach benefits an organization by providing the team with the information or support they need and training new employees or leaders in the ways of the organization.)
Developers
The Developers are responsible for completing the items from the task list. They’re the ones building the product with guidance from the Product Manager and Scrum Coach. The Developers decide how to complete the tasks within each Sprint and are responsible for executing them.
Although the Scrum Coach makes sure everyone is working within the Scrum framework, the Developers must still hold each other accountable. Because the Scrum framework gives the Developers the freedom to work as they see fit, it’s their responsibility to create consistent value within each Sprint.
(Shortform note: In Inspired, Cagan calls the team members with this role engineers. He notes that because the engineers will understand the product in more detail than the project manager will, they’ll be able to come up with creative, realistic solutions to problems. This aligns with Sutherland’s ideas for this role, in which the developers figure out how to approach the specific tasks while the Product Manager focuses on the big picture.)
Assess and Prioritize Tasks
When starting a project, Sutherland says the first step is to develop the overall vision you have for your company: what problems you’re going to solve, what you’re going to make, how you’re going to make it.
To do this, he advises that you create a task list, or what he calls a “backlog,” of all the things that need to be done to make your vision a reality. The task list should include every possible task that might be needed for the end product.
Then, with the task list complete, go through the entire list and rank each item by importance. Ask which tasks will have the biggest impact and create the most value for the customer, as well as which will be the most profitable and which will be the easiest to complete.
Once you have a clear picture of which tasks will bring the most value in the least amount of time, he advises that you simply begin working on those tasks.
In this way, the Scrum method improves on traditional project methods, which would begin by making a big roadmap for the project. The Scrum method takes a much simpler and straightforward approach by simply beginning on the most important tasks without a large, comprehensive plan.
| Covey’s Time Management Matrix In First Things First, Stephen Covey gives a framework for prioritizing tasks. The two things you should consider when choosing a task are importance and urgency. In the business sense, importance would be the amount of value a task brings to the project. Urgency deals with tasks that require immediate action. Covey suggests prioritizing importance over urgency, as unimportant but urgent tasks can be a huge waste of time. Important and urgent tasks are dangerous. You want to avoid being in the position of having to rush to finish something important. This is similar to Sutherland’s advice to tackle the most important tasks first. |
Work in Sprints
A Sprint is the core process within Scrum. Sprints are fixed lengths of time, usually one or two weeks, in which the team works on a particular task or tasks. The key values of the Scrum framework are developed and maintained inside Sprints. Sprints are where the work gets done, where value is created, and where people turn ideas into reality.
(Shortform note: Sutherland and Ken Schwaber introduced the term “Sprint” in the essay “SCRUM Development Process,” which they first presented in 1995. Since then, the idea of working in Sprints has become ubiquitous in business management circles. Jake Knapp wrote a book on Sprints in 2016. We also see it show up in news articles that claim working in sprints will “transform your productivity,” and recommend working in short bursts even in your personal life.)
Sutherland gives us four phases to a Sprint cycle.
Phase 1: Plan
At this stage you should have a prioritized task list and a Scrum team ready to begin working. The goal of this phase is to determine three things:
- How the Sprint will bring value. The product manager begins by proposing how the product will increase in value during the upcoming Sprint.
- Which tasks will be completed in the Sprint. The team then chooses which items from the task list they will complete. The tasks must be fully completed within the chosen time frame, meeting the standards for completion defined in the task list.
- How the tasks will be completed by the Developers. The last step of Sprint planning is to plan out the work needed to complete the chosen tasks. This can be done by organizing the workload into daily tasks, but those decisions are left to the Developers. The Product Manager and Scrum Coach should have no say in how the tasks are completed.
| Planning as a Habit In The 7 Habits of Highly Effective People, Stephen R. Covey gives advice on how to best prioritize your time and achieve your goals. When trying to tackle personal goals, he suggests weekly planning. Weekly planning is broad enough to allow for adjustment but narrow enough to ensure things are getting done. Covey gives a step-by-step guide to weekly planning: 1. Identify your roles 2. Identify one or two goals for each role 3. Assign a day for each goal 4. Schedule time for enriching activities 5. Build in time for the unexpected 6. Adapt the plan as needed Covey’s advice thus aligns with Sutherlands: Covey recommends planning week-by-week because it can allow for frequent adjustment, and Sutherland recommends planning Sprint-by-Sprint for the same reason, to allow for frequent adjustment as the project proceeds. |
Phase 2: Meet Daily
Sutherland recommends that during each Sprint, the Scrum Coach and Developers hold short meetings every day. He states these meetings should be held in the same place, at the same time, and they should be no longer than fifteen minutes. Consistency and simplicity are important.
During the meeting, each team member should report:
- What they accomplished yesterday.
- What they will accomplish today.
- What’s slowing them down.
This helps the team know exactly where they are in the Sprint, what needs to be done next, and where they can improve. In these daily meetings, there should be no additional tasks assigned by management. If there are any impediments to the team’s progress, it’s the responsibility of the Scrum Coach to remove them. The Daily Meetings help build communication, clarify direction, and increase efficiency.
| Use Multiple Lists to Increase Efficiency The Scrum framework gives a team a structure to the workflow: Each week or two weeks, a Sprint is completed and each day, the team meets to discuss progress. Different task lists are used for each type of check-in. Sutherland isn’t the only management expert who recommends using different task lists for different purposes: In Eat That Frog, Brian Tracy recommends four different lists to use depending on which timeframe you need to plan for: Master list: This contains everything you want to do. Any time a new idea or task comes up it’s added to the master list. Monthly list: At the end of each month, move items from your master list to your monthly list. Weekly list: Build the weekly list as you work. This way, at the end of each week you will already have your next week roughly planned out. Daily list: Take items from the weekly list and list the tasks you wish to complete that day. Check off items as they are completed. |
Phase 3: Demonstrate
After each Sprint, the team must demonstrate what they’ve produced in the Sprint. Anyone with a stake in the project or its outcome is invited to see this demonstration. Outside participants, such as customers, are encouraged to attend and give feedback. If no stakeholders or customers are able to attend, the Product Manager acts as their stand-in and attempts to view the demonstration from an outside perspective.
The idea behind the Sprint demonstration is to force Developers into making a finished, demonstrable product during each Sprint. Sutherland recommends building a prototype—something you can show the customer that actually functions even if it’s not fully fleshed out, so that you don’t waste time trying to make a perfect product but instead focus on building something that works that you can improve later.
| Prototyping In Inspired, Marty Cagan discusses the usefulness of prototypes in software development. Prototypes take less time and energy to make than a finished product, and they allow the team to flesh out ideas and see what works. Cagan gives four types of prototypes: Feasibility Prototype: A prototype used to determine if a product can actually be created. You should only build enough to ensure the team is capable of completing it. User Prototype: A user prototype is a non-functional simulation of the final product. A simpler user prototype may be a bare-bones version to help the team visualize the product. A more complex user prototype may be tested internally and externally to see how it works. Live-Data Prototype: A pared-down but functional version of the final product. A live-data prototype is used to test if a product is commercially viable by getting real data from test users. Hybrid Prototype: This is a combination of the previous three types. These are the least scalable of the four types, as they are meant to be built quickly and provide feedback. |
Phase 4: Reflect
After demonstrating the product, the team then examines the previous Sprint. The aim of the Reflection is to find ways to increase productivity and efficiency within the Sprint process. Team members should look at what went right, what went wrong, and how the team reacted to any obstacles or problems that arose. They should identify potential changes that could be made to improve the process. Then, they should decide which changes will have the biggest impact and look to implement them in the next Sprint. With each Sprint reflection, the team should be finding new ways to increase productivity.
This part of the process requires a high degree of maturity and trust, as each team member must take responsibility for their actions and look for ways to improve.
| Accountability The reflecting phase is about encouraging accountability: Whether working individually or with a team, you must hold yourself and others accountable if you wish to be successful. The Oz Principle details how to lose the victim mentality and assume responsibility for your actions. The authors lay out four steps to help practice accountability: Face the facts: You must face reality if you wish to be accountable. This includes recognizing when things around you change, making space for other people’s perceptions, and being honest about your own shortcomings. Admit your role: Acknowledge that you aren’t just a victim of circumstance and that your actions contributed to those circumstances. Once you recognize your own culpability, you can more easily find a solution. Take responsibility for solving problems: If you see a problem, help fix it. It can be easy to say “not my job” or “not my fault,” but being accountable means helping to solve the problems you see around you. Take action: Once you recognize a problem, you must stay committed to finding a solution. Don’t let any obstacles get in the way of your goal. On top of individual accountability, The Oz Principle also examines how to be accountable as a team. A team’s accountability can have a direct effect on their creativity, camaraderie, and overall performance. Here are some ways you can nurture organizational accountability: – Recognize you and your team members are interdependent – Focus on results instead of individual responsibilities – Use rewards as a motivational tool – Encourage two-way feedback – Find the underlying causes of a problem |
———End of Preview———
Like what you just read? Read the rest of the world's best book summary and analysis of Jeff Sutherland's "Scrum" at Shortform .
Here's what you'll find in our full Scrum summary :
- Why the "Waterfall Method" leads to inefficiency and wasted money
- An explanation of the Scrum method and details on how to implement it
- How to use Sprints to get more work done
