SCRUM - An Agile Project Management Framework
| Line 1: | Line 1: | ||
| − | ''Developed by | + | ''Developed by MH'' |
| − | + | Scrum has over the last few years become increasingly popular for software development for good reasons. In order to overcome the traditional challenges of project management for 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 project management framework for software development. | |
| − | + | ||
| − | + | ||
| + | Scrum is an agile project management framework especially popular for software development. It is based on short work cycles of 2-4 weeks(sprints) with the aim of creating incremental business value. The workforce is organized in small teams, with cross-disciplinary skills and knowledge, and receives continuous feedback from key stakeholders are after each sprint. The constant feedback and dialogue with stakeholders are key to delivering true business value and keeping the project on track. Scrum was created by Jeff Sutherland and Ken Schwaber, both ex-soldiers from the Vietnam war, which later both became a part of the software industry and had a shared frustration of late deliveries, poor quality, and user dissatisfaction <ref> Scrumdesk: The history of Scrum https://www.scrumdesk.com/the-history-of-scrum-how-when-and-why/ </ref>. They were inspired 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” <ref> The New New Product Development Game by Hirotaka Takeuchi and Ikujiro Nonaka https://hbr.org/1986/01/the-new-new-product-development-game</ref>. | ||
== Big idea == | == Big idea == | ||
| − | + | Scrum is widely used due to its efficient framework for organizing a team and their tasks in order 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 need to use a development process where priorities and requirements can be changed during the development. Software development was previously often based on the linear waterfall model<ref>How to Kill the Scrum Monster https://doi.org/10.1007/978-1-4842-3691-8_1</ref> where everything is signed of and specified before the project is started, see figure xx. When developing software, the timeline will often be multiple years, where both requirements and priorities likely have changed. In contrast to this approach, there is Scrum, which is based on shorter sprints, where the most value-adding tasks from the backlog are completed in self-organized teams and immediately shared with the client to get continuous feedback. Instead of one final huge delivery at the end, the idea of Scrum is to develop small incremental updates which will make the full delivery at the end, while being able to change requirements while developing. The scrum method includes a small part of the phases planning, executing, and monitoring process in each sprint, known from the standard for project management, PMBOK Guide <ref name = "PMBOK"> Guide to the Project Management Body of Knowledge (PMBOK Guide) 6th edition</ref>. Instead of performing the phases on time like the waterfall model, they will be continuously repeated in each sprint, to make it possible for adjustments and reprioritization, this will often be considered as the ability to being agile. | |
| − | + | ||
| + | The Scrum framework is based on the 12 agile principles, which were signed by the 2 founders of Scrum together with 15 other prominent individuals, all frustrated with traditional software development. The 12 Agile principles are based on 4 core values<ref>Values of Agile Software Development https://agilemanifesto.org/</ref>: | ||
| + | |||
| + | ; 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, why they should be prioritized above strict process and tool requirements. | ||
| + | |||
| + | ; Working Software over Comprehensive Documentation | ||
| + | : Instead of using tons of time on specified and technical documentation of requirements, the developer should be trusted, that he or she will be able to make use the time more efficient to make working 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 prior to work start. 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 on [[ https://agilemanifesto.org/principles.html |agilemanifesto]]. Even though the founders of Scrum signed the agile manifesto, it is a common misunderstanding the implementing Scrum, will make you agile. As mentioned above, agile is a set of values and principles. In order to adopt an agile way of working, the members of the scrum team will need to 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. The remainder of this article will focus on what scrum is and when it is beneficial for software development. This will include an overview of the scrum method, followed by a section on application and limitations. | ||
| + | |||
| + | ===Team & Roles=== | ||
| + | ====Scrum Team==== | ||
| + | |||
| + | The implementation of Scrum will lead to a new way of organizing the staff in order to make sure the roles of the Scrum team can be fulfilled<ref> Atlassian: What is Scrum? https://www.atlassian.com/agile/scrum</ref>. The definition of the Scrum team follows the Scrum guide (ref). A Scrum team is a small team of professionals, consisting of one Scrum Master, one Product Owner, and Developers, in total should they not exceed 10 individuals, if more people are working on the product then they should split into multiple teams. 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 they have the skills to create business value from each increment delivered after each sprint <ref name="scrumguide"> The 2020 Scrum Guide https://www.scrumguides.org/scrum-guide.html </ref>. | ||
| + | |||
| + | ====Product Owner==== | ||
| + | |||
| + | The responsibility of the product owner is to maximize the value of the product developed by the Scrum team. The role as Product Owner is held by one person, in order to gain success with Scrum it is crucial that the decisions of the product owner are respected by the organization. The product owner has the responsibility for the following points<ref name="scrumguide" />: | ||
| + | |||
| + | * 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 Spring 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 <ref> Advanz: Scrum Product Owner https://advanz.dk/blog/scrum-product-owner/ </ref>. | ||
| + | |||
| + | ==== 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, development/programing, testing, and deployment <ref> Atlassian: Scrum Roles https://www.atlassian.com/agile/scrum/roles </ref>. 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 of the issues, in order to obtain the sprint goal <ref name="scrumguide" />. | ||
| + | |||
| + | ==== 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 effectiveness of the team. This can also include working with the organization to understand how the scrum teams work and when the rest of the organization will see results. In order to support the team, the scrum master will often coach the team to master self-management, cross-disciplinary functions, solve challenges and impediments which 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. In addition, is the Scrum master 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 <ref name="scrumguide" />. | ||
== Application == | == Application == | ||
| + | |||
| + | Project management as presented by the PMBOK standard<ref name = "PMBOK" /> 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 the figure above, the initiating phase can be compared to the process that will happen regarding the Backlog. In this process will the Product Owner receive and gather inputs from the End-users, Customers, Team, and other relevant stakeholders. But instead of using this to create the full plan of the entire project, the product owner will prioritize them and find the most important. The product owner will then together with the development team being the planning phase for the upcoming sprint, here will the inputs be further refined and get a time estimate, this will also include a definition of a Sprint goal, the objective which the team aims to achieve during the work period. Hereafter will Executing process come, 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 are 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 will the Scrum team 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, this can be considered the part where the sprint review is performed, and the increment pushed to the end-users to create instant value. What then makes the true difference to working with scrum is then the continuous repetition of this cycle, as it is also illustrated in the figure, in order to constantly improve and keep on track with requirements and priorities from the customer. To gain a better understanding of the events and artifact, an explanation of each of them follow. | ||
| + | |||
| + | === Artifacts & Events === | ||
| + | |||
| + | ==== Sprint ==== | ||
| + | |||
| + | A sprint is a time timeboxed period, within the sprint, the Scrum team completes their planned task and performs the reoccurring events in order to obtain the sprint goal. The length of the sprint is always the same, usually 2 weeks, but can vary between projects up to 4 weeks. The next sprint starts right after the previous was completed, which also means all events and activities are a part of the sprint. | ||
| + | In order 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. | ||
| + | |||
| + | ==== Sprint Planning ==== | ||
| + | |||
| + | The Sprint planning is the first activity of the sprint. In accordance with the scrum guide, the sprint planning included 3 tasks that must be addressed and should be limited to 4 hours for a 2-week sprint. | ||
| + | |||
| + | # Definition of the sprint goal. The product owner will present how the product can increase value in the current sprint, this will be used as outset for collaboration by the entire team, to define the sprint goal. | ||
| + | # 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 continuously refinement of the tasks, definition of done and time estimates, altogether this will make a more trustworthy estimate of what can obtained in the sprint. | ||
| + | # The developers plan based on the decided task from the product backlog, how they turn the task into valuable increments. This task is solely completed by the developers. | ||
Backlog - Sprint backlog - Estimating & capacity | Backlog - Sprint backlog - Estimating & capacity | ||
Revision as of 16:36, 21 February 2021
Developed by MH
Scrum has over the last few years become increasingly popular for software development for good reasons. In order to overcome the traditional challenges of project management for 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 project management framework for software development.
Scrum is an agile project management framework especially popular for software development. It is based on short work cycles of 2-4 weeks(sprints) with the aim of creating incremental business value. The workforce is organized in small teams, with cross-disciplinary skills and knowledge, and receives continuous feedback from key stakeholders are after each sprint. The constant feedback and dialogue with stakeholders are key to delivering true business value and keeping the project on track. Scrum was created by Jeff Sutherland and Ken Schwaber, both ex-soldiers from the Vietnam war, which later both became a part of the software industry and had a shared frustration of late deliveries, poor quality, and user dissatisfaction [1]. They were inspired 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].
Contents |
Big idea
Scrum is widely used due to its efficient framework for organizing a team and their tasks in order 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 need to use a development process where priorities and requirements can be changed during the development. Software development was previously often based on the linear waterfall model[3] where everything is signed of and specified before the project is started, see figure xx. When developing software, the timeline will often be multiple years, where both requirements and priorities likely have changed. In contrast to this approach, there is Scrum, which is based on shorter sprints, where the most value-adding tasks from the backlog are completed in self-organized teams and immediately shared with the client to get continuous feedback. Instead of one final huge delivery at the end, the idea of Scrum is to develop small incremental updates which will make the full delivery at the end, while being able to change requirements while developing. The scrum method includes a small part of the phases planning, executing, and monitoring process in each sprint, known from the standard for project management, PMBOK Guide [4]. Instead of performing the phases on time like the waterfall model, they will be continuously repeated in each sprint, to make it possible for adjustments and reprioritization, this will often be considered as the ability to being agile.
The Scrum framework is based on the 12 agile principles, which were signed by the 2 founders of Scrum together with 15 other prominent individuals, all frustrated with traditional software development. The 12 Agile principles are based on 4 core values[5]:
- 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, why they should be prioritized above strict process and tool requirements.
- Working Software over Comprehensive Documentation
- Instead of using tons of time on specified and technical documentation of requirements, the developer should be trusted, that he or she will be able to make use the time more efficient to make working 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 prior to work start. 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 on agilemanifesto. Even though the founders of Scrum signed the agile manifesto, it is a common misunderstanding the implementing Scrum, will make you agile. As mentioned above, agile is a set of values and principles. In order to adopt an agile way of working, the members of the scrum team will need to 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. The remainder of this article will focus on what scrum is and when it is beneficial for software development. This will include an overview of the scrum method, followed by a section on application and limitations.
Team & Roles
Scrum Team
The implementation of Scrum will lead to a new way of organizing the staff in order to make sure the roles of the Scrum team can be fulfilled[6]. The definition of the Scrum team follows the Scrum guide (ref). A Scrum team is a small team of professionals, consisting of one Scrum Master, one Product Owner, and Developers, in total should they not exceed 10 individuals, if more people are working on the product then they should split into multiple teams. 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 they have the skills to create business value from each increment delivered after each sprint [7].
Product Owner
The responsibility of the product owner is to maximize the value of the product developed by the Scrum team. The role as Product Owner is held by one person, in order to gain success with Scrum it is crucial that the decisions of the product owner are respected by the organization. The product owner has the responsibility for the following points[7]:
- 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 Spring 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 [8].
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, development/programing, testing, and deployment [9]. 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 of the issues, in order to obtain the sprint goal [7].
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 effectiveness of the team. This can also include working with the organization to understand how the scrum teams work and when the rest of the organization will see results. In order to support the team, the scrum master will often coach the team to master self-management, cross-disciplinary functions, solve challenges and impediments which 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. In addition, is the Scrum master 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 [7].
Application
Project management as presented by the PMBOK standard[4] 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 the figure above, the initiating phase can be compared to the process that will happen regarding the Backlog. In this process will the Product Owner receive and gather inputs from the End-users, Customers, Team, and other relevant stakeholders. But instead of using this to create the full plan of the entire project, the product owner will prioritize them and find the most important. The product owner will then together with the development team being the planning phase for the upcoming sprint, here will the inputs be further refined and get a time estimate, this will also include a definition of a Sprint goal, the objective which the team aims to achieve during the work period. Hereafter will Executing process come, 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 are 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 will the Scrum team 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, this can be considered the part where the sprint review is performed, and the increment pushed to the end-users to create instant value. What then makes the true difference to working with scrum is then the continuous repetition of this cycle, as it is also illustrated in the figure, in order to constantly improve and keep on track with requirements and priorities from the customer. To gain a better understanding of the events and artifact, an explanation of each of them follow.
Artifacts & Events
Sprint
A sprint is a time timeboxed period, within the sprint, the Scrum team completes their planned task and performs the reoccurring events in order to obtain the sprint goal. The length of the sprint is always the same, usually 2 weeks, but can vary between projects up to 4 weeks. The next sprint starts right after the previous was completed, which also means all events and activities are a part of the sprint. In order 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.
Sprint Planning
The Sprint planning is the first activity of the sprint. In accordance with the scrum guide, the sprint planning included 3 tasks that must be addressed and should be limited to 4 hours for a 2-week sprint.
- Definition of the sprint goal. The product owner will present how the product can increase value in the current sprint, this will be used as outset for collaboration by the entire team, to define the sprint goal.
- 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 continuously refinement of the tasks, definition of done and time estimates, altogether this will make a more trustworthy estimate of what can obtained in the sprint.
- The developers plan based on the decided task from the product backlog, how they turn the task into valuable increments. This task is solely completed by the developers.
Backlog - Sprint backlog - Estimating & capacity
Self-organized teams - cross-disciplinary -
Retrospectives - Learnings & review
Risk of scrum vs benefits
Limitations
Consider overall planing Training of employees & implementation
Annotated bibliography
The official scrum guide
References
Managing Successful Projects with PRINCE2 2017
- ↑ Scrumdesk: The history of Scrum https://www.scrumdesk.com/the-history-of-scrum-how-when-and-why/
- ↑ The New New Product Development Game by Hirotaka Takeuchi and Ikujiro Nonaka https://hbr.org/1986/01/the-new-new-product-development-game
- ↑ How to Kill the Scrum Monster https://doi.org/10.1007/978-1-4842-3691-8_1
- ↑ 4.0 4.1 Guide to the Project Management Body of Knowledge (PMBOK Guide) 6th edition
- ↑ Values of Agile Software Development https://agilemanifesto.org/
- ↑ Atlassian: What is Scrum? https://www.atlassian.com/agile/scrum
- ↑ 7.0 7.1 7.2 7.3 The 2020 Scrum Guide https://www.scrumguides.org/scrum-guide.html
- ↑ Advanz: Scrum Product Owner https://advanz.dk/blog/scrum-product-owner/
- ↑ Atlassian: Scrum Roles https://www.atlassian.com/agile/scrum/roles
