The Scrum framework

Abstract

In the complex technology and business world we live in today, there is a need for flexible project management practices. In for example product development, timing plays a huge role. Companies face growing pressure in delivering products quickly to the market. This pressure can result in many uncertainties and increase the rates of failures. These uncertainties can be linked to traditional project management methods being applied, where deterministic practices are being used. Resulting in companies not being able to evolve quickly or inexpensively enough when nearing the end of the development lifecycle. The ultimate goal is to deliver great customer value, Agile practices do that by constantly seeking involvement in product development e.g. from the customer. Evaluating and validating if what is being made is meeting the set business case . This business case sets the objectives and success criteria for the project. In agile project management this validation is done more often. Most often the success or the real benefits of a project can‘t be seen until the project has been done. It can be considered an advantage for project managed with agile methods having constant validation, and close relationship with the stakeholder and that it will result in target benefits being met and higher success rate .

Scrum is an Agile project Management framework, where projects are managed in short sprints or iterations. The control or project management is moved from the traditional central scheduling to the teams itself. Where individuals closer to the actual work take charge of the decision making. With this frameworks the feedback loop between customers and developers is much shorter, the progress is visible, inspections are done constantly and adaptations done when needed. . This is especially important in complex projects where companies have to be able to adjust to changes in scope or specifications. From that perspective it can be said that the Scrum framework is the opposite to deterministic project management approaches where detailed plans are being done with the use of e.g. Gantt charts and work schedules. These traditional planning methods use a bottom-up approach where the requirements are set and from the scope the tasks are constructed. In comparison to Agile practices the planning method is based on a top-down approach .

Background

In 2001 a group of 17 people which called themselves the The Agile Alliance met and from those three days they spent together the Manifesto for Agile Software Development emerged ". It can be said that these men started an Agile movement. Where in the beginning the main focus was to improve software development. When signing the Agile Manifesto you agree to follow a couple of principles, the following three were chosen as relevant for this article: Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. (Addresses how projects are managed all the way through the life cycle); Business people and developers must work together daily throughout the project (Addresses how Stakeholder management/involvement is); Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done ". This describes well how stakeholder involvement is seen. Ken Schwaber & Jeff Sutherland were apart of the The Agile Alliance that met in 2001, however approximately 10 years prior to that they had started developing the SCRUM framework . In the book Wicked Problems, Righteous Solutions (Degrace and Stahl) Scrum was first introduced in 1990 . It was then in 2009 when Agile project management methods were flourishing, more organisation were using the Agile processes than the waterfall processes. From those Agile processes the majority was using the Scrum framework or 84%. In 2009 Ken Schwaber created an organisation Scrum.org and opened up the website: [www.scrum.org], reaching a broader audience and providing access to materials and courses. Ken Schwaber and Jeff Sutherland published the Scrum Guide in 2010 .

The Scrum Team

The Scrum Team has three roles: The ScrumMaster, Product Owner and the Developers (The Team). It should be mentioned that even though one role is called Developers it does not mean that the Scrum framework is only meant for Software development. It was first developed for that purpose however now used worldwide within various organisations.

• The Product Owner represents the customers of the project. The Product Owner is in charge of making a plan that meets their vision and needs. That is done by setting up a Product Backlog, the Backlog contains both functional and nonfunctional requirements that have to be met to reach the goal or vision. This Backlog gets then prioritised, making sure that the Scrum teams starts with the main functionalities. With this prioritisation of functionalities a proposed release plan can be set. It is therefore the role of the Product Owner to priorities and decide what will be done during the sprint. This is then presented to the team during a Sprint planning meeting . The Product Owner manages the Backlog, makes sure that the backlog is well organised and the content visible. He is also the only person that can make decisions on adjusting/changing something in the backlog .

• ScrumMaster makes sure that everyone within the Scrum team knows the principles of Scrum and makes sure that everyone follows them. Another key role of the ScrumMaster is to remove any obstacles that might come their way, ensuring that the team can complete their work. The ScrumMaster is a role that is often filled by a project manager, however the ScrumMaster should not manage or define the work. The ScrumMaster should be managing the Scrum process, making sure that everyone is one the same page. As Ken Schwaber describes so well by comparing a ScrumMaster to a sheepdog, responsible for keeping the flock together and the wolves away.

• The Developers (The Team) is a cross functional team, that is self organising and self managing. Where the latter is key as Scrum teams should not be managed rather they are responsible for managing their own work and making sure that the job gets done during each sprint . It could be described as the team owns how it chooses to get the job done e.g. the functionalities. In comparison to the Product Owner that owns what should be done. The team is a relatively small, and usually consists of 5-9 people .

The Scrum Team are the individuals that are considered to be committed to the project, they can be called Pigs. However people that are interested in the project, have no accountability or responsibility are called Chickens. There is a clear distinction of authority between these two groups where the Chickens are not able to interfere without having the proper authority and the Scrum team has the full authority to do whatever it takes to make the project a success .

Application: The Scrum Events

Sprint

A sprint is where all the work takes place, often said to be the heartbeat of the Scrum Framework. The Sprints are fixed time boxes that are usually 30 days or less. When a sprint ends the next sprint takes over. The following events are linked to a sprint: Sprint planning meeting, Daily Scrum, Sprint review and Sprint retrospective meeting . In Figure 1 you can see the sequence of the Sprint events.

Figure 1: The Scrum Events, Adapted from Ken Schwaber's Agile Project Management with Scrum (Figure 1-3)

Sprint planning meeting

May last up to 8 hours when preparing a 30 day sprint . The Product Owner uses the first 4 hours to introduce to the Team the Product Backlog and the highest priorities within the next Sprint and why those are important and bring value to the project . From these priorities the Team assesses and selects what items they estimate they will be able to get done during the Sprint, here it is important to determine what their Definition of Done is. Finally the team evaluates how they will be able to get the work done. The Team is the only ones that can determine how the items from the Product Backlog are turned into Increments of value (product functionalities), (See Figure 2) By the end of the Sprint planning meeting a Sprint Goal has to be set ,.

Figure 2: The three main topics for the Sprint planning meeting, Adapted from the Scrum Guide , available at https://www.scrum.org/resources/scrum-guide

Daily scrum

Daily scrum are 15 minutes meeting held at the same time and same place each day to track the progress and how they are doing in regards to the Sprint Goal. During that meeting the Team evaluates what they have done, what they are doing and what obstacle are preventing them from getting the work done . To track the progress the Scrum Team often uses visual boards called Scrum Boards (See Figure 3) that they will update during the Daily Scrum meetings. Where the minimum categories would be: to do, doing (in process) and done. The items from the Sprint Backlog are evaluated and divided into manageable blocks, in Figure 3 called stories, the stories are then divided into subtasks . During the Daily scrum meeting the Team moves around the tasks on the visual board according to the progress. Another way of visualising how much of the work is done during each Sprint is by the use of Burndown charts. Burndown charts provides good overview of how well the work is progressing The Burndown chart in Figure 4 shows well how these graphs show the correlation between time and remaining work for one sprint that lasts from July 7th to August 3rd.

Figure 3: An Example of a Scrum Board, Adapted from the fyi blog; The Top 10 Scrum Boards you should be using by Marie Prokopets , available at https://usefyi.com/scrum-board/

Figure 4: Burndown chart to illustrate Scrum, picture by Manuelmorales (2009), distributed under a Creative Commons Attribution 3.0 Unported license, available at: https://commons.wikimedia.org/wiki/File:Burndown.png

Sprint review

Sprint review is a 4 hour meeting that takes place at the end of the Sprint. During that meeting the Team presents to the Product Owner and other relevant Stakeholders the outcome of the work that was done during that Sprint . This meeting is informal and Stakeholders can give feedback on the work done during the Sprint. During that meeting the features are explored and from that new opportunities are explored and what should be the next steps ,.

Sprint retrospective meeting

The ScrumMaster leads the Sprint Retrospective meeting, it is a 3 hour meeting where he goes over what went well during that sprint and what could be done better in the next sprint that the ScrumMaster leads and goes over what went well and what can be done better in the next sprint in respect to the Scrum process framework and practices . The meeting should ensure that the next sprint be more enjoyable, effective and increase quality . This is also an interactive meeting where not only the ScrumMaster does the talking, the team is involved and discussed their opinions on the previous Sprint, what went well and what problems they encountered that were challenging .

Scrum vs Traditional Project Management (Waterfall)

Scrum vs Traditional approaches (Waterfall)

	Scrum	Traditional (Waterfall)
Planning	Planning is done based on the sprints, therefore the plans are shorter where there are multiple deliverables	There is a detailed timeline with long term project plans .
Frequent reviews	Reviews are being done after each of the Sprints with the relevant stakeholders, therefor they are being done throughout all the project stages .
Customer involvement	High customer involvement, The customer is involved all throughout the project	Low customer involvement Customers are often only involved during the beginning and at the end of the project
Ability to adapt to change	Closely linked to the frequent reviews and customer involvement. In the Sprint review meetings where the functional increment is reviewed there is the opportunity to evaluate if any changes are needed or any new ideas come up.	Changes are more costly and harder to make as projects have been planned at the beginning.
Requirements	Throughout the project detailed requirements are being made	Before the project start detailed requirements are defined.
Product delivery	After each Sprint a product is delivered in a functional state, it is not the finished product however it shows the product functionality (increment) Done during the sprint	At the end of the timeline the product is delivered, fully functioning according to the requirements set in the beginning .

So is there a way of knowing when to apply traditional approaches like e.g. waterfall model and when to use Agile approaches like Scrum? The following bullets on reasons why Scrum or Traditional Project management methods are appropriate was adapted from the article Jason Fair wrote on Agile versus Waterfall approaches

Reasons for why Scrum would be appropriate:

• It is a complex project
• It can be possible to split employees up to teams of 5-9 people.
• The team works well together, the environments fosters collaboration, Openness and self organisation.
• The resources are available to play the roles needed. If not companies may have to invest in training in order to get the full benefits.
• Customers are willing and wanting to be an active part of the process

Reasons for why Traditional Project management would be appropriate:

• The project is of a Smaller to Medium Scale,
• Where requirements are known beforehand and they are not likely to be subject to changes
  • Where it is easy to scope and define the project .

Advantages of Scrum

It has been said that with the use of Scrum companies have a faster way to the market. One reason could be that the Customer might be happy with the product sooner than with the traditional approached, as the customer can realise that some functionalities that they had requested in the beginning aren't as important after seeing the product functionalities already implemented. This is possible only because the customer reviews the product throughout the project, with a more traditional approach the customer would be reviewing the product at the end of the timeline. Another reason could be that the teams have to deliver increments frequently, meaning that there is better support and more pressure on deliveries. In 2008 the QSM Associates concluded in their report "Agile Impact Report, Proven Performance Metrics from the Agile Enterprise" that projects managed with the Agile approach were 37 % faster at delivering their products to the market and 16% more productive .

The customer is heavily involved throughout the project validating the functionalities of the product, this can increase the chances of the customer being satisfied with the end product. For many companies the customer satisfaction is how they measure their project success. Therefore this close relationship between the ScrumTeam and the customers can increases the possibility of meeting the target benefits.

When working with complex projects there is a higher risk of uncertainties and risks. With the use of frequent reviews that the agile approaches uses then it is more easy to identify and manage risks. By reviewing each Increment the risks for each sprint can be identified, analyzed and managed. The other aspect is that you have a good overview of the job ahead with the overview of the backlog, with this knowledge it is easier to priorities the progresses according the the risk exposure .

Disadvantages of Scrum

Some have concluded that agile methodology does not work at scale, and that the small team sizes are a constraint. However there are ways of scaling with the use of Scrum-of-Scrums, and Ken Schwaber also introduces ways of scaling Scrum with examples in his book Agile Project Management with Scrum. Another approach that could be interesting to look at in this perspective is SAFe (link to SAFe).

Team members have to be cooperative, self organising and willing to follow the Scrum framework. There are frequent meetings so the team members have to be willing to engage. A problem could arise when a team member decides to quit during the project as each member of the team is very valuable to get the functions done. However as the sprints are maximum 30 days than it should be possible to find a new member filling that gap.

Annotated bibliography

Schwaber, K. (2004). Agile Project Management with Scrum (Developer Best Practices) (1st ed.). Microsoft Press: This book is written by one of the founders of Scrum Ken Schwaber. This book provides you with a good overview of the Scrum framework, The Scrum roles and Scrum Events. Ken also introduces good cases that have both been successful and failed, and provides good recommendations. This book is well structured and the appendixes are very helpful e.g. the Definition table.

Schwaber, K & Sutherland, J (November 2020) The Scrum Guide; The Definitive Guide to Scrum: The Rules of the Game: This book provides good understanding of Scrum. The guide is short and very on point, therefore easy to read.

Sliger, M. (2011). Agile project management with Scrum. Paper presented at PMI® Global Congress 2011—North America, Dallas, TX. Newtown Square, PA: Project Management Institute: This is a short article that gives good overview of the Scrum framework, especially the application. The article has good figures explaining the Scrum Process very well as well as introducing the relevant tools for Scrum like e.g. Scrum Board and Burndown charts. Furthermore it provides good examples as well as comparison between Scrum and more traditional approaches.