Case study of use of Scrum

Abstract

This article is a case study of Sweco's use of Scrum in its Danish software division Digital Drift & Forvaltning (Digital Operations & Management) or DDF for short. DDF is a software division which develops software solutions for mainly Danish municipalities and Utilities companies. They currently have nine software solutions on the market which they are continuously maintaining and improving upon. Therefore, Sweco utilize Scrum to better manage different project and teams. Sweco and DDF are working towards being the Nordic leader in Digital operations and management solution. The article will cover, an introduction to Scrum, an introduction to Sweco and Digital Drift & Forvaltning, and how Sweco use Scrum on the daily bases.

Quick introduction to scrum

Scrum is an agile project management framework. This means that Scrum is a continues process that can utilize its learning as the project moves along. Scrum work by focusing the development process into smaller tasks. These tasks then put into a so-called Sprint backlog. A Sprint is a period of time, usually 1-4 weeks. In this sprint the team is working on the given task in the sprint backlog, which is the list of tasks for the sprint. By the end of a sprint the teams evaluate how the sprint and the task have proceeded. Throughout the sprint, the teams have stand-up meetings. These meetings are short, 15-30 mins, where each member present what they are working on and what troubles they may have. Here the members can help each other by sharing their ideas. When a sprint has ended the finish task will be added to the product backlog, to help manage these sprints as well as the project. Members of the teams have different roles. There are mainly three roles. Product owner (PO), the Scrum Master and the Development Team. The PO is the person who set the direction for the product. The PO is the one that decides whether something gets developed. The PO is the one who take ownership of the product, hence the name product owner. A Scrum master is the person managing and supporting the Scrum. It is the Scrum master’s job to align the team and facilitate the development in the team. Then lastly there is the Development Team. They are the main part of the Scrum team and are responsible for the development.

Case study

Introduction

Sweco is properly most know as an architect and building consultancy firm. And this is their main business. However, at Sweco Denmark they also have built a large software business, Digital Drift & Forvaltning, DDF. In this business department of Sweco, they are developing software solutions for mainly Danish municipalities, focusing on operational and management software solutions. Sweco are currently providing nine different software solutions with two of their larger software solutions being DriftWeb and RenoWeb. To efficiently manage the development of these software solutions Sweco has implemented the Scrum framework into its daily operations. Teams Within the DDF there are multiple teams. Each teams have a certain role in the division. Some of the teams has a business-related role. Meaning that the teams are not necessarily involved in the development of the software. Then there are the teams which are directly involved with the software development. Some of the teams which are directly involved with the development, are the development teams. Here DDF has several teams where some teams are working on a specific product or product group, and a couple which are working crosswise between the products. These development teams consist of about 3-10 people. Each development team has their own product backlog. These development teams are managed by the Product Owner (PO). These teams have daily stand-up meetings where they discuss and help each other out. These stand-up meetings are also used for teams’ information of estimating time for the next sprint. Once a week other teams related to the product are invited to the daily stand-up. This is often the support team since the support team is the one in direct contact with the users. This is so that the teams can share information and viewpoints. The support team is another team which has somewhat influence on the development. This is because they are the ones who talk with the users and learns how the end users use the product. They can the report their learnings to the development teams via the Product Owner. Whenever the support team learns of a bug or an improvement wish, they create a ticket in the development teams’ Scrum project board. Here the Product Owner reviews the ticket and place it in the product backlog in order of priority. Bugs are usually high priorities and a developer in the team starts working on it immediately. The Product Owners also has their own team. Here the Product Owners also discusses alignment of their software, so that it is clear to the costumers that all these software solutions are from Sweco. They also share knowledge on integration with other systems, for example Datafordeler, a public data agency.

Roles

Within Scrum there are different roles. Sweco has adopted these roles as well. For each product or product group. There is a Product Owner, a Scrum Master, and members of the Development Teams. The Product Owner is responsible for the management and development of the products. Each Product Owner has a single team of developers connected to a given product or product group. It’s the Product Owners job to manage these teams so that the development can move forward. Each product has a backlog. Whenever someone has an improvement idea, task, or a bug, they create a ticket, where they describe the issue, whenever it is a certain problem, an idea, a task, or a bug. The Product Owner then makes decisions on rather or not this should be moved to the product backlog. The tickets created in the product backlog are usually created by the Product Owner, the development team, the support team, or the consultants. The Product Owner then plans a sprint together with the developer in the team. Depending on the product, a sprint can be from one week to a month. Here the Product Owner plan the team’s resources and moves the ticket from the product backlog to the sprint backlog. When the team is in the sprint the developers are only working on those tickets in the sprint backlog, except for critical bugs. When the sprint is over, the development team and the Product Owner evaluates the sprint and puts the resolved tickets into the next release. The Scrum Master is the person responsible for establishing the Scrum. Meaning that it is the Scrum Master’s job to aid the workflow and support the development team. The Scrum Master is often the one controlling the meetings and managing the status of the tickets. Sometimes the Scrum Master is also part of the development team. The members of the development team are the developers. They are the ones programming the products. The developers are assigned to a ticket by the Product Owner or the Scrum Master. They are then working on the given ticket. The developers are working closely together with the Product Owner. The developers often have different focus areas, some are backend or frontend developers. The frontend developers are the ones working on the user interactive side of the system. While the backend developers are working more on how the system is tied together. Within each team there is around 3-10 developers. Beside these Scrum roles, which are more within the development site of DDF, there are different teams which also have an influence of the development products. These roles are the leaders, supports, and consultants. The leaders have some goals for the business division and therefore wants to push the development in a certain direction. They do this together with the Product Owner. The leaders are also the ones responsible for the resources allocated to the products and product groups. The supports have the direct contact with the users and clients. Therefore, they have specific knowledge of the user’s wishes and needs and translate these to the Product Owner. In a similar way the consultants have contact to users and clients like the supporters, but the consultants are often also working within the products as well.

Tools & Methods

To manage the productivity of the teams, Sweco’s DDF utilize management tools like Atlassian© Jira. Each team has its own project in Jira. These projects are setup to have dashboards which showcase the needed information and the progress. For the different development teams, these dashboards appear relatively similar. In the development team’s Jira projects, there is a product backlog where all new tickets get placed. The tickets can have different status depending on the process of the ticket. The project also has the spring backlogs. All the tickets connect to the sprint. And all tickets will be present in this board. These boards are Kanban boards. A Kanban board is a project managing method of easily structuring tasks. A Kanban board has the progress of tasks horizontally. These progresses could be to-do, in progress, and done. Each member is listed vertically on the same board. This gives an easy overview of what each other are working on and the progress of the members tasks. Doing the stand-ups each member discusses progress. Here the Kanban board can help the product owner reassign tasks if needed. Thought Jira each employee can also make their own dashboard. So that they can better focus on their own tasks. Jira also allows for a statistics report visualization. This allows for easy insight to the team’s progress. All teams within DDF use Jira and have their own project with some general dashboards, which is often product specific. But members can also make their own dashboards to help them structure the day.

Workflow

The workflow at DDF is based around the Scrum framework with the development teams in focus. The development team has the project with a product backlog and sprint backlog. The workflow of the other teams is also based on Scrum. The other team’s tickets are by the members themselves. Each ticket is assigned to a member who is resolving the issue. If the issue needs, or is for, the development team, i.e., a wish for improvement, a task, or a bug, the other teams create a linked ticket to the development team. This is done by the approval of the Product Owner. Then the original issue change status to ‘awaiting implementation’. The ticket created for the developer, is in status ‘new’. When the Product Owner review the level of priority, the ticket is placed in ‘open’ or ‘ready for revision’. To make sure that the developer has the needed information, the use of templates is valuable. These templates force the reporter, the one who created the ticket, to explain the issue or idea and how to reproduce it. Giving the developer a clear picture of what is the issue or idea. The Product Owner also prioritizes the tickets so that the developer knows which one to start on next. For example, a bug is prioritized highly until its severeness has been clarified by the developer. From this clarification the bug can either be fixed immediately or fixed thought a sprint. When planning a sprint, the Product Owner looks at the product backlog of tickets and select the ticket needed for the next sprint. Then the ticket is placed in a sprint backlog. The Sprint board is linked to the ticked. The status of the ticket is then based on the progress of the development. For tracking the progress, the development teams have a Kanban board. The different progress stages links to the status of the ticket. When a ticket is resolved, it receives the status ‘done’. The ticket is then linked to the coming release board. When the ticket is released, it receives status of ‘released’. This is the general workflow. Although for some products there may have been more statuses in between, like ‘revision’, ‘estimation’, and ‘test’. When the ticket is released, the report of the original ticket gets notified so that they can report back to the customer or client. Then the original ticket gets status ‘resolved’ instead of ‘awaiting implementation’.

Reflections

I personally think that the Scrum framework it is the best way for structuring software development which is also what it was originally intended to be. Because software isn’t a physical thing, we can continuously change and improve upon it. This allows for an iterative development process. An iterative process wouldn’t be effective with more traditional methods. Hence agile and Scrum. It makes it possible to improve, fix, or change the software as time goes on. In case of Sweco and DDF for example, many of the software solutions are built around environmental guidelines and laws, which can change. Sweco’s/DDF’s waste management solution was designed when people only had one or two different types of waste in their homes, but now we have up to ten types. Although Scrum doesn’t allow us to change this, the software does. Scrum helps us be more well-structured and effective dealing with these types of projects or programs. Daily stand-ups are valuable meetings since it encourages people in the teams to collaborate and help each other out. The framework itself isn’t enough. Like a Kanban, KPI’s, or other dashboards, can help structuring the daily development. In the end Scrum is a great way of structuring developments, especially in software development. In my opinion many other industries could utilize the Scrum framework.

Reference

Bente Kjærsgård Henriksen, Product owner for MiljøWeb, JordWeb.dk, and Bygningsaffald.dk.

Lea Taggaard, Business Unit Manager, Software Department.

Scrum.org, The Scrum organization, who train people in Scrum, www.scrum.org

Atlassian.com, Jira, https://www.atlassian.com/software/jira

Atlassian.com, What is Kanban, https://www.atlassian.com/agile/kanban#:~:text=In%20Japanese%2C%20kanban%20literally%20translates,in%20a%20highly%20visual%20manner.