Have you ever spent long hours working on a project only to deliver a product that was never used? Have you ever worked on a project where you spent more time preparing, planning, and proposing than actually getting work done? If so, this could be a consequence of following the traditional waterfall approach to project management (Figure 1). Successful start-up and established software development companies (e.g., Amazon, Adobe, Apple, Google, and Microsoft, etc.) have moved away from this approach and use a project management method known as Scrum. The purpose of this article is to give an overview of the Scrum methodology with the goal of understanding the process, so that you can implement Scrum and improve your productivity and team’s success. The majority of the material in this article comes from the book, “SCRUM The Art of Doing Twice the Work in Half the Time” cowritten by Scrum’s co-founder, Jeff Sutherland.
.svg)
Figure 1: The waterfall method, sometimes referred to as the traditional method, starts by building the business requirements, coming up with the technical design or proposal, building and testing the product or conducting the research, and finally delivering the product or research findings to the customer.
Whether you work on a team, lead teams, or are at the executive level, the Scrum methodology could be a game changer. Scrum is built on the concept of continual improvement, and follows a Plan-Do-Check-Act (PDCA) Cycle (Figure 2). Continual improvement methods are superior to traditional methods (e.g., the waterfall method in Figure 1) because the actions the team takes can evolve as circumstances evolve. For example, with the waterfall method, it can take months or even years to build and deliver a product. Given the long development time, the product may no longer meet the customer’s expectations or changing requirements. To quote the famous military fighter pilot John Boyd, “He who can handle the quickest rate of change survives,” which is even more relevant today as technology keeps changing at a rapid rate.
Figure 2: Plan-Do-Check-Act (PDCA) Cycle.
The Scrum project management methodology focuses on doing the 20% of the effort that will give 80% of the value first. This approach is directly related to Pareto’s 80/20 Rule: 80% of the value comes form 20% of the effort. At the heart of Scrum is the idea of checking in regularly to make sure the project is on track, and continuously improving to do things more efficiently. Here, efficiency refers to better in terms of quality and faster in terms of time.
The name “scrum” comes from rugby, and refers to the way a rugby team works together to move the ball down the field. In order to have a successful scrum, the team must be in careful alignment, have a clear goal, and a purpose that goes beyond any one individual (i.e., the team does not care who scores the points, just that the team scores the points and wins the game). The best Scrum Teams move fluidly, in unison, sensing and knowing where their teammates are located at all times, and what they are about to do. Picture a flock of birds or a school of fish that can effortlessly maneuver around an obstacle without running into each other, maintaining their spacing, and reforming their formation with what looks like little effort.
The Scrum methodology was born in the 1990s, out of the Agile Philosophy. The Agile Philosophy emphasizes people over processes, products that work over documentation, collaboration over negotiation, and responding to change over following a plan. Scrum, in this sense, is a team methodology for achieving or living the Agile Philosophy. Scrum aligns a team with a common purpose, gets the team to see the end product through the eyes of the customer, strips away all titles and roles where one person and their goals are more important than the teams, and promotes a culture of delivering finite, incremental, and demonstrable products along the way.
In this article, I focus on the steps, or a recipe, for implementing Scrum as outlined in the Appendix of Sutherland’s book. These steps can be summarized into three main components and follow the PDCA Cycle: (1) Forming a team, (2) Creating a Backlog or Plan, and (3) Doing the work, which is called a Sprint. The main and key elements to scrum are outlined in Figure 3, which also serves as on outline for the rest of the article.
Figure 3: A Recipe for implementing Scrum, highlighting the similarity to the Plan-Do-Check-Act (PDCA) Cycle.
Form a Team: The Actors in the Scrum Story
There are three main roles in Scrum: The Product Owner, Scrum Team member, and Scrum Master. The Product Owner (1a) is the one who has the vision, and decides what the end product should be. It is their job to weigh the risks and rewards, to figure out what is possible, and to be deeply connected with the customer. The Scrum Team (1b) is made up of the people that will be doing the work. The team needs to have the all the skills to turn the vision into reality. The Scrum Master (1c), who could also be called the Scrum Coach, leads the team through the Scrum process to eliminate waste (i.e., anything that is slowing the team down). Some common forms of waste include: waste through unreasonableness (e.g., setting absurd expectations and overburdening the team), waste through inconsistency, waste through outcomes (e.g., giving people things to do to keep them busy rather than contributing to the goal), and emotional waste (i.e., the waste generated by unstable team member(s) that undermine the team’s ability to get things done).
In terms of team dynamics, a Scrum Team typically has between 3-9 team members. Teams should not have more than 9 people, as teams greater than 9 have a decline in productivity. This last point may go against conventional wisdom and intuition (i.e., the more resources you can throw at a problem the better), but the idea behind the Scrum Team is that they should operate as a single unit. When there are more than 9 people on the team it is physically and mentally challenging to keep up with all of these relationships.
The last point to make about the Scrum Team is that the project leaders (this includes the Product Owner and Scrum Master) should be transparent (i.e., everyone should have all relevant information at their disposal). In addition, Scrum Teams should have autonomy (i.e., freedom to choose how to get things done), mastery (i.e., a challenging problem that involves learning new skills and sharpening existing skills), and purpose (i.e., a purpose greater than oneself). These points should not be taken lightly, as these elements are key to workplace motivation and happiness (see Drive by Daniel Pink for more on this subject). When people are happy they make smarter decisions, are more creative and productive, and less likely to leave their job.
Create a Backlog: The Plan
Create and Prioritize a Backlog
With the team in place, the next step is to create and prioritize the Backlog (2a). The Backlog is a high-level list of all the actions (e.g., features to be developed in a software development framework) that need to be completed to turn the vision into a reality. The Backlog is essentially a road map that is created and evolves over the lifetime of the project; it contains everything that could possibly be done. It is the Product Owner’s responsibility to create and prioritize the Backlog. However, the Product Owner must consult with both the customer and the Scrum Team to make sure that Backlog is properly prioritized and realistic. When prioritizing the backlog, it is important to figure out how to deliver value as quickly as possible (i.e., figure out the 20% of the effort that will give the most value and deliver that first).
Keep in mind that the first backlog and prioritization is just your best guess at that time, and will most certainly be wrong. In fact, at the beginning of any project trying to estimate the project scope with any method is difficult. In the majority of cases, it is not until we get into a project that we get a better sense of how much time it is going to take to complete the project. Get the prioritization done quickly so that the team can begin doing. The beauty of Scrum is that it follows the PCDA Cycle of continual improvement; there will be time to redirect and reprioritize later.
Refine and Estimate the Backlog
Once the backlog exists, it is critical that those who are going to be doing the work (i.e., the Scrum Team) get together to refine and estimate the difficulty of each Backlog item (2b). Backlog items must be doable, realistic, and demonstrable. They should be clearly defined and small enough so that the team can complete the task in a reasonable amount of time. In addition, the team must know when the task is done, which means they need to produce something that is demonstrable. In many cases the Backlog items will be too broad and will need to be refined. For example, the following Backlog item is too broad, “As a customer I want the world’s biggest book store so that I can buy any book at any time.” In order to carry out this task, the team will need to refine and break down the item into smaller more manageable pieces such as, “As a customer, I want to be able to browse books by genre, so that I can find the type of books I like.” The team knows they are done with this task when they are able to demonstrate and show the team how a user can use their software tool to browse books by genre.
In addition to refining each backlog item into small manageable pieces, the Scrum Team also estimates the difficulty of each task, which is essential to the feedback loop and described later in more detail. Most people are horrible at estimating the amount of time it takes to get things done, so rather than estimating the amount of time to get a task done, the Scrum methodology estimates the difficulty of each task in a qualitative way. This is commonly done by estimating the relative size (i.e., Small, Medium, Large, or Extra-Large), or by using the Fibonacci series (i.e., 1, 2, 3, 5, 8, 13, 21, etc.).
The process of estimating the difficulty of each item on the Backlog is accomplished during a Planning Poker Meeting. This is called a “poker” meeting, because this task is efficiently carried out if each team member has a deck of cards that has either the difficulty sizes or Fibonacci numbers on them. Each Scrum team member independently estimates the level of difficulty by selecting the appropriate card, and then all team members flip over the card at the same time so that one person’s estimate does not affect others. If there is inconsistency among the team, the team members that picked the extremes (i.e., the high and low difficulties), explain why they made their choices, and then everyone makes another estimate. Once the estimates are close, either the mean or median estimate is assigned to that task. The team repeats this process until all the tasks on the Backlog have an estimate of difficulty. Just as the first backlog and prioritization is likely to be wrong, estimating the difficult of each task will be nebulous as well, until the team starts working and gains some experience on how quickly they can get things done. So again, the idea is to get the refining and estimating done quickly so that the team can begin doing or “Sprinting.”
Sprint: PDCA & Repeat
Plan the Sprint
The next step in the process is to have a Sprint Planning meeting (3a). This, in a sense, is a mini kickoff meeting for the work that will be done within the next N weeks, where N typically ranges between 1-4 weeks. The entire team, including the Product Owner, looks at the Backlog — the prioritized list of actions with accompanying estimates of difficulty — and decides what they can realistically accomplish over the next Sprint time period. After the team has a few Sprints under their belt, it is then possible to calculate the teams Velocity (i.e., the task difficulty per time), which should make estimating the amount of work that can be done over subsequent Sprints more realistic.
The Sprint Planning meeting also provides an opportunity for the Product Owner to articulate how this Sprint’s goals fit into the overall vision. A successful Sprint Planning meeting is one in which everyone on the team has a clear understanding of what they need to accomplish over the Sprint time period. Once the team has made the commitment to the tasks, these tasks are fixed and should not be changed or modified. New ideas, features, and tangents, which are naturally generated as the team starts working, should be sent to the Product Owner so that they can be prioritized and put on the Backlog.
Do the Work: Make the Work Visible
The next step in the process is to do the work (3b.i) transparently. This is often done with a Scrum Board (Figure 4). Scrum Boards can be quite intricate, but at the basic level contain three columns labeled: To Do, Doing, and Done. For teams working in the same room or office, this can easily be accomplished by putting sticky notes on a board, though in recent years a number of electronic Scrum or Kanban style boards have emerged (e.g., Trello, Asana, etc.). Another useful visualization tool is the Burndown Chart, which tracks overall progress over the length of the Sprint. Visualization tools provide immediate feedback and a sense of accomplishment, which are also important ingredients to creating a happy workforce.
Figure 4: A Simple Scrum Board.
Do the Work: Meet Regularly – The Scrum Meeting
A key component of doing the work in a Scrum framework is the Scrum Meeting (3b.ii). In a traditional Scrum framework, this meeting is 15 minutes and occurs every day at the same time. Though, it is this author’s experience that meeting weekly or biweekly may be appropriate depending upon the project. The purpose of this short meeting is to make sure that the team is transparent, making progress, and not stuck. This meeting is sometimes referred to as the “Daily Stand-up,” as having everyone stand-up is a good way to ensure that the meeting is short and to the point. During a Scrum Meeting each team member should be prepared to succinctly answer the following three questions: 1) What did you accomplish since the last meeting to help the team finish the Sprint? 2) What will you be working on next to help the team finish the Sprint? 3) Are there any obstacles, impediments, or road-blocks in your way that are keeping you or the team from achieving the Sprint goal?
Asking these three questions is an efficient way to get the entire team up to speed on 1) what has been accomplished, 2) what everyone is working on, and 3) if there are any issues. If the Scrum Meeting is done right, these questions spark conversations that allow other teammates to give feedback and suggestions (e.g., you are working on X today, I did that a while back and you might want to look at my code, or beware of Y). Also, by asking whether anyone is stuck, helps with making sure that people do not stay stuck for too long. Many times other team members have run into the same problem and will have suggestions for helping the person get unstuck.
In regards to the Scrum Meeting, the Scrum Master has three roles. These include facilitating the meeting, giving the team autonomy, and removing any road-blocks or impediments. As the facilitator, the Scrum Master makes sure that the team does not go down rabbit-holes or tangents, and keeps the meeting to the strict 15-minute time limit. If there is an issue that needs to be discussed further, the relevant team members and any outside people should follow-up offline (i.e., at some time other than the stand-up meeting). This ensures that the process is not wasting people’s time as in many cases the entire team is not needed to work out the issue. The Scrum Master is also responsible for giving the team autonomy. This explicitly means that he/she does NOT make assignments and that team members are given the freedom to choose how they accomplish the work. Lastly, it is the Scrum Master’s job to facilitate the removal of road-blocks. This could be as simple as making a phone call or sending an email to request data, or as complicated as working with IT on security issues and policies.
Check/Review your Progress: The Sprint Retrospective
At the end of the Sprint, the team has a Sprint Retrospective (3c) to talk about what went right, what can be made better in the next Sprint, and to demonstrate what the team has accomplished. In the PDCA Cycle, this is the “Check.” This meeting requires radical candor – honest feedback in a caring way – and a psychologically safe environment. The focus should be on improving the process rather than singling out individuals. Some of the questions that should be answered during this meeting include: “Why did things happen this way?”, “Why did we miss that?”, and “What could we do to make things more efficient (i.e., better quality and faster) in the next Sprint?”. The team should celebrate victories, come up with solutions to inefficiencies, and act on those solutions.
Act: Make Changes and Repeat the Process
Another component of acting on the solutions, is to begin the Scrum process again (3d). In most cases the process will start right at planning the next Sprint (3a); however, this quick pause in the workflow allows for a new team (1) to be formed if necessary, the Backlog to be modified and reprioritized (2) if necessary, and for the team to think about the next 20% effort that will give 80% of the value. In theory and over time, a Scrum team delivers more value because they keep reprioritizing and changing as the product and customer expectations and feedback evolves.
Concluding Remarks
In this article, I presented a brief overview of Scrum and a recipe for implementing Scrum (Figure 3). Scrum is an adaptive project management framework that follows the PDCA Cycle, which allows projects to evolve as customer’s expectations and requirements evolve. Scrum provides a powerful alternative to traditional waterfall-style project management, as it is better suited for our modern world that is changing at a rapid rate.
Since reading about Scrum a few months ago, I have started implementing aspects of the Scrum methodology into several work and personal projects, and am already seeing the benefits. Our teams are more aware of what everyone is doing, and we have avoided some pitfalls and road-blocks that may not have surfaced as early on in the project without the Scrum Meeting questions. We have also added an additional question to our Scrum Meeting Questions, “Do you have any items to add to the Backlog?” which has helped us capture ideas. But, enough about me. I am more interested in knowing what you think. Please leave some comments below or shoot me an email to let me know what you think of this article? Do you plan to try Scrum or have any hesitations about implementing Scrum? If you already use Scrum, what aspects have worked or not worked for you?
Lastly, I have a feeling that many of you are in the same boat as me: You are not a software developer, but are interested in adapting Scrum into a different project environment. There are, likely, aspects of Scrum that may work well for software development, but will need to adapted or modified in order to successfully implement the method into a different domain. Stand by for a future article on Adapting Scrum for Research Projects. Once this article is finished I will put a link here. Thank you for your time, and a special thanks to my editorial staff and those who have given feedback!
live-learn-lead 