Scrum method

Developed by Jakob Rolfsson

In the early days of software development, the usual waterfall method used for product development turned out to be inefficient and problematic for software development teams. As software development is different from other kinds of projects e.g. building a house, where every detail has been planned in advance, software oriented projects can constantly change along with the needs of the customer. It can be difficult and complicated to describe to a programmer which functions you want in a program and how they should work and more than often the outcome of the project does not satisfy the customers need. It was therefore necessary to come up with a new method more fitted to the ever changing environment of software development projects. The method developed is called Scrum and is an iterative agile software development framework. By being agile, Scrum ensures that everyone involved in the task know where the project stands, what tasks are left and status of ongoing tasks. Scrum encourages the team to share knowledge and help other members in the team to finish the task as fast as possible i.e. Scrum is focused on fast output of tasks and adapting to changes in demand from the client or market. The output of the project is therefore a customized solution which fulfills all of the client's needs.

History

The initial concept of Scrum was developed by Hirotaka Takeuchi and Ikujiro Nonaka in their paper "The New New Product Development Game" which they published in 1986. In it, they came up with a new faster and more flexible approach to managing product development processes. They described it using a rugby team, where the team passes the ball within to reach a common goal or in other words, the project team works together and help each other to reach the projects goal. In it they argue that teams do better when given goals instead of the usual tasks. The team would then figure out how to reach the goal and overcome obstacles to reach the goal in the most efficient way.

In the early 90's Ken Schwaber and Jeff Sutherland began developing the Scrum method more and presented the method at the OOPSLA(Object-Oriented Programming, Systems, Languages & Applications) conference in 1990 along with the paper “SCRUM Software Development Process”. In it they provided principles to develop and sustain complex software products which were in the end used to create the Scrum framework.

Concept

The Scrum Framework

The definition scrum provided by the Scrum guide is the following : "A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value". Scrum is not a technique or a process but rather a framework which provides you with processes and techniques. The Scrum framework contains roles, events, artifacts and rules applicable to the Scrum team which are lightweight, easy to understand but difficult to master. Scrum takes an empirical approach to projects i.e. decisions made are based on what is known instead of trying to be predictive as in the Waterfall method.

To gather as much knowledge as possible Scrum uses an iterative, feedback driven approach to control risk and optimize predictability which is supported by three pillars made of transparency, inspection and adaption. These iterations are called Sprints and are usually 2-4 weeks long. Before each sprint, a meeting called Sprint Planning is held were the Development Team decides which items from the Product Backlog should be done in the upcoming Sprint. When the sprint is done, a Sprint Review is held with the purpose to see which Increments have been added to the solution, what problems were encountered in the Sprint and to receive feedback for the work done in the Sprint. This process then repeats itself until the project is finished.

To document the projects progress, as visual tool called a Scrum Board is used to display where the project stands. This visually represents every task that needs to be done, has been done or is in progress.

Scrum Values

When the team follows the values of Scrum, the three pillars of transparency, adaption and inspection come into effect and helps in building trust among the team members. By using the tools Scrum provides, the team members explore these values.

Commitment

Each and every team member commits to achieving the ultimate goal of the project.

Courage

The team members have the courage to take the right decisions and do the right thing in the most difficult situations.

Focus

The team members focus on work do be done in the Sprint and the goals of the project.

Openness

The team members and the customers/stakeholders are open about all the work and challenges they run into.

Respect

The team members respect each other skills.

The Scrum Team

The Roles of Scrum

The Scrum team is made out of three core roles, the Product Owner, the Development Team and the Scrum Master. The team itself organizes how it is best to reach the objective instead of be given instructions to do so. The team is cross functional so all necessary knowledge is within the team to finish the project without having to depend on outsiders. This team model is designed to improve flexibility, creativity and productivity.

The Product Owner

The Product Owner is the key stakeholder of the project and is responsible for maximizing the value and getting the most out the Development team. The key is that the Product owner has a vision of what the stake holders want the outcome of the project to be and he conveys that vision to the development team by using the product backlog.

He must have a good understanding of the needs of the customer, the marketplace, the competition and how the future can affect the current project.

His role is not to have a decisive factor in how much work should be done, but rather to motivate the team to perform at its greatest by giving them a clear elevating goal. The Development team itself chooses how much work to be done in each sprint, as they withhold the knowledge of how much work can be done in each Sprint and how time consuming tasks can be.

The Development Team

The Development team is a cross functional team with the purpose of creating the projects solution through the product backlog provided to them. They are free to use any method necessary to reach the current sprints goal. By working together and having no clear roles, the cohesiveness of the team increases along with boosting the productivity and creativity of the team, often leading in faster delivery of the product. The optimal size of the development team is between 3 and 8 people. Smaller than that can lead to that there are not enough resources to finish a sprint and any larger than that means that too much time goes into coordination of the team.

The Scrum Master

The role of the Scrum Master is to make sure that the Development Team follows the rules and practices of Scrum. He is responsible for removing obstacles that can be in the way of the Development Team so that they are able to perform at their highest. He is generally present to help the team to use Scrum by motivating and reminding the team of the projects ultimate goal. He plans Scrum events for the team and all in all helps the team create a high value product. He has no clear authority over the Development Team but rather authority over the process itself. He helps the Product Owner to find techniques for effective management of the Product Backlog and how to maximize the value of it, and helps the Development Team to understand what is expected from each Product Backlog.

Terminology

Artifacts

The Artifacts of Scrum are Product Backlog, Sprint Backlog and Increment. These artifacts help to gain transparency on the work done, and to detect opportunities for adaption or inspection. By adding transparency to the project, each and every member of the Development Team has an easier time of understanding the needs of the project.

Product Backlog

The Product Backlog is a list of tasks that need to be done in order for the product to be developed or changed. It includes all functions, technologies, requirements, enhancements fixes and features that the product should consist of. The items in the backlog have a description, order, estimations and value.

The tasks are generated from User stories which originate from the customer requirements. The Product Backlog is prioritized by the Scrum Master and the Product Owner (who is responsible for the Backlog) so that the project/product generates as much value as possible.

As Scrum is an agile framework which consists of using only the known requirements, the Product Backlog is never complete. It keeps on evolving along with the project itself i.e. it behaves dynamically along with the product needs.

Sprint Backlog

The Sprint Backlog is a list of tasks generated from the Product Backlog in the beginning of each sprint in addition of a detailed plan on how the sprint should be done. It will predict which functionalities will be available in the next Increment of the product.

The Development Team is responsible for setting up and estimate what needs to be done and how it will be done in order to finish the tasks they place in the Sprint Backlog.

A classical Scrum Board. Note the tasks represented as Post-it notes

The progress in each sprint is monitored so that for daily Scrum meetings the team can coordinate their efforts to finish the Sprint on time.

Increment

Increments are all the Product Backlog items completed during a Sprint along with the value of all the Product Backlogs finished in previous Sprints. At the end of each Sprint, the items in the Sprint Backlog must be finished and in a useable condition.

Scrum Board

The Scrum board is a visual representation of the status of the project. It is a preferably a physical document where one can see all the items in the Product Backlog, whom are prioritized and the state of each item. This tool is important for daily Scrum meetings as it helps giving the project a certain transparency and simplicity. A whiteboard is often used to represent the Scrum Board. It is split up into few columns to show the status of each task and tasks are represented with post-it notes.

Daily Scrum Meetings

This meeting should be no longer than 15 minutes and is used to synchronize activities and establish what is today's agenda. Each and every member of the development team explains what they did the day before, what they will do to today, do they identify any impediments.

A Burndown Chart. Note the difference between the planned and actual time

Sprint Planning

Is a plan of what work should be done in the Sprint. The goal of the Sprint Planning meeting is to know: "What can be delivered in the Increment resulting from the upcoming Sprint?" and "How will the work needed to deliver the Increment be achieved"

Sprint Retrospective

This meeting serves as an opportunity for the Scrum Team to inspect and improve itself and the Scrum methods the team is using. The Scrum Master is responsible for this meeting to take place. The improvements identified will then be implemented in the next sprint.

Burndown Chart

A Burndown Chart is a graph which estimates the time length of the project. On the Y-Axis is the sum of task estimates of the project and on the X-Axis is the time until the project is finished.

Application

The Scrum Process

Once the initial Product Backlog has been made, it is presented to The Development Team and they will hold a Sprint Planning meeting to determine which items should be prioritized, how long the first sprint should last and set a sprint goal. During the sprint, daily meetings are held in order to optimize the efficiency of the team and remove impediments which have occurred during daily operations. These meetings can be beneficial to the individuals in the team as this gives them a status on what was done yesterday and plan what should be done today. If they expect or have had any impediments they can notify their team members during the daily meeting and they can work together on how to resolve the impediment.

The Scrum Board is important as it monitors the progress of the project. On it, the Product Owner can see which tasks are done and which tasks need to be done to finish the project. The progress is then charted as a Burndown Chart which gives an estimate for the completion of the project. The board is continuously updated along with the projects alterations so that it represents the correct information for each daily meeting.

After the Sprint a Sprint Review meeting is held. There the stakeholders and the Development Team come together and review what Increments have been done during the sprint and identify improvements or problems with the items in Product Backlog. These meetings serve mainly as an feedback for the Development Team and to get a overview of the status of the project, which items are done and the remaining tasks of the project. If the Development Team was not able to finish all the items in the Sprint, The team needs to clarify the reason why it is not finished to the Product Owner. The outcome of this meeting is then used as a basis for the next Sprint Plan.

A Sprint Retrospective is then held to improve the overall process of Scrum of the team. Improvements and problems are identified and are implemented/resolved in the next Sprint Plan. After the retrospective the team is finally ready for the next iteration of the project.

Advantages

Advantages of Scrum method are many. As the Scrum framework is agile in its nature, it is especially effective for software development as it is transparent and keeps a clear goal of what is to be achieved with the project. The advantages of the scrum method are the following:

• Scrum helps the developer to save time and money
• Large projects are easy to quantify using Sprints
• After each Sprint a useable product is present
• The development of the project is visible, clear and transparent
• It requires regular feedback from the user
• Because of the feedback, it is easy to cope with changes in demand
• Issues are easily resolved in the daily meetings
• Individual effort is visible through the daily meetings

Disadvantages

Although the method is simple and easy to adapt there are some disadvantages that are to be recognized:

• It can lead to Scope Creep as no definite end-date is set. If no end-date is set, the customer can request new functionalities which delays the projects deadline indefinitely
• Team size can not be any larger than 9 people, otherwise management becomes to difficult
• Team members need to have experience to be able to estimate time on the project
• If the team members are not committed, focused or cooperative the project has a is unlikely to be a success
• Quality is hard to implement, until the team goes through aggressive testing process
• If a team member decides to leave the project before the finish deadline. It can have a huge negative effect on team morale and project outcome

Agile Scrum in relation to Non-Software Projects

Graph illustrating the categories of Agile Readiness Assessment

Although Scrum and Agile methods were originally made with software development in mind, using these methods in project which does not produce a software can be highly beneficial. It can though be quite the challenge. For starters, most of the Agile literature available today focuses on delivering "functional software". Secondly there are often numerous high-profile stakeholders with conflicting interests and lastly, the unavailability of industry-established metrics to measure non-software projects.

To determine if the project needs Agile management it needs to land in the Simple category when the Agile Readiness Assessment is made. It revolves around four key factors:

• How well do the stakeholders know the requirements?
• How well do the stakeholders know the technology?
• Are there conflicting interests from different stakeholders?
• Is there a high risk of failure?

To help implement Agile on non-software projects, a five step method has been defined to make it easier to execute Agile:

• Define Working Software: Deliverables that create value for the customer are not always a functional software. It can be for an instance a new process or a roadmap.
• Define Customer: When thinking about software, the customer is usually the front end user, but in the non-software world, identifying the customer can be challenging. The customer is typically the stakeholder/s of the project but often they have conflicting interests and priorities. Choosing the right Product Owner is then critical as he can help balance those interests.
• Define Done: To figure out when each deliverable is done, cooperation is needed between the product owner and the sponsors. It is important to set a criteria when a deliverable is a success.
• Measure Business Value: Establishing the business value and measuring it is crucial for every non-software project. Before each iteration, clearly state the cost benefit of going through the iteration and articulate these benefits after each iteration. Metrics for measuring these non-project initiatives should be defined beforehand.
• Expect the Unexpected: As strategy and consulting projects are turbulent during the brainstorming phase, use short iterations, joint workshops, paired development of deliverables and expert and peer reviews.

Further Reading

• Scrum Is Not Just For Software by Robbie Mac Iver: This article goes through some key points on how and why Scrum can be implemented in the majority of projects.
• Agile Retrospective, Making Good Teams Great by Esther Derby and Diana Larsen. Goes through problems that can come up during the Scrum process and how to deal with them appropriately and overall enhance the Scrum experience of the whole team.
• Agile Project Management With Scrum by Ken Schwaber. Ken Schwaber gives an excellent explanation of the theory of Scrum and how to implement it in real life scenarios.