Scrum Methodology in Agile Software Development

Today market is affected by uncertainly and sudden changes, in these conditions most of the models used in the 20th century to develop software are not still appropriate. Waterfall model , probably the most famous between them, is characterized by a stiff structure which can’t cope with the turbulent needs of actual market. In recent years many innovations are been enhanced in software engineering with a particular focus on the flexibility of these methods in order to cope with the customer’s and market’s needs; surely Agile Software Development is between them; ASD embraces the principles of lean production by applying them in software development to avoid waste and increase responsiveness to change. It represents the solution to the unpredictability of the market where the capacity to welcome change even late in development to satisfy customers is required. This article deals with Agile Software Development with a particular focus on one of its most used technique : Scrum Methodology.

The big Idea

Scrum is an iterative method used to develop software, it can be placed inside the group of methods which are used in Agile Software Development. This word is taken from rugby and represents that phase of the match where an ordered formation of players, with arms interlocked and heads down, push forward against a similar group to gain possession of the ball. This method provides that work is divided into small chunks to manage complexity and to get early feedback from customers and end users; software development is carried out by small working team that allow rapid adjustment during the process and a quick delivery of the final product.

Agile Software Development

Some practitioners believed that traditional iterative model was not so responsive to changes that market required. They thought that to be Agile a process needs to accept change rather than stress predictability and that methods used to develop software has to respond to change as quickly as it arose rather than prevent changes.

It was in these circumstances that practitioners as Mary Poppendieck and Bob Charet started to take inspiration from Lean manufacturing principles and apply them to software development. These are the main points ,according to Poppendieck, which make Lean Production so successful and that can be applied to software development:

• elimination of waste that does not add value to the customer such as diagram and models that do not add value to the final deliverable;
• minimize inventory such as requirements and design documents;
• maximize flow by using iterative development to reduce development time;
• pull from demand;
• empower workers that means “tell developer what needs to be done not how to do it;
• meet customer requirements – work closely with the customer, allowing them to change their minds
• do it right the first time – test early and refactor when necessary;
• abolish local optimization – flexibly manage scope;
• partner with suppliers – avoid adversarial relationships, work towards developing the best software;
• create a culture of continuous improvement – allow the process to improve, learn from mistakes and successes.

Manifesto for the Agile Software development

A few years before Poppoendieck’s publication on February 2001 main principles of Agile Software development were stated by a group of 17 software developers which published “Manifesto for the Agile Software Development”([1])

Manifesto for the Agile Software development

From these few words it is possible to identify what are the innovations introduced by Agile model

• “individuals and interactions” the founders want to remark the power that has a group of developers. Every member is seen as a being able to be creative and collaborative. The stiffness of Waterfall model is instead represented by “processes and tools” in which people has to follow only what the plan requires.
• “working software “ : there is a clear reference to the new way to develop software where at every iteration a working program is realised, differently from the earlier model in which a working program couldn’t be seen until the end of the project. This feature is put over the “comprehensive documentation” which characterizes especially Waterfall model.
• “Customer collaboration” means that it has to be a straight relationship between customer and developer in order to define time by time the projects requirements and evaluate every realise.
• “Responding to change over following a plan” this sentence encloses the essence of Agile software Development that is to cope with turbulent markets by being flexible and by responding quickly to change, instead of being bound by planning. This concept is remarked by the founders in one of the twelve principles which follow the manifesto which says “Welcome changing requirements, even late in development […]”.

Application

Scrum Framework

There are two concepts that are at the basement of Scrum methodology: iterative development and team working. Developing in iterations allow Scrum team to adapt quickly to changing requirements, while working in close location and focusing on communication allow team to make decisions and act on them immediately rather than wait on correspondence.

Basically Scrum consists in a sequence of fixed-length iterations called Sprints managed by one or more cross-functional and self-organizing teams each composed by seven people that aim at a common goal and that usually work only on the software development. There are instead other two figures that manage all things that are in support of the development process: one is Product Owner who mainly handles customers contacts and the other is Scrum Master whose main task is to ensure that development team can work without obstacles.

Each sprint usually lasts from 2 to 4 weeks, in this period there are at least one meeting between the Product Owner and Development Team to define the main objectives; then there are short daily meetings held every morning to enhance communication and inform customers, developers, and managers on the status of the project, identify any problems encountered, and keep the entire team focused on a common goal.

Main figures in Scrum

Product Owner

Product owner is the link between customers and development team, he ensures that deliverables are in line with customers’ expectation and that stakeholders’ interests are fulfilled. He has also the task to fill out customer-centric items (typically user stories), ranks and prioritizes them before adds them to Product Backlog.

Usually development teams have only one Product owner, but differently from the Scrum master, he only takes care of the business side and does not interfere with the scrum team about the technological issues. At the beginning of each Sprint the Product Owner holds a Sprint Planning Meeting to state on which Product Backlog Items Scrum team will go to work during the next Sprint. In this phase he defines what are the most important items for that business, in according to customer’s needs.

Development Team

Development team task is to provide Product Backlog Items (PBIs) at the end of every Sprint in according with customers’ requirements after negotiating commitments with the Product Owner. Usually each team is composed by cross-functional members that allow an all-round software development; the main figures that there must be are a mix of software engineers, architects, programmers, analysts, QA experts, testers, and UI designers.

The size of the team is an important point, the group members' number influences capacity of people to communicate and work together: it is recommended that a scrum team is composed not more than nine people, usually seven.

Another important characteristic is the Self-organization of the group which facilitates members’ creativity and increases team cohesiveness: for this reason it is better to not change members of a team after they have worked together, especially if they had success in their project. After working together team members gain a mutual understanding that increases their capacity of team working, this synergy cannot be acquired if team are continuously changed.

A further point that characterized the good outcomes of a scrum team is location: people are most successful when located in the same room, particularly for the first few Sprints: this facilitates communication and information sharing.

Team self-organization

Team self-organization is a crucial point in the scrum methodology : with this concept it means that “it is told developer what needs to be done not how to do it”, they can autonomously choose the way to reach commitments. As it is said previously during Sprint execution, team members develop an intrinsic interest in shared goals and learn to manage each other to achieve them, for this reason self-organizing teams can radically outperform larger than traditionally managed teams. It has to be specified that an optimal self-organization takes time: it may be possible that for the first few sprints developers perform worse than when they work in the traditional way.

Some requirements are necessary to gain a good team self-organization:

• members are committed to clear, short-term goals;
• members can gauge the group’s progress;
• members can observe each other’s contribution;
• members feel safe to give each other unvarnished feedback.

Conversely there are some conditions that can hander self-organization:

• Geographical distribution: it is better if the whole team work in a room;
• Boss/work dynamics: each member has to consider the others as peer to facilitate a fair communication between them;
• Part-time team members;
• Interruptions unrelated to Sprint goals.

Scrum Master

The scrum master worries that Scrum team can work without obstacles but he has no management authority over them. Essentially he has the aim to:

• create an environment to promote team self-organization;
• support team in the achievement of expected goals;
• ensure that events (e.g. daily Scrum meeting) take place in the right way;
• keep Scrum artefacts visible (Product Backlog, Sprint Backlog, Sprint burndown chart …);

Sprint

Sprint (or iteration) is the fundamental unit in which the work is divided; it is characterized by a fixed length of 2 weeks or 30 days and by a goal to achieve. At the beginning of each sprint Scrum team , Product Owner , Scrum Master and sometimes also stakeholders hold a meeting, called Sprint Planning meeting whose output is the Sprint Backlog where goals and requirements of the next Sprint are defined. Then other meetings inside development team will be held in order to define in more detail how achieving the common goals stated in the previous meeting.

Scrum Meetings

Scrum Meetings

Meeting are a fundamental tool used during the whole Scrum process. Usually they are facilitated by the Scrum master who has no decision-making authority over them . There are different typologies of meetings according to the different phase of the process in which we are.

Sprint Planning Meeting

At the beginning of each Sprint, the Product Owner and team hold a Sprint Planning Meeting to define on which Product Backlog Items (PBIs) they will go to work during the next Sprint. The Product Owner is responsible for declaring which items are the most important to the business. The team is responsible for selecting the amount of work they feel they can implement. In this phase in perfect Lean perspective the team “pulls” work from the Product Backlog to the Sprint Backlog. At the end of the meeting the selected items are broken into a provisional list of Sprint task. The maximum time that can be used to do Planning meeting, known as timebox, is of eight hours.

Daily Scrum and Sprint Execution

During the sprint every day members of the Scrum team hold a fifteen minutes meeting where they take stock of the situation. Usually they speak about what they did previous day, which impediments they faced and what they are going to do in the current day. To make these meetings shorter it is better that people are standing. During sprint execution it is common to find out additional tasks necessary to achieve sprint goal; to keep the control over processes during sprint development it could be useful to maintain a current Sprint Task List, a Sprint Burndown Chart, and an Impediments List: these are some artefacts that allow developer to understand where the project is located.

Sprint Review Meeting

At the end of every Sprint it is held a Review meeting where the scrum team has to explain to the Product Owner what they did during the previous sprint. Usually this meeting consists in a live demonstration of the working product increment after which Product Owner states which Items can be considered as done. Items which are declared not done have to return to the Product Backlog to be ranked and reprioritized by the Product Owner with the help of the Scrum master. Last step of this meeting is to convert stakeholders’ feedback to a new Product Log, this task is consigned to both Product Owner and Scrum Master. The Sprint Review Meeting is the appropriate meeting for external stakeholders (even end users) to attend.

Sprint Retrospective Meeting

During this meeting every member of the scrum team inspects his behaviour to identify some impediments that he faced during Sprint. There are mainly three kind of impediments in which developers can be involved:

• people who conduct performance evaluation are an obstacles to transparency of the team;
• human tendency of someone in the team to jump to conclusions and propose actions too quickly;
• geographical distribution of the team can be an impediments, team work better if they are delimited in a small place like a room.

After identifying all these impediments Scrum master has the task to eliminate them.

Backlog Refinement Meeting

Especially at the beginning of the project most of the Product Backlog Items (PBIs) need refinement because they are too large and poorly understood. In the Backlog Refinement Meeting, the team gave an estimation of the work left to complete Items in the Product Backlog and provides other technical information to help the Product Owner prioritize them.

Artefacts

Product Backlog

Product Backlog

It is defined before the project beginning and then upgraded during the Backlog Refinement meeting ; it is made up by the whole group of items which have to be completed during the project in order to realize the final product. Every item is ranked and constantly reprioritized by the Product Owner. It is important that Product Backlog Is visible to the stakeholders.

Product Backlog Item (PBI)

An item specifies what has to be done but not how do it. Usually they are written in a User story to be understood also by stakeholders. Every items has a work load of 2-3 days and requires 2-3 people. It represents the basic unit of Product backlog.

Sprint Backlog

Sprint backlog

It is defined at the beginning of each sprint during the Sprint Planning meeting where committed items and the main task that have to be done during the sprint are identified. It has to be visible to Scrum team and it can be upgraded during the sprint execution with additional task necessary to achieve the final goal.

Sprint task

Every item is divided into several tasks, each of them requires one day or less of work. A sprint task specifies how to achieve what is required by PBI. If the task takes more than one day of work, remaining effort is re-estimated daily, typically in hours.

Sprint Burndown Chart

Sprint Burndown Chart

This tool is used to facilitate self-organization of the team. It indicates the total remaining team task hours within one Sprint. Usually chart shows a decreasing line but if there are some re-estimation it may be possible that line increase for then going down.

Limitations

Scrum method was often used in the object-oriented software development. Actually this technique are applied not only on software but also on other products from different sectors like wheelchairs, semiconductors and mortgages. Scrum has to be used in those projects where people cannot rely on the plan-driven approaches like Waterfall, cause of unknown requirements and technology.

Predictability of a Project

Conversely if the projects is placed under precise and stable conditions it is better to use one of the traditional model which allow to have a fixed planning over the whole project. In this case Scrum method would involve in a waste of resources and money because he is working on a field that is not its responsibility.

Michael James in his “Scrum Reference card” explains with a simple graphics in which conditions Scrum should be used and which ones are not. James defines the predictability of the projects on the base of two features: knowledge of the requirements and knowledge of the level of technology required. A project which provides known requirements and a known level of technology should be carried out with a plan-driven model. It these conditions are not met it is better to use an empirical approach like Scrum.