SCRUM - An Agile Project Management Framework

Latest revision as of 20:38, 28 February 2021

Developed by Mads Hønberg

Scrum is an agile project management framework primarily used for software development. It is based on short work cycles of 2-4 weeks(sprints) to create incremental business value. The workforce is organized in small teams, with cross-disciplinary skills and knowledge, who receives continuous feedback from key stakeholders after each sprint. The constant feedback and dialogue with stakeholders are key to delivering true business value and keeping the project on track. Jeff Sutherland and Ken Schwaber created Scrum, both ex-soldiers from the Vietnam war, which later both became a part of the software industry and had a shared frustration with late deliveries, poor quality, and user dissatisfaction ^[1]. They were inspired to create Scrum by Hirotaka Takeuchi and Ikujiro Nonaka, who compared a new development approach to the movement of a rugby team, in their paper “The New New Product Development Game”^[2], this became the inspiration for the roles and team. They found the inspiration for the values and management of the teams in the theory of Empirical Process Control^[3], which builds on Transparency, Inspection, and Adaptation. The article will focus on what Scrum is and why it can benefit software development compared to the traditional waterfall development framework. This will include an overview of Scrum roles, events & artifacts, followed by sections on benefits & limitations.

To overcome the traditional challenges of software development, which builds on the assumption of constant demands and full sign of on requirements before beginning, a more agile approach, Scrum, has gained its justification. The ability of Scrum to cope with the reality of modern software development with ever-changing demands, the challenge of capturing all requirements from the beginning, the acceptance of failure, and the need for testing while developing, but most importantly, the acceptance of changing preferences and requirements from the client as the development evolves, has made it a popular framework for software development.

[edit] The agile foundation for Scrum

Figure 1. A comparison of the Waterfall and Scrum framework, showing the different approaches to delivering, including the project phases. Inspired by pmi-macedonia.mk^[4]

Scrum is widely used due to its efficient framework for organizing a team and their tasks to deliver continuous business value. The implementation of Scrum is often driven by the wish to become more responsive to changing demands from stakeholders. With a technological scene changing faster than ever, there is an increasing demand for a development framework that allows for changing priorities and requirements during development. Software development was previously often based on the linear waterfall model^[5] where everything is signed of and specified before the project is started; see figure 1. When developing software, the timeline will often be multiple years; requirements and priorities will often change during this period. In contrast to this approach, Scrum is based on short sprints, where the most value-adding tasks from the backlog are completed in self-organized teams and immediately shared with the end-user to get continuous feedback. Instead of one final delivery at the end, the idea of Scrum is to develop small incremental updates with flexibility for changes, which in small steps will fulfill the scope. Scrum also includes the phases: Initiating, Planning, Executing, Monitoring & Controlling, and Closing, all known from the standard for project management, PMBOK Guide ^[6]. Instead of performing the phases one time like the waterfall model, the phases will be continuously repeated in each sprint to make it possible for adjustments and reprioritization; this will often be considered working agile.

The Scrum framework is based on the 12 agile principles, which were signed by the 2 founders of Scrum and 15 other prominent individuals, all frustrated with traditional software development. The 12 Agile principles are based on 4 core values^[7]:

Individuals and Interactions over Processes and Tools

The focus is on what will create value. It is people who will interact, communicate as needed, and develop the results. The Scrum members should therefore be prioritized above strict process and tool requirements.

Working Software over Comprehensive Documentation

Instead of having the developers spending hours on specifying technical documentation and requirements. It should be trusted that the developers can use their time more efficiently making software, which will create business value.

Customer Collaboration over Contract Negotiation

Instead of following the traditional approach of the waterfall model, where everything is negotiated before the execution phase. The customer or stakeholders should be included during the work and be part of the collaboration to assure the work makes business value.

Responding to Change over Following a Plan

Instead of seeing a change as an expense, changes should be welcomed and incorporated to create additional business value.

The 12 principles can be read in full in the Agile Manifesto^[8]. Even though the founders of Scrum signed the agile manifesto, it is a common misunderstanding that Scrum and agile are the same thing. As mentioned above, agile is a set of values and principles. To adopt an agile way of working, the Scrum team must work under these principles and beliefs. The implementation of Scrum can push you towards a more agile way of working but cannot do it alone^[9].

[edit] The Scrum Team

The implementation of Scrum will lead to a new way of organizing the staff to fulfill the roles of the Scrum^[10]. The definition of the Scrum team follows the Scrum guide^[11]. A Scrum team is a small team of professionals, consisting of one Scrum Master, one Product Owner, and Developers; in total, they should not exceed 10 individuals. The team has no sub-teams or hierarchy and works towards the same product goal. A Scrum team is self-managed and has cross-functional roles and knowledge to make sure the team has the skills to create business value in each sprint^[11]. In traditional software development, a Product Manager will both be organizing and assigning the tasks among the developers, which also means the Product Manager will be held responsible for the results. In the Scrum framework, the team is self-managed and thereby responsible for distributing the work among each other and developing the right thing. In this way, the accountability is placed on the developers, which are also the ones with the capability of developing the software. The scrum framework trust that when the developers have the responsibility, they will produce a better product^[9].

[edit] Product Owner

The product owner's responsibility is to maximize the business value created by the Scrum team by utilizing his or her knowledge concerning the demands of the stakeholders and business landscape. The role as Product Owner is held by one person. To gain success with Scrum, the decisions of the product owner must be respected by the organization; the product owner must be able to make decisions that will not later be overruled. The product owner has the responsibility for the following points^[11]:

• Effective managing, development, and prioritization of the product backlog
• Clearly communicate product goal and product backlog items
• Keep stakeholders informed and included as necessary
• Execution of Sprint planning and Sprint Review sessions

The product owner will often be the “middleman” between the business and developers and must be able to find compromises. Strong communication skills, negotiation skills, proactivity, diplomatic, and result-driven will often be favorable personality traits for a product owner ^[12].

[edit] Developers

The developers are the ones who will produce the real work of each sprint. Atlassian, a key tech provider for many software companies using Scrum, presents the typical skill-set of the developers, like design, UX, programming, testing, and deployment ^[13]. The developers hold the responsibility of estimating and planning the tasks for the sprint based on the sprint backlog. They make the definition of when a task can be considered “done". Lastly, the developers are also accountable for daily adjustments of the sprint planning as they gain knowledge and learn about possible issues, to obtain the sprint goal ^[11].

[edit] Scrum Master

This role is not responsible for delivering on the task from the Sprint Backlog. The Scrum Master is there to help the team follow the Scrum practices and thereby increase the team's effectiveness. This can also include working with the organization to understand how the Scrum team works and when the rest of the organization will see results. The Scrum Master will often coach the team to master self-management, cross-disciplinary functions, and solve challenges and impediments that can be obstacles to progress. The Scrum master will help the Product Owner, as requested to, find techniques and tools for effective product goal definition, management of the product backlog, and stakeholder collaboration. Additionally, the Scrum master is involved with the rest of the organization to make sure they understand Scrum and the consequences of adoption. This will often include training and implementation of Scrum in the organization. Furthermore, the Scrum Master will often be involved in conflicts or challenges between the stakeholders and the Scrum team ^[11].

[edit] The Iterative Process of Scrum

Project management, as presented by the PMBOK standard^[6] splits a project into 5 phases: Initiating, Planning, Executing, Monitoring & Controlling, and Closing. These phases can be compared to the way work is organized in the Scrum framework. Considering figure 2, the initiating phase can be compared to the process that will happen regarding the Backlog. In this process, the Product Owner will receive and gather inputs from the End-users, Customers, Team, and other relevant stakeholders. But instead of using these inputs to create the full plan of the project, the Product Owner will prioritize them in the product backlog. The product owner will then together with the development team begin the planning phase for the upcoming sprint; here the inputs will be further refined and receive a time estimate. This phase will also include a definition of a Sprint goal, the objective which the team aims to achieve during the sprint. Hereafter, the Executing process will follow; this will in Scrum terminology, be considered the sprint. This is the part where the actual work will be completed, and the sprint goal is hopefully obtained – the Scrum team is self-managed and will get the work done in the manner that works best for them. Considering the task of monitoring and controlling the progress, the Scrum team will benefit from the manageable number of tasks, as they only plan work for a short period of time and secondly a part of the sprint planning included the task of estimating time for the task, which can be used to make a burndown chart of keeping track of expected progress for the team. Lastly is the closing phase of the project, which is the part where the sprint review is performed, and the increment pushed to the end-users to create instant business value. What then makes the difference to working with Scrum is the continuous repetition of this cycle, as illustrated in figure 2. The aim is to constantly improve and keep on track with requirements and priorities as they change. To gain a better understanding of the events and artifact, an explanation of each of them follow.

Figure 2. Overview of the Sprint and the including events and artifacts shows the iterative process where all events are a part of the timeboxed sprint. Illustration of the Scrum Framework by Scrum.org^[14].

[edit] Sprint

A sprint is a time timeboxed period within the Scrum team completes their planned task and performs the reoccurring events to obtain the sprint goal. The length of the sprint is always the same, usually 2 weeks, but it can be up to 4 weeks. The next sprint starts right after the previous was completed, which means all events and activities are a part of the sprint^[11]. To create a clear direction from the beginning of the sprint, the sprint goal cannot be changed and quality not decreased. If the sprint goal becomes obsolete during the sprint, the product owner has as the only one the power to cancel the sprint^[11].

[edit] Sprint Planning

The Sprint planning is the first activity of the sprint. By the Scrum guide, the sprint planning included 3 tasks and should be limited to 4 hours for a 2-week sprint^[11]. To make a realistic estimate of what can be accomplished in the sprint, the developers must know their capacity or time available in the sprint, often called velocity^[9].

1. Definition of the sprint goal. The product owner will present how the business value of the product can be increased in the current sprint, this will be used as the outset for collaboration by the entire team to define the sprint goal.
2. The developers will in collaboration with the product owner, select the items from the product backlog to include in the current sprint. This task included continuous refinement of the tasks, the definition of done, and time estimates; altogether this will make a more trustworthy estimate of what can be obtained in the sprint.
3. The developers plan based on the chosen tasks from the product backlog how they turn the task into valuable increments following the sprint goal. This task is solely completed by the developers.

[edit] Definition of Done

It might seem like a rather simple question when something is done. But as presented by Atlassian, a team without a clear definition of done will often find themselves asking whatever a task is done? A clear definition will help the team to identify when a task is done and can be presented as an increment for review ^[15]

[edit] Sprint Backlog

During the sprint planning, the team has refined and made the definition of done for each of the tasks prioritized for the sprint, selected from the backlog. These tasks are sometimes defined as user-stories and will be placed in the sprint backlog. The sprint backlog will be the overview of the user-stories to be completed during the sprint and should make it possible to fulfill the sprint goal^[11].

[edit] Daily Scrum

This event is the only reoccurring event every day of the sprint. It is a short 15-minute meeting, often hold in the morning as a standup. To reduce complexity, it should take place at the same place and time every day. The goal of the meeting is for the developers to share progress and possible obstacles. The Scrum Guide has no formal instructions of the daily scrum; the important thing is to find a format that fits with your team: online, standup, chat, or tossing a ball – what works for you is the right choice. Many teams will have each developer present what they did yesterday, plans for today, and whether they are blocked by anything ^[11].

[edit] Increment

Figure 3. Incremental deliveries vs. One Final Delivery. Illustrated with the example of a car, in reality, it would be very costly to develop a car with incremental deliveries – but it works nicely as an illustration for an incremental process. Inspired by Arijit Sarbagna, Dzone.com^[16]

At the end of the sprint, the scrum team has in the optimal scenario, completed all the tasks from the sprint backlog. If this is not the case, the sprint will still be complete as the timebox is coming to an end^[11]. The tasks that have not been completed will have to become a part of the backlog and go through the prioritization phase again to make it to the next sprint's backlog. The tasks which have resulted in changes, new features, or other relevant software updates to present for the stakeholders will be presented on the Sprint Review. Increments are a part of the agile way of working, where the focus is to make constant improvements while stakeholders are informed and provide continuous feedback. This can be seen as a process where features are added after the software is already taken into use, this is also known as Continuous Development/Continuous Integration^[17]. This is mainly used for software, but to make it more illustrative, it is showed with the example of car development in figure 3. Where incremental updates will focus on adding value, the first increment will be to make a product that can drive, then something more comfortable or faster, determined by what creates business value. In traditional waterfall development, the focus will often be to finish the wheels, then the cabin, and so on. This might seem more effective but have a high risk of not fulfilling the stakeholders' demand, as the solution cannot be adjusted while developed. Remember, the car example is only for illustrative matters; the focus is on software development.

[edit] Sprint Review

The goal of this session is to inspect and review the results of the sprint. This is often done with a presentation of deliverables by the scrum team for stakeholders. During this review, the goal is to have a dialogue about the results and the value in regards to the overall product^[11]. In terms of gathering a strong sense of ownership and engagement of the development team, this session can be used as a form of a celebration of what has been achieved and should have a casual vibe ^[18].

[edit] Sprint Retrospective

This is the chance for the scrum team to reflect upon the last sprint. What went well and what they would like to do even better, this should hopefully lead to initiatives that can increase quality and effectiveness in the future sprints. The scrum guide suggests the sprint results are evaluated in regards to the individuals, interactions, processes, tools, and the Definition of Done. Some of these initiatives that the team would like to change or implement can be added to the sprint backlog of the next sprint if required^[11]. To obtain the true value of the Sprint Retrospective, there must be a high level of transparency, honesty, and trust among team members; this will allow talking about some of the true challenges that the team might face. Afterward, the team will be stronger and be able to overcome every challenge. To create this transparent and safe atmosphere, the scrum master plays a crucial role^[9].

[edit] Why use Scrum for software development?

One of the main challenges when developing software is the changing priorities and requirements during the development period. The requirements and priorities for the product will at the end of the development period, in most cases, have changed since the development began. This challenge is captured in the book: Agile Product Management with Scrum^[19] her is a 2-year software development project using the waterfall framework described. During the project, the focus was on the plan and the budget, and they managed to complete the project on time and within budget. Unfortunately, the customer's market situation was after the 2-year development period, not as assumed, and the software was therefore useless, it had created no business value, and the resources was wasted. They did not allow for changes while the development was ongoing.

The smart reader will argue that this is not an argument for Scrum, which is true. This is a clear example of one of the main challenges with traditional software development, where an agile approach is beneficial. By adopting Scrum, you will work in short sprints, from which you will receive continuous feedback from stakeholders at review sessions to make sure the result will add business value. This way of working will allow for flexibility and changing requirements, which is a great advantage when developing software.

Figure 4. The level of risk following the progress comparing the Scrum and Waterfall framework during software development. Inspired by James Freeman, edrawsoft.com^[20]

Another important aspect that is often considered in project management is limiting risk. When developing software, one of the major risks is to develop the “wrong” software, as presented above. Comparing the waterfall framework and the Scrum framework in this light, the risk of developing the wrong end product has been illustrated in figure 4. As the Scrum framework is based on iterative deliveries with continuous review and implementation, the risk will be limited to developing the wrong thing in one sprint, compared to the waterfall method where the review follows after the software is completed.

[edit] Limitations of Scrum

To make a successful implementation of Scrum, it is of great importance that the rest of the organization is ready for a new way of working. The importance of implementing the 2 key characteristics of the Scrum framework: “Cross-functional” and “Self-managed” teams, is presented together with possible constraints in the book: Navigating Hybrid Scrum Environments ^[9]. Cross-functional means the team must contain the required skills to develop the product. Traditional teams often consist of people with the same skills. Having all the required skills in the teams prevents delays from dependencies from other parts of the organization. The second benefit is connected to being self-managed. When a team has no Product Manager, the team will be responsible for the work distribution and the solutions themselves. In this way, the team holds all the skills they need to deliver the product, combined with the responsibility. Combining capabilities and self-management will give the teams a greater sense of responsibility, resulting in better products. Scrum will often fail to become a success in organizations where the teams are not “Cross-functional” and “Self-managed”. This will often happen if the product owner turns into a traditional Product Manager, who distributes and assign work to the team. When the Product Owner starts to manage the team, he or she will also become responsible for the results. The creativity of the developers will be limited to the specified orders of the product manager. Trying to transform traditional teams with the same skills into Scrum teams will remove their capability of being “Cross-functional,” why they will often be delayed due to dependencies on other people in the organization.

The team size is another important matter to touch upon. According to the Scrum guide, the teams should have a maximum of 10 participants^[11]. In many large organizations, much more than 10 people are working on developing a product. Many of these organizations have seen the promising results of Scrum and want to adopt the framework. This can be a challenging task while keeping the ability to make fast changes and keep flexibility. The Scrum guide suggests splitting the group into multiple development teams with the same product backlog, product goal, and product owner^[11]. One of the main challenges when scaling the Scrum framework is to keep the teams self-managed; as more teams are working on the same product, the question of how they should be organized arises ^[9]. There are multiple frameworks that try to address this challenge, to mention a few Scaled Agile Framework (SAFe)^[21], The Large-Scale Scrum Framework (LeSS)^[22], or the Scrum@Scale^[23] could all be relevant to consider for scaling Scrum.

The focus of this article is Scrum used for software development. However, before jumping right into implementing Scrum for software development or other product development projects, it is important to consider what kind of product is being delivered. One of the key concepts of Scrum is incremental deliveries, and here is it important to consider what can be delivered incrementally. After the software architecture is developed and put in place, you could consider this as the skeleton of the software, you can start building on incremental updates, which the end-user can see and understand. But what about other projects, earlier on in figure 3, an example of developing a car incrementally was displayed, but is that even realistic. Probably not so much, the cost of first developing a skateboard, then a bike, and then end up with a car would simply be too costly and therefore not be a realistic application of Scrum. This is often considered as the constraints of physicality; some products will not benefit from being developed with the Scrum framework. Concerning software development, it benefits from the flexibility of the computer and the possibility of constant adding on.

[edit] Annotated bibliography

The Scrum guide^[11]

The guide for Scrum is written by Ken Schwaber and Jeff Sutherland. The guide is continuously updated, with the last update in 2020. The guide takes you through the roles, events, and artifacts you need to know before implementing Scrum. It can effectively be used as a handbook for the terminology of Scrum when the framework is implemented.

Agile Manifesto^[7]

The Agile Manifesto is signed by 17 individuals frustrated with traditional software development, including Ken Schwaber and Jeff Sutherland, the 2 originators of Scrum. All 17 individuals working within or around software development. The agile manifesto includes 12 principles and 4 values to reduce the challenges of software development. The values are important to incorporate to obtain the full advantage of Scrum.

Navigating Hybrid Scrum Environments^[9]

There are many books describing Scrum, the roles, artifacts, and events. This book takes it a step deeper and tries to answer the question of why. This will give you a much better understanding of the reasons for the different roles, artifacts, and events. The highlight of the book is the focus on why self-management and cross-disciplinary teams are so important for the success of Scrum and why it is challenging to scale these principles. The book is written by Frederik M. Fowler, who has worked as a software developer for more than 35 years and today is the highest-level certified Scrum Master.

[edit] References

1. ↑ Scrumdesk: The history of Scrum https://www.scrumdesk.com/the-history-of-scrum-how-when-and-why/ (Visited 20/02/2021)
2. ↑ The New New Product Development Game by Hirotaka Takeuchi and Ikujiro Nonaka https://hbr.org/1986/01/the-new-new-product-development-game (Visited 20/02/2021)
3. ↑ Scrum.org: The Three Pillars of Empiricism by Hiren Doshi https://www.scrum.org/resources/blog/three-pillars-empiricism-scrum (Visited 27/02/20)
4. ↑ Project Management Institute, Macedonia: Scrum or waterfall what is the difference? https://pmi-macedonia.mk/event/scrum-or-waterfall-whats-the-difference/ (Visited 27/02/2020)
5. ↑ Bibik I. (2018) How to Kill the Scrum Monster. Apress, Berkeley, CA. Retrieved from https://doi.org/10.1007/978-1-4842-3691-8_1
6. ↑ ^{6.0 6.1} Project Management Institute (2017) Guide to the Project Management Body of Knowledge (PMBOK Guide) 6th edition. Retrieved from https://app-knovel-com.proxy.findit.dtu.dk/s.v?4QJeKzna
7. ↑ ^{7.0 7.1} Agilemanifesto: Values of Agile Software Development https://agilemanifesto.org/ (Visited 20/02/2021)
8. ↑ Agilemanifesto: The 12 Agile Principles https://agilemanifesto.org/principles (Visited 20/02/2020)
9. ↑ ^{9.0 9.1 9.2 9.3 9.4 9.5 9.6} Fowler. F. M. (2018) Navigating hybrid scrum environments, Apress, Sunnyvale, CA. Retrieved from https://doi.org/10.1007/978-1-4842-4164-6
10. ↑ Atlassian: What is Scrum? https://www.atlassian.com/agile/scrum (Visited 21/02/2021)
11. ↑ ^{11.00 11.01 11.02 11.03 11.04 11.05 11.06 11.07 11.08 11.09 11.10 11.11 11.12 11.13 11.14 11.15} Schwaber K. & Sutherland J. (2020) The Scrum Guide. Retrieved from https://www.scrumguides.org/scrum-guide.html
12. ↑ Advanz: Scrum Product Owner https://advanz.dk/blog/scrum-product-owner/ (Visited 20/02/2021)
13. ↑ Atlassian: Scrum Roles https://www.atlassian.com/agile/scrum/roles (Visited 20/02/2021)
14. ↑ Scrum.org: What is scrum https://www.scrum.org/resources/what-is-scrum (Visited 27/02/2021)
15. ↑ Atlassian: Scrum Artifacts https://www.atlassian.com/agile/scrum/artifacts (Visited 20/02/2021)
16. ↑ Dzone.com, Arijit Sarbagna. https://dzone.com/articles/scrum-is-not-mini-waterfall (Visited 21/02/2021)
17. ↑ Infoworld: What is CI/CD https://www.infoworld.com/article/3271126/what-is-cicd-continuous-integration-and-continuous-delivery-explained.html (Visited 27/02/2021)
18. ↑ Atlassian: Sprint Review https://www.atlassian.com/agile/scrum/sprint-reviews (Visited 20/02/2021)
19. ↑ Pichler, R. Agile Product Management with Scrum (2010) Addison-Wesley Professional, Boston
20. ↑ Edrawsoft: Agile vs. Waterfall https://www.edrawsoft.com/agile-vs-waterfall.html (Visited 27/02/2020)
21. ↑ Atlassian: What is SAFe? https://www.atlassian.com/agile/agile-at-scale/what-is-safe (Visited 27/02/2021)
22. ↑ Atlassian: The Large-Scale Scrum Framework: https://www.atlassian.com/agile/agile-at-scale/less (Visited 27/02/2021)
23. ↑ Atlassian: Scrum at Scale https://www.atlassian.com/agile/agile-at-scale/scrum-at-scale (Visited 27/02/2021)