The Scrum framework

Abstract

In the complex technology and business world we live in today, there is a need for project management practices that can be considered flexible. In for example product development, timing plays a huge role. Companies face growing pressure in delivering products quickly to the market. This pressure can result in many uncertainties and increase the rates of failures. These uncertainties can be linked to traditional project management methods being applied, where deterministic practices are being used. Resulting in companies not being able to evolve quickly or inexpensively enough when nearing the end of the development lifecycle. The ultimate goal is to deliver great customer value, Agile practices do that by constantly seeking involvement in product development e.g. from the customer. Evaluating and validating if what is being made is meeting the set business case . This business case sets the objectives and success criteria for the project. In agile project management this validation is done more often. Most often the success or the real benefits of a project can‘t be seen until the project has been done. It can be considered an advantage for project managed with agile methods having constant validation, and close relationship with the stakeholder and that it will result in target benefits being met and higher success rate .

Scrum is an Agile project Management framework, where projects are managed in short sprints or iterations. The control or project management is moved from the traditional central scheduling to the teams itself. Where individuals closer to the actual work take charge of the decision making. With this frameworks the feedback loop between customers and developers is much shorter, the progress is visible, inspections are done constantly and adaptations done when needed. . This is especially important in complex projects where companies have to be able to adjust to changes in scope or specifications. From that perspective it can be said that the Scrum framework is the opposite to deterministic project management approaches where detailed plans are being done with the use of e.g. Gantt charts and work schedules. These traditional planning methods use a bottom-up approach where the requirements are set and from the scope the tasks are constructed. In comparison to Agile practices the planning method is based on a top-down approach .

Background

In 2001 a group of 17 people which called themselves the The Agile Alliance met and from those three days they spent together the Manifesto for Agile Software Development emerged ". It can be said that these men started an Agile movement. Where in the beginning the main focus was to improve software development. When signing the Agile Manifesto you agree to follow a couple of principles, the following three were chosen as relevant for this article: Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. (Addresses how projects are managed all the way through the life cycle); Business people and developers must work together daily throughout the project (Addresses how Stakeholder management/involvement is); Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done ". This describes well how stakeholder involvement is seen. Ken Schwaber & Jeff Sutherland were apart of the The Agile Alliance that met in 2001, however approximately 10 years prior to that they had started developing the SCRUM framework. It was then in 2009 when Agile project management methods were flourishing, more organisation were using the Agile processes than the waterfall processes. From those Agile processes the majority was using the Scrum framework or 84%. In 2009 Ken Schwaber created an organisation Scrum.org and opened up the website: [www.scrum.org], reaching a broader audience and providing access to materials and courses. Ken Schwaber and Jeff Sutherland published the Scrum Guide in 2010".

The Scrum Team

The Scrum Team has three roles: The ScrumMaster, Product Owner and the Developers (The Team). It should be mentioned that even though one role is called Developers it does not mean that the Scrum framework is only meant for Software development. It was first developed for that purpose however now used worldwide within various organisations.

• The Product Owner represents the customers of the project. The Product Owner is in charge of making a plan that meets their vision and needs. That is done by setting up a Product Backlog, the Backlog contains both functional and nonfunctional requirements that have to be met to reach the goal or vision. This Backlog gets then prioritised, making sure that the Scrum teams starts with the main functionalities. With this prioritisation of functionalities a proposed release plan can be set. It is therefore the role of the Product Owner to priorities and decide what will be done during the sprint. This is then presented to the team during a Sprint planning meeting . The Product Owner manages the Backlog, makes sure that the backlog is well organised and the content visible. He is also the only person that can make decisions on adjusting/changing something in the backlog .

• ScrumMaster makes sure that everyone within the Scrum team knows the principles of Scrum and makes sure that everyone follows them. Another key role of the ScrumMaster is to remove any obstacles that might come their way, ensuring that the team can complete their work. The ScrumMaster is a role that is often filled by a project manager, however the ScrumMaster should not manage or define the work. The ScrumMaster should be managing the Scrum process, making sure that everyone is one the same page. As Ken Schwaber describes so well by comparing a ScrumMaster to a sheepdog, responsible for keeping the flock together and the wolves away.

• The Developers (The Team) is a cross functional team, that is self organising and self managing. Where the latter is key as Scrum teams should not be managed rather they are responsible for managing their own work and making sure that the job gets done during each sprint . It could be described as the team owns how it chooses to get the job done e.g. the functionalities. In comparison to the Product Owner that owns what should be done. The team is a relatively small, and usually consists of 5-9 people.

The Scrum Team are the individuals that are considered to be committed to the project. However Stakeholders or, people that are interested in the project are called chickens and pigs. There is a clear distinction of authority between these groups where the chickens and pigs are not able to interfere without having the proper authority and the Scrum team has the authority to do whatever it takes to make the project a success .

Application: The Scrum Events

Sprint

A sprint is where all the work takes place, often said to be the heartbeat of the Scrum Framework. The Sprints are fixed time boxes that are usually 30 days or less. When the sprints ends the next sprint takes over. The following events reside within one sprint: Sprint planning meeting, Daily Scrum, Sprint review and Sprint retrospective meeting,

Sprint planning meeting

May last up to 8 hours when preparing a 30 day sprint. (Sprint Guide) During the first 4 hours of the Sprint planning meeting the Product Owner introduces the Product Backlog (Ken Sch) to the Team and what has the highest priority within that Sprint. The whole Scrum Team attends that meeting as well as advisors when needed. From these priorities the Team assesses and selects the items that they will use during the Sprint. Lastly the

• Product owner: sets what has to be completed in that sprint
• Team: determines what actions are needed to get that done, the how

Daily scrum

• How the process is being tracked.
• Visual board is constantly being updated
• With columns like
• Bare minimum to do, doing, done. (Story, to do, In Progress, To verfiy, Done)
• In the daily scrum meeting the team meets together and moves tasks around the visual board.
• An explanation on how burndown charts give a good overview of the work done and how well the work is progressing. (Put in picture of burndown chart)
• Short description on agile project management tools existing to do so.

Sprint review

• Meeting that is after a sprint has been done
• There stakeholders are invited and provide feedback to the work done

Sprint retrospective meeting

• Is a meeting that the ScrumMaster leads and goes over what went well and what can be done better in the next sprint in respect to the Scrum process framework and practices, an action plan is made for the next sprint to ensure that the next sprint will be more effective and enjoyable than the previous one.

Release planning

• Short introduction on how that can be done for a quarter.

Benefits

• More transparency
• Ability to adapt to changes
• Better alignment
• Can resul in faster way to the market (references needed)

Limitation

• Some have concluded that agile methodology does not work at scale, Therefore argue that scaling Scrum is a possibility. Maybe introduce shortly the combination of agile and more traditional, in that case Safe can be mentioned (could link to an article here). Another point to consider is why the waterfall method shows a better overview for the customers to have a better picture of timing and how projects are being managed.