Scrum

From apppm
Revision as of 21:45, 1 December 2014 by Murcs (Talk | contribs)

Jump to: navigation, search

This article focuses on Scrum, which is a framework [1] for dealing with Agile Project Management. Scrum can be used in different size projects and can also be used for Program and Portfolio management. The article will introduce the framework and the underlying principles. The framework has been developed by many contributors, but was introduced by Jeff Sutherland and Ken Schwaber at the OOPSLA 1995 conference [1].

The Framework is used in managing agile project, and focuses on project with high complexity, novelty with a fixed deadline. The important factors of Scrum are that it depends on three main roles the Product Owner that has the responsibility of the Product Backlog. The Development Team that develops the product that the Product Owner has specified in the Product backlog. And the Scrum Master that controls that the Scrum rules are being over held. Scrum is based on having Sprints where every Sprint a working Increment should be produced.

Contents

Background

History

The creator of The Scrum development process have been a frequent topic of debate, but from the Scrum Papers [2] by Jeff Sutherland the start of Scum has been dedicated to the Godfathers; Hirotaka Takeuchi and Ikujiro Nonaka, they where the ones that came up with he name Scrum and came up with the initial concept in the paper [The New Product Development Game] [3] in 1986 [1]. While Jeff Sutherland was the one to apply the concept and tweak it for then introducing it together with Ken Schwaber at the OOPSLA 1995 conference.

Schwaber and Mike Beedel later introduced Scrum in the first book about Scrum: Agile Software Development with Scrum in 2001. From the Scrum Papers [2] it becomes clear that there have been many contributors in forming the Scrum framework. A Scrum community stated emerging, and a platform to unite the community was created with the name Scrum Alliance (SA) [4] and Certified ScrumMaster (CSM) certification. But over the time since SA was created there became an dispute about their stands and transparency [5] and the result was that Schwaber created Scrum.org [6] . In 2013 Schwaber and Sutherland published the latest version of The Scrum Guide™ [7]

Takeuchi and Nonaka realized that in the "fast-paced, fiercely competitive world of commercial new product development, speed and flexibility are essential" [3], and that the old way of developing product by following a sequential order was not sufficient. Takeuchi and Nonaka therefore introduced a holistic approach with six characteristics "built-in instability, self-organizing project teams, overlapping development phases, "multilearning", subtle control, and organizational transfer of learning" [3] when used as a whole become a flexible and powerful tool and named it Scrum.

Sutherland believes that Scrum is a framework based on a set of best practices during the past 50 years of software development. And it is not a development method or a formal process [1][2], he gets support from Schwaber in his claim. Sutherland also says "Scrum is used as an agile practice that delivers software to the end user faster, better and cooler".[2]

Overview of Scrum

What is Scrum?

According to the Scrum Alliance: [2]

“Scrum is an agile framework for completing complex projects. Scrum originally was formalized for software development projects, but works well for any complex, innovative scope of work. The possibilities are endless. The Scrum framework is deceptively simple.”

Scrum is a framework that enforces a set of rules for how teams can collaborate and work together efficiently and effectively to develop complex projects to develop a product, it provides a structure that enables the team to focus on projects that might otherwise seem extremely challenging. The framework can be used and to scale any size of project [8], and also in programs and portfolios, but for this article the focus will be on using Scrum in projects. Scrum is best suited for projects that change rapidly and have frequent emerging requirements. The framework is also a way of supporting the employees in having focus on the human accept by creating a sense of belonging to the team and that they are needed. It focuses on learning, creativity and the interaction with others, since this is essential for the projects success.

Scrum is not using Gantt charts, but using sprints that last no longer than 30 days. When using Gantt Charts all the details are planning in the beginning, where there is the most uncertainty concerning the project. Every sprint insted tries to create a working Increment from the beginning, even if it starts out small, for then continuously developing on it. An Increment is the sum of all the items on the Product Backlog that is finished during a Sprint [2].

At the core of Scrum are the three roles; the Product Owner, the Scrum development team an the Scrum Master, which all have their specific roles which will be described below. Next important aspect of the Scrum framework is Artifacts; the Product backlog and the Sprint backlog also to be explained below.

Roles

In Scrum there are three main roles that need to be implemented there needs to be a Product Owner, a Scrum development team and a Scum Master, collectively they are called The Scrum Team

Product Owner

The product owner (PO) is a single person that has the responsibility of getting the maximum return on investment (ROI), this is done by that the PO manages the Product Backlog. [2] [9] At the very beginning the PO gathers all the necessary requirements given to achieve the goals and mission. Then a set of user stories are created either alone or in collaboration with the Development team. The stories are prioritized by using different techniques for example Planning Poker or T-shirt sizes [10] for then being added to the Initial Backlog. Where they are arranged after what is most important based on the complexity and not on the effort and time.

The PO has the responsibility of creating a transparent product backlog that shows all the necessary items, but this not necessarily mean that the PO will give a detailed requirements upfront. The PO is the one that decides what needs to be done during the next sprint, but again might still not give all the details. The focus is more on "the what" than the how of the project.

The PO makes sure that the Development team understands the Product backlog to the extent needed. Because it might not make sense to make up all the details upfront, since there might be high uncertainty for the future, but the PO needs to have the vision. The PO also have the responsibility for the optimizes of what the development team does and also the value of the work.

It is important that the PO is respected ant that what the PO decides is what goes, the development team is not allowed to take orders from other parties and are not allowed to overrule the PO and act as they please. If anyone wants something from the development team they will need to ask the PO, and the PO decides if it is important to the project.

The PO can sometimes be the customer and other times the customer might be millions of people all having different needs. The PO can sometimes have a similar role as a Product manager, but the POs role is somewhat different from a Product Manager, because the PO's role is to actively be in contact with the development team, and review each sprint as they finish, for then creating the next sprint backlog.

Scrum Development Team

The Development Team is a cross-functional group of people that are self organized [9]. The Development Team job is to create the product [2] that the PO has planned, and provide the PO with ideas how to make a product great. The Development Team does the analysis, development, testing, interface design documentation among other things [2]. By every sprint they try to make a functional increment that is potentially shippable [9], only the ones that are part of the Development Team create the increment. The team is built up of people that in total have all the necessary requirements to be able to create the increment. They are self-organizing managing that they have the sole responsibility to how they turn the product backlog into increments [7].

The Development Team do not have individual titles, other than Developer [7], and it is an important factor that the Team can count on each other [9] to be able to realize the Increments each sprint. If the same team is kept together over a longer time and they learn how to work together it is assumed that they will increase productivity [9]. The Development team members can have specialized skills, but the whole team is help responsible for the project, following Scrum rules sub-teams are not allowed [7].

The Development Team can have different sizes, but a minimum of two people is set [7]. The optimal size is set to 4-9people [9]. If the team is to small they might encounter problems with not being able to complete sprints because there might be a lack of skills in the team[2]. When the team becomes to big other issues might occur for example that the complexity increases and organizing difficulties. There can be several Scrum development teams working on different aspects of the product [2], but with close coordination between them.

Scrum Master

The main role of the Scum Master (SM) is to teach the Development Team to apply Scum to achieve business value [2]. The SM has the responsibility to help the PO and Development team be successful, but the Scrum Master is not the team manager, the SM has no managerial authority, but their role is to serve the team and protect them against outside influences [9]. The SM also helps the organization with the changes that Scrum afflicts and makes the organization understand what is needed for success using Scrum.

In most cases the SM is a full-time job, but in some cases the SM can be part of the Development Team, but the PO and SM cannot be the same person [2]. The SM can have different backgrounds from engineering, product management, project management etc.

Events

Scrum has different events, the two main events are Sprints, which is the intervals that the Scrum Team works in. And Daily Scrum, which is a meeting that is held daily for updates on progress.

Sprints

Sprints are fixed lengths of intervals, sprints are officially 30days long, but it is quite common that a sprint is done in 14days. Every sprint contains a combination of; Analysis, design, actual implementation, testing, planning for the future, shipping and deploying [9][2]. During a sprint there should be done a little design every time tip it becomes a continues design, the customer does not always know what they want to begin with, therefore by having continuous design the Development Team will eventually reach the goal.

The sprint has as a goal that at the end of each spiny there should potentially be a releasable increment. A Sprint always starts directly after the previous Sprint has ended. There can be made no changes to the Sprint Goal, but the scope can be changes when the PO and development Team learn more [7]. A Sprint may be cancelled, but it is very rare since the Sprints are no longer than 30 days. If they are cancelled the PO will look at the work form Product backlog that is "Done" and see if some of it can be used or if it should be dismissed.

Sprint planning is an important part of Scrum, for a 30-day Sprint the maximum time used is eight hours [2], if the sprint is shorter, the planning time is usually also shorter. The Sprint planning plans what can be delivered and how will the work needed to reach the goal be achieved. The Sprint Goal is a set objective that can be reach by using the Product backlog[7] .

tabell

Daily scrum

Daily scrum is a meeting that is held at the same time for everyday of the sprint. All team members participate, it as held at the same location everyday and should maximum last for 15 min. During the meeting three topics are discussed [7] [11]:
1. What was done yesterday to meet the Sprint Goal
2. What will be done today to meet the Sprint Goal
3. Are there any challenges that can cause problems reaching the Sprint Goal.

Daily Scrum is used to evaluate if the progress is going the way it should to reach the Sprint Goal. After a Daily Scrum the Development team often meets to further discuss on the plan. [7]

Sprint Review and Sprint Retrospective

After the Sprint is finished the Scrum Team and the stakeholder review it, and the Product Backlog might be updated if needed. During the review the PO informs what has been "Done" and what has not been "Done". The Development team tells what has gone well and what has been a challenge [7]. The Review regards the product. At the end the entire group will discuss what needs to be done next.

The Sprint Retrospective regards the process. [2] It is a step that often is overlooked, but is very important for optimization. During the meeting it is discussed what is working and what is not, and find a way of solving the issues. The Development team and the SM attend, while the PO is welcome to join if he feels like it. [2]

Artifacts

Product Backlog

The Product Backlog is a list of everything that might be needed done to the product [9][7][2], it is where any changes to the product will be added. The Product Backlog is the POs responsibility, anyone can add to it but it is the PO that has the responsibility of prioritize the list to maximize the ROI[2][7]. But there is always only one item on the top of the list. If something is not in the Product Backlog then it does not exist, but the Product Backlog is never done, and at the beginning only the known requirements are added [9]. There can be multiple Scrum Teams working on the same Product Backlog.

One of the ways the product backlog is prioritizing is by looking at the relative size of the items (factoring in complexity, uncertainty and effort) [2], using a unit of Story Points. This is used to see how many tasks they can to each Sprint, by saying that they on average can do 24 Story Points per Sprint [2].

table of PB

Sprint Backlog

The Sprint Backlog contains what needs to be done during a sprint. The Sprint Backlog is made by looking at the Product Backlog and taking the highest priority item and break it down into individual tasks[2]. The Sprint Backlog visualized the work that the Development Team needs to do to reach the Sprint Goal. If something is found unnecessary to do it is removed from the Sprint Backlog.

Table of SB

Since the Team is self-managing it needs to know how the Sprint is going and if they are able to finish the items on time. To manage this a Sprint Burndown Chart is used [12][2]. This Charts contains the ideal time set to do the tasks, while one person adds everyday to the Sprint Burndown Chart what the expected hours remaining to finish for the entire Team is. The goal is that the Burndown Chart has a downward slope, meaning that they at the end of the Sprint have reach the goal [2].

Figure of a burndown chart

Implementation of Scrum

When starting implementing Scrum there of course needs to be a project that is suited for the Scrum Framework, next is gathering the Scrum Team that will do the project. [13][14]

1. Staring of getting everyone interested in the Scrum, what is Scrum, why is it relevant to this project, What are the benefits from it.
2. Start by having a pilot test of Scrum in the organization, because even tough Scrum might seem like the may to go it might not work in the particular organization it is planned to be implemented in.
3. Having an environment that is Scrum-friendly is key, it the organization is working against Scrum the chances are higher of failure.
4. The backlog needs to be in order, this means that there will need to be a willing PO and that there is someone that is acting as a SM. They will then need to add the tasks that are known to the Backlog so far and prioritize them. There needs to be at least enough work for the first Sprint to start. From this the Development Team can be created based on what is assumed needed to be done.
5. Plan the Sprint and then start sprinting, it is not necessary to wait till all of the pieces in the puzzle are available, the best way is to just start and the evaluate what is working and not working at the end of the Sprint.
6. Track the process with the Sprint Burndown Chart, to try and ensure that the project is going as planned.
7. Finish when it is planned to be finished. Done means that it should be Done, and there is no more time to do it, but the changes must be revisable.
8. Evaluate, review and do it again, meaning that plan the next Sprint and to it better than last time.

Even if the steps are followed three will still be encounters where problems arise, but Scrum is a Framework that needs to be used to understand fully, and it is important that the rules are followed to ensure that the project and company reaps the benefits of Scrum.

When to use and when not to use Scrum

Scrum can be used in many projects, but it is suggested to use Scrum when a project is very agile, when the success of the project is dependent on how the team can respond to the customer need. Meaning that the customer can change their mind and the project has a turnaround which needs to be handled in the next sprint [15]. Scrum has the greatest success when there is an strict deadline, a high degree of complexity and a novelty to the project [16]. It is used when there is newness to the project, if it is something they have done many times before then Scrum might not be the right approach. Scrum is very relying on finish the most important items first and having the ability to adjust the scope when needed. Also all steps are not known in advance and change is to be expected [15]. And both the team and organization need to be on board and willing to follow the Scrum rules.

"Scrum works well because it provides communication, social integration, control and coordination mechanisms that are especially useful for distribution and agile project management" [17]

Scrum should not be used when the company is working passively or actively against the Scrum rules, for Scrum to work the guidelines need to be followed [18]. Some companies do not see the benefit from using Scrum and will therefore either not bother to try at all or just do what they feel is necessary. Also companies that believe in Scrum and think they will get great benefits form it can end up using it wrong and not completely committing should not use Scrum. If the company cannot set the amount of people that is needed aside and try to used them in different projects then Scrum will not work. If the team members cannot follow a fairly daily fixed scope they might run into problems. Because Scrum is based on having a daily progress and if the team members feel free to not follow the set Scope the Burndown Chart might not be getting the desired downward slop. As for that the company, they might be working against Scrum, but so can the team members also be therefore it is important to have a strict SM that will guide the team into following the Scrum rules. Another time where Scrum should not be used is when the time set to do the project is way shorter than what it possibly can be done in. For example if the time needed is 21 months, but the time given is 15months then the chances of having success with the Scrum Framework is low.

Scrum was developed for Software Development, therefore some say that Scrum should only be used for doing that [18], while others say that they do not see a project where Scrum cannot be used [19].

Examples

An example of not using Scrum is when you are dealing with production of for example cars, tables, windows etc. When it has been done enough times the company will be aware of the things that work and what does not work and the novelty is low [16]. Another example is restaurants when they get special orders on dishes, they are very likely to be able to handle this change because the complexity is low, and therefore they are not very likely to need a Scrum development team to handle it.

Examples of when to use Scrum is of course the main one when creating a Software program [16], they are often complex, novel and have a fixed deadline. A different example could be when planning an event be it a wedding, fashion show or concert, there are many factors that play into part for it to be a success. To start there is always a deadline that needs to be met. Second they are usually novel because every wedding is different with different menus, locations, flower, artists, fashion designers, guests etc., which also creates a high complexity.

Next example is the design of products, the customer might not always now from the beginning what they want maybe they are asking for a product that can transport them somewhere. They start with some constraints that the product should have wheels, and should have some way of being steered. This gives the Development Team something to start with and after the first Sprint they might come back with a scooter (a child's foot-operated vehicle). But this was not exactly what the customer wanted, they wanted something that they can sit on as well and pedal to get the product moving. The Development Team comes after the next sprint with a new suggestion a bike. But again the customer is not completely happy, they want it to be able to transport more than one person and that it has an engine to help with the work. The Development team then has an Increment of a motorized bike with a box that other people can sit it. And this can continue till the customer is satisfied.

Reflections

The Scrum framework can be used for many types of projects, programs and portfolios of different sizes. It can help the company reach their goals by having a structured way of approaching agile projects. When used correctly it creates a team that are dependent on each other and therefore work coherently together to reach the goal, because they feel a commitment to the team. The downside of Scrum is that if the rules are not obliged the outcome might not be what was expected. There exist many different adaptations of Scrum that a company might follow and have success with, but for it to be true Scrum the rules and guidelines need to be followed.

See also

Agile Project Management

References

  1. 1.0 1.1 1.2 1.3 A Brief History of Scrum, A Confusing Origin Story, Venkatesh Krishnamurthy, October 15, 2012
  2. 2.00 2.01 2.02 2.03 2.04 2.05 2.06 2.07 2.08 2.09 2.10 2.11 2.12 2.13 2.14 2.15 2.16 2.17 2.18 2.19 2.20 2.21 2.22 2.23 The Scrum Papers:, Nut, Bolts, and Origins of an Agile Framework, Scrum, Inc. Jeff Sutherland, Version 1.1 – 2 Apr 2012
  3. 3.0 3.1 3.2 "New New Product Development Game". Harvard Business Review 86116:137–146, 1986. January 1, 1986. Retrieved March 12, 2013
  4. Link: www.scrumalliance.org
  5. The Scrum Compliance, Agile Anarchy Link: https://agileanarchy.wordpress.com
  6. Link: www.scrum.org
  7. 7.00 7.01 7.02 7.03 7.04 7.05 7.06 7.07 7.08 7.09 7.10 7.11 The Scrum Guidelines, The Definitive Guide to Scrum: The Rules of the Game, Ken Schwaber and Jeff Sutherland, July 2013, Scrum.Org and ScrumInc
  8. Scaling Scrum to Program and Portfolio level, SCRUMstudy, February 10, 2014
  9. 9.0 9.1 9.2 9.3 9.4 9.5 9.6 9.7 9.8 9.9 Link: scrummethodology.com
  10. what the PO does during the sprint, Juan Banda, September 25, 2009 Link: juanbandaonscrum.blogspot.dk
  11. Daily Scrum: Merely a status report?, Vinay Krishna, CSM, 23 November 2009
  12. Understanding the Scrum Burndown Chart, Dusan Kocurek, ScrumDesk Link: www.methodsandtools.com
  13. How To Implement Scrum in 10 Easy Steps, Kelly Waters, 14 September 2007
  14. Your First 10 Scrum Steps, Ilan Goldstein, Aug 5, 2013
  15. 15.0 15.1 When to use Scrum, When to use Scrum for software projects, Kevin Thompson PhD
  16. 16.0 16.1 16.2 Deciding What Kind of Projects are Most Suited for Agile, Mike Cohn, January 15 2011
  17. Why Scrum Works, A case study from an agile distributed project in Denmark and India, Lene Pries-Heje and Jan Pries-Heje
  18. 18.0 18.1 Link: www.scrumcrazy.com
  19. When should you not use Scrum?, August 21, 2013, Link: www.leanagiletraining.com

Further readings


Personal tools
Namespaces

Variants
Actions
Navigation
Toolbox