SCRUM - A Project Management Framework

Latest revision as of 18:58, 28 February 2021

By Louise Landschoff

This article will give you an overview of Scrum in its essence, relating it to the project management standards, and is thus aimed towards the reader seeking knowledge regarding Scrum as a project management framework. Since Scrum is a widely used framework, a lot of literature on the topic is to be found. If you want to know more, or already have knowledge of Scrum, you can seek inspiration in the annotated bibliography which will explain valuable sources for further reading. If you are seeking knowledge regarding pitfalls in the Scrum implementation, you can take a look at the section 'Pitfalls and Mitigations in Scrum Implementation'. In this section, you will also find suggestions of improvements to ensure a successful implementation of the Scrum Framework. This article first includes an abstract, then describes the overall idea of Scrum, followed by descriptions of the application and the framework and then pitfalls in the implementation along with mitigations. Lastly, the limitations of Scrum will be listed before the annotated bibliography is presented.

[edit] Abstract

In an ever-changing world that is getting more and more complex, the art of project management is becoming harder to control due to uncertainty and the speed in which requirements and demand change. Standard ways of planning a project, such as the Waterfall model, may not be applicable in some cases. To accommodate this issue, the adaptive project management framework, Scrum, can be used because it embraces agility and fast project deliveries. Scrum relates to the project and development life cycles in the PMI standard. Even though Scrum is applicable for both project, program and portfolio management, this article will focus solely on Scrum as a project management framework and the implementation of Scrum.

The Scrum framework was developed in the early 1990's by Ken Schwaber & Jeff Sutherland and is a framework based on empiricism and lean thinking and has its roots in software development^[1] (p.1). Today, Scrum is one of the most popular ways of becoming agile and is widely used for various projects. Benefits of utilizing the Scrum Framework to structure the development life cycles are continuous improvements, transparency, early adoption, and embracing change, which is a great advantage compared to the classic Waterfall model. The process of Scrum is to first create the product backlog and then define the sprint by creating the sprint backlog and then performing development resulting in an increment. By working incrementally, the team can learn from previous sprints to optimize the next and the product may be ready for release earlier than first anticipated. The Scrum Framework creates value in an adaptive and agile way through the Scrum values, the Scrum team, events and artifacts. The values focus on Commitment, Focus, Openness, Respect, and Courage. The team consists of the Product Owner (PO), the Scrum master (SM) and, lastly, the self-organizing Development Team (DT). Furthermore, the framework consists of events such as Sprints, Sprint Planning and Sprint Retrospective, and artifacts which are the product backlog, sprint backlog and burndown chart. Scrum has limitations by being non-applicable to 'business-as-usual' projects, constraint of physicality, potential scope creep due to an indefinite end-date etc.

[edit] Why use Scrum?

As the world evolves, change in demand and uncertainty arise. Being agile and flexible has become a precondition to survive and succeed in today's business environment^[2](p.5) compared to using the classic Waterfall model^[3](p.16). It is crucial for all kinds of businesses to be able to respond and adapt to unforeseen activities and events on the market because if not, someone else will fulfill the customers' demand. Scrum has become one of the most popluar ways of becoming agile^[3](p.15) because it is a simple framework that can be adapted and fulfilled by own needs and goals^[1](p.3). Agility is acknowledged in a few sections in the PMI standard^[4] (p. 18-19 and Appendix X3) for being one of the ways of determining the project life cycle in an adaptive manner. Even thought agile is not widely acknowledged in the PMI for now, the work towards incorporating it is underway^[5] and extending the practice of project management.

Adaptive life cycles are agile, iterative, or incremental. The detailed scope is defined and approved before the start of an iteration.
Adaptive life cycles are also referred to as agile or change-driven life cycle (The PMI standard, p19)

Agility and Scrum are strong drivers for simplicity in a complex environment especially within the project management knowledge areas; project integration management, scope management, schedule management and risk management^[4](p.23-25) to name a few. For scope and schedule management, Scrum is a strong framework because it is possible to adapt to unforeseen changes as the business environment evolves due to the iterative nature of the framework. For risk management, Scrum is usable based on, again, the iterative nature but also continuous contact to project stakeholders^[4](Appendix X3). This, together with other knowledge areas, all adds up to a strong framework for excellent integration management throughout the project life cycle. By structuring the development life cycles according to the Scrum Framework, benefits such as continuous improvements, transparency, early adoption, and embracing change are met.

Scrum theory^[1](p.3) explains how the agile framework from the 1990's is based on empiricism, which means that knowledge comes with experience and decision making should be based on what is observable and lean thinking which seeks to eliminate waste and focus on what is value-adding. The empirical pillars of Scrum are transparency, inspection and adaptation^[1](p.3). Scrum improves predictability and the act of controlling risk, which is driven by transparency in the project management process. Having high transparency also implies a need for inspection to ensure progress and identify problems during the process. The inspection process is handled during the Scrum events. Lastly, having inspections without adaptation and learning is pointless which is why the Scrum team must work empirically. Scrum is highly relevant in today's vibrating business environment because it creates a framework able to handle unpredictability and complexity in a project and makes teams able to create higher value more frequently, ultimatly resulting in higher customer satisfaction^[6].

To form the basis of an Agile approach to projects, the Agile Manifesto ^[7](p.9-14) was created. It is based on software development but is applied across industries. The Agile Manifesto is:

1. Individuals and interactions over processes and tools

2. Working software over comprehensive documentation

3. Customer collaboration over contract negotiation

4. Responding to change over following a plan

With this in mind, the application of Scrum is presented below.

[edit] Application and Implementation of Scrum

Scrum is applied as a framework for managing the project life cycle development from idea to finished product. Figure 1 provides an overview of the Scrum Framework consisting of the roles, events and artifacts. Literature on Scrum implementation in software projects incorporates further roles in the framework^[8][3](p.35-55 and p.16-18) than illustrated in Figure 1, though the figure explains how the Scrum Framework can be implemented in any project regardless of type. The figure is based on the Scrum Framework Poster from Home of Scrum^[6]. Based on this figure, the framework will be described in the following section, focusing on how to implement Scrum.

Figure 1: The Scrum Framework (own figure based on The Scrum Framework Poster from The Home of Scrum^[6])

[edit] How to implement Scrum in your project

Scrum is a simple framework that is hard to apply^[8](p.34). The following section will provide a practical guide in how to implement Scrum in your project by utilizing the Scrum Framework as described below. The implementation guide is inspired by KnowledgeHut (2019), Sutherland Ph.D, Jeff; Schwaber, Ken(2008) and M. Gannon (2013)^[9][10][11]. As no two projects are identical, the Scrum Framework will have to be adapted to every project to ensure a successful implementation. This overall guide describes all required steps to follow to implement Scrum as an Agile framework. All parts in the Scrum Framework are described in further detail below.

1. Identify a Product Owner The Product Owner should be a person able to work with several stakeholders and to formulate their wishes and needs into requirements in the Product Backlog, or, in short, act as a customer representative^[10](p.12). Strong personal-, communication- and prioritization skills are needed to successfully do the job of a Product Owner as he/she entirely owns and prioritizes the Product Backlog after business value which is vital for the progress of the project^[9].

2. Build a cross-functional Development Team The Development Team consists of up to nine people with the necessary competences and expertise (e.g. analysts, testers, designers, developers^[9]) to fulfil the desired product. They will work closely to provide a quality product. It is preferrable that the team is cross-functional and self-organizing to incentivize ownership of the project. The team member should also be able to change and adapt during the process^[11](p.7).

3. Choose a Scrum Master with the right skills The Product Owner will define why the project is necessary, the Development Team will define what should be done in order to create the desired value and the Scrum Master will define how the work should be done in order to reach the targets. Great Scrum Masters can have varying backgrounds (Project Management, Engineering etc.) but most importantly, they are not managing the team. They are simply serving the team with whatever they need, to be successful in their work^[10](p.20).

4. Build and Prioritize the Product Backlog After having set the team, the next vital step is for the Product Owner to start building the Product Backlog. The Backlog will be prioritized according to customer and business value written as User Stories. The Product Backlog will be regularly adjusted as the project progresses^[10](p.21).

5. Perform Sprint Planning Based on the Product Backlog, the User Stories ready for work will be planned for the next Sprint and placed on the Sprint Backlog managed by the Scrum Master and the Development Team. As part of the first Sprint Planning, agreements on how to work, commitments and the Product Goal will also be defined^[9]. For each Sprint, a Sprint Goal will be agreed upon in the Sprint Planning session.

6. Start working on the Sprint deliverable Start sprinting! Work towards the Sprint Goal and the Definition of Done (see later section for definition). Work according to the commitments made in the Sprint Planning.

7. Have Daily Scrum meetings Every day at the same time during the Sprint, the Scrum Master will facilitate a Daily stand up meeting where the team inspects and adapts to each other to increase transparency and remove impediments^[10](p.24).

8. Perform a Scrum Review at the end of the Sprint At the end of the Sprint, the Scrum team demos the Increment to the rest of the team and relevant stakeholders^[10](p.25). The outcome of this meeting is items (new/adjusted) or requirements to the Product Backlog.

9. Perform a Sprint Retrospective The Retrospective meeting gives the team a chance to reflect about the Sprint and on areas to improve during the next Sprint. Here, the team will inspect and adapt to perform better in the next Sprint^[11](p.4+7).

10. Refine and adapt the Product Backlog if needed and start at 5. again The Product Backlog will be prioritized and a new Sprint will start.

To dive deeper into how Scrum is implemented, the Scrum Framework will now be described.

[edit] The Scrum Framework

The Scrum Framework consists of the Scrum values, the Scrum team, events and artifacts. The Scrum team roles, events and artifacts are illustrated in figure 1 according to where in the process they adhere. The success of Scrum depends on how well the framework is followed and adapted to the individual project.

[edit] The Scrum values

The five Scrum values are: Commitment, Focus, Openness, Respect, and Courage^[1](p.4). The Scrum team is committing to the goals of the project and as they work and learn from the Scrum Framework, the values are incorporated in their way of collaborating with each other. The values define important aspects needed for the team to perform well sprint after sprint, which is based on mutual respect and the pillars of Scrum (transparency, inspection and adaption). In this way, the mindset is in place for the team to start working.

[edit] The Scrum Team

The full Scrum team consists of the Product Owner (PO), the Scrum Master (SM) and the self-organizing Development Team (DT). As a general rule, the team consists of up to 10^[1][3](p.5 and p.16) highly skilled, professional and self-managing people working in a cross-functional environment. The team will deliver value each sprint and work together towards the product goal (the future state^[1](p.11)). According to the goal and nature of the project, the composition of the team will be settled with people with the required competences.

The Product Owner (PO) The Product Owner has the overall responsibily for communicating the product goals, defining and managing the Product Backlog. The PO decides which items should be in the Product Backlog and how they should be prioritized according to business benefit and value. The Product Backlog needs to be transparent and visual for the rest of the team to understand the progress^[1](p.5-6). It is important for the PO to justify why a Backlog item is important for the team members to buy in and understand the purpose. In this way, the team invests more in the sprint. It is the teams' responsibility to find out how to reach the PO's goals for the product. Furthermore, the PO has the responsibility of communicating with internal and external stakeholders and translate their requirements into project goals if relevant^[8](p.39-42). During the project, as seen in figure 1, the PO is involved in almost the entire project; firstly in defining, prioritizing and managing the Product Backlog, secondly in communicating to the Scrum team which items that provide highest business value for the coming sprint, thirdly in reviewing the Sprint Increment and discussing the outcome with stakeholders, and lastly adapting the Product Backlog according to the Sprint Retrospective.

The Scrum Master (SM) The Scrum Master is responsible for ensuring that the Scrum rules are complied with and therefore also for the effectiveness of the team. The Scrum Master makes sure that the Development Team has understood the Scrum theory and practice^[1](p.6). It is a vital role in the Scrum team, because the SM helps out whenever there is an obstacle or an impediment preventing effective working. The SM is the servant-leader to the Development team^[1][3](p.6 and p.17) and his/her job is to keep their day free from disruptive tasks and blockings in order for them to be successful. The SM is also a facilitor of the Scrum events to make sure that the events are value-adding, not wasting valuable time and within the timeframe^[8](p.45-54). When impediments are met, the SM will be the motivator and join with encouraging language to get the morale up. All in all, the SM's most important job is to help out both the PO, the Development Team and the organization by e.g. helping the PO with the management of the Product Backlog, coaching the organization in Scrum adoption^[1](p.7), ensuring an empirical approach and removing impediments to enable the team to be successful. In figure 1, the SM is ubiquitous, meaning he/she is part of the full process. Even though the SM cannot be everywhere all the time, he/she is the person to go to, whenever a problem or a success is encountered.

The Development Team (DT) The Development Team are the ones who develop the product. The DT consists of skilled profesionals assigned according to the task and their competences. They are self-managing as a team, commit to the Sprint and take responsibility for the deliverables. Often there will be roles as quality engineer, technical writer and an architect especially for software development^[3](p.16-18). The DT will create a plan for each Sprint (Sprint Backlog) with the most important and valuable tasks to be completed, then they will define the Definition of Done (see further below), devide the work according to skill and capacity, work on the deliverables while constantly adapting their work towards the Sprint Goal and deliver an increment at the end of the Sprint. During the Sprint Retrospective, the DT will learn from the previous Sprint experiences to improve for the next one. The DT will hold each other accountable for their work and for their own responsibilities towards their own time, skill and capacity^[1](p.5). Before moving in to the first Sprint, intitial agreements need to be set. This includes team rules, working agreements and responsibilities. A team whose members are not on the same page from the beginning of a project is doomed to fail, which explains the importance of working agreements and struture^[12]. Read more about team structures in McKenna, Dave (2016) ^[8] p.55-61. This can include agreements of working time and place, team values, a code of conduct and so on. A template such as the Working Agreement Canvas created by ScrumInc.^[13] can be utilised. The benefit of creating a working agreement from the beginning is that all team members know what actions should be taken, if trouble occurs, and a unified way of working is agreed upon.

[edit] Scrum Events

The Scrum Events are the core of what makes Scrum an excellent agile framework because it creates a collective and understood rhythm for the team. The framework is based on working in iterations. After the PO has defined the scope of the project, the first sprint can begin. All other events work as a part of the Sprint, this will be described in further detail. Having figure 1 in mind during this section will be beneficial.

Sprints The Sprint is the backbone of the Scrum. The Sprint is a 2-4 week^[1][8](p.7 and p.30-31) period where ideas turn in to value by the DT, to achieve the Sprint Goal. By keeping the Sprints short, focus and engagement will not be lost, risks can be mitigated quickly and the predictability rises. The Sprint is one iteration resulting in a product increment (a minimal viable product or potentially shippable product^[8](p.30-31)). The Sprint consists of all the Scrum events described below. The Sprint starts with a Sprint Planning event that will define the Sprint Backlog based on the Sprint Goal which is derived from the Product Backlog and the PO's priorities. Once the Sprint Backlog is set, the work can begin. During the sprint, the SM hosts a Daily Scrum meeting for the DT to keep each other informed during the process. This will increase predictability, decrease risk, highten transparency and ultimatively adaptability. When the work complies with the Definition of Done (see below) an increment is born. The product Increment will be demoed to PO and stakeholders in a Sprint Review. Inputs from stakeholders will result in changes to the Product Backlog. The last event in the Sprint is the Sprint Retrospective where the DT has time to evaluate the Sprint's ups and downs and learn from them (empirical work). The learnings will be carried on to the next Sprint. The next Sprint starts immediately after the end of a previous Sprint^[1](p.7). The individual events will now be explained in further detail.

Sprint Planning The Sprint Planning is the first event of the Sprint. During the planning, three topics will be adressed: Why having this Sprint? What can be done? How will the work get done?^[1](p.8). During the first point, the PO will explain how value can be increased during the next Sprint, thus providing transparency and understanding to the team. The team will hereafter define the Sprint Goal. During the second point, the PO, SM and the DT agree on which user stories should be in the forth-coming Sprint according to the Definition of Ready (see below). The user stories that are ready will be a part of the Sprint and the purpose is for the DT to define work tasks (story points) of the user stories. The PO will act as a customer representative and answer the questions coming from the DT. One user story might be split up to 10 story points which is specific tasks to complete during the Sprint^[8](p.81-87). Lastly, the DT will create a plan on how to get the work done during the Sprint to produce the desired increment. This planning should take maximum eight hours for a one month Sprint.

Sprint Goal In each Sprint, there is a Sprint Goal. The Sprint Goal is agreed upon by the Scrum team and defines why the exact Sprint is valuable for customers. The goal must be finished before the end of the Sprint Planning session in order for all members to leave the meeting knowing what the purpose with the coming Sprint is^[1](p.11).

Definition of Ready (DoR) The Definition of Ready will be defined by the PO and applies to the user stories. When the PO is working with the Product Backlog, he/she must prioritize the user stories in the Product Backlog according to how close they are to being ready for the team to work with and substantialize. The DoR defines when a user story is ready to be added to a Sprint. DoR should be used in the same way for all user stories but can evolve as the project progresses. It is convenient to follow the INVEST scale when assessing if user stories are well defined, which mean they should be: Independent, Negotiable, Valuable, Estimable, Small and Testable^[8](p.75-77).

Definition of Done (DoD) Along with the Sprint Goal definition, the Definition of Done also needs to be defined during the Sprint Planning event. The DoD is a state of quality the increment needs to meet before it can be deemed done. This ensures transparency and that no task is being pushed ahead^[1][8](p.12 and p.32-33). If an item does not meet the DoD requirements it will go back to the Product Backlog and be revised further.

Daily Scrum The Daily Scrum (or a Scrum Meeting) is a daily stand-up meeting of a fixed duration of 15 minutes at the same time every day and its intend is to inspect the progress of the team. The meeting will ensure that communication will be promoted and any potential problems or impediments will be solved quickly. This is a chance for the team to make adjustments in the plan to be sure to reach the Sprint Goal^[1](p.9). The event is created for the Development Team and the Scrum Master will facilitate the event. The Product Owner has optional attendance. During the meeting, three questions should be answered: What did I do since the last meeting? Were there any blockages? What will I do before our next meeting?^[3](p.20-21).

Sprint Review The Scrum team demos to the relevant stakeholders what backlog items have been completed during the Sprint according to the DoD. In general, the Sprint Review is the PO's show since he/she has relations to the stakeholders and thereby further builds the relationship with them. The DT gets to showcase the features of the product if relevant. The items are inspected, adaptions towards the Product Goal will be discussed and the Product Backlog will be adjusted. If a test of e.g. a software can be presented to the stakeholders, it is of interest. The session should last at most four hours for a one month sprint^[1][8](p.9 and p.182-183).

Sprint Retrospective The last event in the Sprint is the Sprint Retrospective. In this event, the Scrum Master hosts a meeting for the Development Team to inspect and adapt to how the Sprint went. The team can raise concerns and problems if any but the meeting should be kept positive and the outcome will be two or three actions to improve during the next Sprint. When the next Sprint Retrospective is up, the actions can be revised. The team will probably talk more freely if the PO is not attending the meeting but if the relationship to the PO is good, then he/she can attend^[8](p.92-94).

[edit] Scrum Artifacts

The artifacts of Scrum indicate work or value and will increase transparency in the framework.

Product Backlog The Product Backlog is owned by the PO and it is a list of all the requirements and other related attributes from the customer that need to be fulfilled to reach the Product Goal. The Product Backlog consists of several items descending in priority and specificity. These items can be epics which are general and logical groupings in the backlog and consist of several user stories. An epic does not fit into one Sprint but may be split up and executed across several Sprints^[8](p.28). Another item on the Product Backlog can be a user story, which is some defined work that will create value for the customer^[8](p.78). A User Story can beneficially be written in the following format: "As a [name or role of the end user] I want [simple description of functionality] so that I have [business value]"^[11](p.2). It is the PO's responsibility to decide what is on the Product Backlog, to prioritize the user stories and decide which stories go in for each Sprint.

Sprint backlog The Sprint Backlog will be created by the DT during the Sprint Planning session. It is a plan for the next Sprint consisting of the Sprint Goal explaining why the Sprint is valuable, a set of items (user stories) from the Product Backlog to define what work should be done and a plan for how to reach the Increment. As a part of breaking down the user stories to story points, an hourly estimate is provided for each task. The Sprint Backlog should be highly visible to be transparent for the team to read. To accommodate structure, a Kanban board^[14] can be used as seen in figure 2 below. Here, the team members will place sticky notes on the board with tasks and move them as the work progresses from To Do to In Progress to Done or defined according to the project nature. In this way, transparency in the distribution of tasks is met. During the Sprint, as the work is inspected in the Daily Scrum meetings, adaptions and adjustments will be necessary as the team learns more details^[1](p.11). The progress of a Sprint can be visualised by a Burndown chart^[8](p.85-87) but not replace the importance of empiricism^[1](p.8). As each task is estimated in hours, it is possible for the team to see how much work has been done compared to the calculated amount. An example of a Burndown Chart can be seen in figure 3.

Figure 2: A Kanban board to keep track of work tasks in each Sprint (own figure based on Porter (2017)^[14]). Figure 3: A Burndown Chart to visualize the remaining work in the Sprint (own figure based on McKenna, Dave^[8](p.86))

Increment An Increment is a concrete piece of usable work, working together with all other Increments to create the Product Goal. The Increment should be thoroughly verified and meet the DoD before it is called done. An Increment is done whenever, meaning several Increments can be produced during one Sprint, as long as they follow the DoD^[1](p.11-12).

After having read the Scrum Framework, it is advantageous to take a look at the implementation plan once more, to fully understand its structure. Now, some of the pitfalls of the framework will be presented.

[edit] Pitfalls and their Mitigations in Scrum Implementation

Every organization that wants to implement Scrum will face difficulties at some point. Here are some common pitfalls and how to mitigate them to succeed with the Scrum implementation.

1. The Scrum Framework is extensive but does not describe every aspect of what is needed to do. The framework provides a lot of information but not all information or aspects may be relevant for all projects. It is up to the individual team member and the Scrum Master to follow the framework and infuse other necessary practices from elsewhere to succeed. The framework should not prohibit or discourage any practice, just because it is not included in the framework^[10](p.27-28). To mitigate this issue, critical thinking and speaking to the experienced Scrum Master would be an idea.

2. Time management and estimation. The team will probably have issues, especially in the beginning, with estimating how much work they can perform in a Sprint, which may cause frustration and questioning of the framework^[10][11](p.27-28 and p.6). Scrum is a relatively new way of working and will need a cultural change in the organization to fully succeed (institutionalization^[10](p.89)). To mitigate this, speaking to an experienced Scrum practioner will ignite the needed experience to become better in managing time.

3. Lack of engagement from team members or lack in performance. Getting all team members committed to the task of utilizing the Scrum Framework might impose problems with resistance, lack of understanding and lack of willingness to change^[10](p.27-28). This could be solved by improving understanding and responsibility for the practioners by providing them with training in Scrum.

To obtain an organization that ensures that the relevant processes are considered along with an efficient implementation embracing change, a mix of Capability Maturity Model Integration (CMMI) and Scrum can be utillized. For further reading see Sutherland Ph.D, Jeff; Schwaber, Ken(2008): The Scrum Papers p. 85-89.

[edit] Limitations

Scrum is extending the current practice of project management but cannot always be applicable. For projects of less complex nature, the Scrum Framework is not the obvious choice due to an extensive framework based on iterations and feedback loops, which may not be nescessary in 'straight-forward' or 'business-as-usual' projects. Jeffrey A. Livermore ^[15] explains how several factors can impact the implementation success of an agile framework as Scrum:

Training on the methodology Especially training on the methodology for the project team is highly nescessary for the success of Scrum. If all team members are on the same page and understand the framework, several problems can be mitigated.

Active management support The more active and involved management is in implementing the framework, the better the result.

Access to external resources Access to knowledge will increase the project team's ability to understand the subject to improve throughout the project. As the team is set in the beginning, valuable consultant work is excluded.

Other issues stated by Akif, R., H. Majeed (2012)^[16] include a pile-up of quality related items due to the high speed in the project execution. The need for documentation is also stated as an issue, and therefore, Scrum may not be applicable to projects with a high documentation need. Lack of training is also mentioned as an issue along with potential scope creep which may occur due to an indefinite end-date for the project.

Furthermore, a general issue in implementing Scrum in an organization is the cultural change it entails. Scrum is not just a tool to be used during a project, it is an entirely new way of working and thinking project managment, which of course needs time and effort to implement in an organization.

Most literature on Scrum implementation and Agile development is based on the software industry and projects^[5]. Where Scrum encounters limitations is in the usefullness for physical product development projects where Scrum meets constraints of physicality^[17]. Constraints of physicality means that there is a physical bound to what is managable to complete in one iteration, e.g. it is rather impossible to build a substantial part of a suspension brigde in four weeks. The difference from the software industry of clicking 'Run' on a script compared to building a part of a physical product such as a suspension bridge encumber major differences in resources, time and effort. Nevertheless, demand and uncertainty is also present in non-software industries, the need for an agile method is great. Even though Scrum may not be directly applicable for physical product development yet, the work and research is moving towards that stage^[5].

The referenced material in this article mainly includes sources explaining Scrum implementation in software development since it is where Scrum originates from and is mostly applicable. Some sources such as Ciric et al (2019) and Schmidt et al (2017) seek to go beyond the standards of agile implementation in the software industry and expand it to other industries. Along with this movement, the standards of project management is also working to include practice-driven and iterative working in the status quo and the next generation of project management practice^[18]

[edit] Annotated Bibliography

The annotated bibliography desribes in short the most relevant references for getting further knowledge regarding Scrum as an agile framework and also some limitations.

1. Sutherland Ph.D, Jeff; Schwaber, Ken(2020): The Scrum Guide. The Definitive Guide to Scrum: The Rules of the Game. Retrieved from https://www.scrumguides.org/

This is the official Scrum guide, written by the two founders of Scrum, Ken Schwaber and Jeff Sutherland. The guide is continously updated as new research becomes relevant and the latest edition from November 2020 is used. This reference is useful to gain an overview of the Scrum Framework and the definitions of each component of it. It is beneficial to first take a look at this reference, especially if you are new to Scrum, since it lays out the map for the game of Scrum. Since it only lasts fourteen pages, it is an efficient and quick way to get introduced to Scrum.

2. Sutherland Ph.D, Jeff; Schwaber, Ken(2008): The Scrum Papers: Nuts, Bolts, and Origins of an Agile Process. Retrieved from http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.108.814

A book by the co-founders of the Scrum Framework, Jeff Sutherland and Ken Schwaber that is going beyond the introductory Scrum Guide as described above. The book both gives an introduction to Scrum but quickly go in to more advanced practices and explanation to the framework. The focus is both on agile software development and the Scrum framework. Schwaber and Sutherland also includes practialities, case studies and real-world referencing to improve the reader's understandig. This reference should be visited if you have knowledge regarding Scrum in advance and seeks a further deep dive in to the full framework with all its aspects and a practical approach to Scrum.

3. The Art of Scrum (2016) How Scrum Masters Bind Dev Teams and Unleash Agility. Dave McKenna, Apress, Berkeley, CA. Retrieved from https://doi-org.proxy.findit.dtu.dk/10.1007/978-1-4842-2277-5

Dave McKenna is an experienced Scrum Master and has written this book with focus on the Scrum Master's perspective. It gives valuable and practical insights into how Scrum is applied in real life. This reference is relevant for both new users of Scrum to get a practical understanding of Scrum but also for more experienced individuals who wish to broaden their knowledge. It is written with a focus on story telling from McKenna’s own life and he provides down-to-earth examples from his everyday life. This makes it less academic to read but still provides a lot of valuable insights.

4. Schmidt, Tobias Sebastian et al (2017): AGILE DEVELOPMENT AND THE CONSTRAINTS OF PHYSICALITY: A NETWORK THEORY-BASED CAUSE-AND EFFECT ANALYSIS. In: Proceedings of the 21st International Conference on Engineering Design (ICED17), Vol. 4: Design Methods and Tools, Vancouver, Canada, 21.-25.08.2017.

This conference paper examines some of the mentioned limitations of agility being applied in other industries than the software industry. The Constraints of Physicality makes it difficult to implement agile methods in physical product development projects because of the rise in complexity. This conference paper is relevant to those who have a profound knowledge of agility and Scrum and wants to know more of where the boundaries of the framework occur. This is especially relevant to those who aims to work with agility outside the software industry.

[edit] References

1. ↑ ^{1.00 1.01 1.02 1.03 1.04 1.05 1.06 1.07 1.08 1.09 1.10 1.11 1.12 1.13 1.14 1.15 1.16 1.17 1.18 1.19 1.20 1.21} Sutherland Ph.D, Jeff; Schwaber, Ken(2020): The Scrum Guide. The Definitive Guide to Scrum: The Rules of the Game. Retrieved from https://www.scrumguides.org/
2. ↑ Baskerville, Richard L.; Mathiassen, Lars; Pries-Heje, Jan; DeGross, Janice I. (2005): Business Agility and Information Technology Diffusion IFIP TC8 WG 8.6 International Working Conference May 8–11, Atlanta, Georgia, U.S.A.
3. ↑ ^{3.0 3.1 3.2 3.3 3.4 3.5 3.6} Bibik I. (2018) Agile Scrum Deep Dive. In: How to Kill the Scrum Monster. Apress, Berkeley, CA. Retrieved from https://doi.org/10.1007/978-1-4842-3691-8_3
4. ↑ ^{4.0 4.1 4.2} Project Management Institute, Inc.. (2017). Guide to the Project Management Body of Knowledge (PMBOK® Guide) (6th Edition). Project Management Institute, Inc. (PMI). Retrieved from https://app.knovel.com/hotlink/toc/id:kpGPMBKP02/guide-project-management/guide-project-management
5. ↑ ^{5.0 5.1 5.2} Danijela Ciric, Bojan Lalic, Danijela Gracanin, Nemanja Tasic, Milan Delic, Nenad Medic (2019): Agile vs. Traditional Approach in Project Management: Strategies, Challenges and Reasons to Introduce Agile. Procedia Manufacturing, Volume 39, Pages 1407-1414, ISSN 2351-9789, https://doi.org/10.1016/j.promfg.2020.01.314. Retrieved from: https://www.sciencedirect.com/science/article/pii/S2351978920303814.
6. ↑ ^{6.0 6.1 6.2} The Home of Scrum. Retrieved from https://www.scrum.org/resources/what-is-scrum
7. ↑ Hazzan O., Dubinsky Y. (2014) The Agile Manifesto. In: Agile Anywhere. SpringerBriefs in Computer Science. Springer, Cham. https://doi-org.proxy.findit.dtu.dk/10.1007/978-3-319-10157-6_3
8. ↑ ^{8.00 8.01 8.02 8.03 8.04 8.05 8.06 8.07 8.08 8.09 8.10 8.11 8.12 8.13 8.14 8.15} McKenna, Dave (2016): The Art of Scrum. How Scrum Masters Bind Dev Teams and Unleash Agility. Apress, Berkeley, CA. Retrieved from https://doi-org.proxy.findit.dtu.dk/10.1007/978-1-4842-2277-5
9. ↑ ^{9.0 9.1 9.2 9.3} Youtube video KnowledgeHut(2019): How to implement Scrum in your team | Scrum Guide | 6 steps to get started with Scrum. Retrieved from https://www.youtube.com/watch?v=J3cMJJGNY4g&ab_channel=KnowledgeHut
10. ↑ ^{10.0 10.1 10.2 10.3 10.4 10.5 10.6 10.7 10.8 10.9} Sutherland Ph.D, Jeff; Schwaber, Ken(2008): The Scrum Papers: Nuts, Bolts, and Origins of an Agile Process. Retrieved from http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.108.814
11. ↑ ^{11.0 11.1 11.2 11.3 11.4} M. Gannon (2013): "An agile implementation of SCRUM," IEEE Aerospace Conference, Big Sky, MT, USA, pp. 1-7, doi: 10.1109/AERO.2013.6497388. URL: https://ieeexplore-ieee-org.proxy.findit.dtu.dk/stamp/stamp.jsp?tp=&arnumber=6497388&isnumber=6496810
12. ↑ Youtube video Scrum Academy (2020): The Scrum Framework explained (Scrum Academy explains Agile) | 2021 Edition | Scrum in 15 Minutes. Retrieved from https://www.youtube.com/watch?v=wxbjCSEyq2I&ab_channel=scrum-academyScrum
13. ↑ ScrumInc.(2018): Team Working Agreement Canvas. Retrieved from: https://www.scruminc.com/team-working-agreement-canvas/
14. ↑ ^{14.0 14.1} Porter, Steven (2017): A Kanban primer for Scrum Teams. Retrieved from: https://www.scrum.org/resources/blog/kanban-primer-scrum-teams
15. ↑ Livermore, Jeffrey A. (2008). Factors that Significantly Impact the Implementation of an Agile Software Development Methodology. Journal of Software, Vol. 3, No. 4. Retrieved from http://pdfs.semanticscholar.org/d517/2f869445e3d2989d1d8acba6fcee38bd2eec.pdf
16. ↑ Akif, R., H. Majeed (2012). Issues and Challenges in Scrum Implementation. International Journal of Scientific & Engineering Research, Volume 3, Issue 8. Retrieved from https://scholar.google.dk/scholar?q=Issues+and+Challenges+in+Scrum+Implementation&hl=da&as_sdt=0&as_vis=1&oi=scholart
17. ↑ Schmidt, Tobias Sebastian; Chahin, Abdo; Kößler, Johannes; Paetzold, Kristin (2017): AGILE DEVELOPMENT AND THE CONSTRAINTS OF PHYSICALITY: A NETWORK THEORY-BASED CAUSE-AND EFFECT ANALYSIS. In: Proceedings of the 21st International Conference on Engineering Design (ICED17), Vol. 4: Design Methods and Tools, Vancouver, Canada, 21.-25.08.2017.
18. ↑ ISO (2020): ISO 21502:2020(E) Project, programme and portfolio management — Guidance on project management