PDF Summary:Scrum, by Jeff Sutherland

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. In Scrum: The Art of Doing Twice the Work in Half the Time, Sutherland details the Scrum framework, a more effective way of developing products.

In this guide, we’ll show you how Scrum works and why it’s used by some of the most successful businesses across the world. We’ll demonstrate how to implement the Scrum framework and how it leads to a company that is happier, more productive, and more efficient at every level. Along the way, we’ll examine advice from other business experts on efficiency, productivity, teamwork, and other management strategies to see how Sutherland’s theories stack up.

(continued)...

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:

1. How the Sprint will bring value. The product manager begins by proposing how the product will increase in value during the upcoming Sprint.
2. 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.
3. 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:

• Identify your roles

• Identify one or two goals for each role

• Assign a day for each goal

• Schedule time for enriching activities

• Build in time for the unexpected

• 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:

1. What they accomplished yesterday.
2. What they will accomplish today.
3. 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