Ville T. Heikkilä

Inter-team coordination in large-scale globally distributed scrum: do scrum-of-scrums really work?

Scrum-of-Scrums meeting is mentioned in the literature as the mechanism for handling inter-team coordination in large-scale Scrum. However, how to implement it in projects with tens of teams is not explained. In this paper, we present a multiple case study on how Scrum-of-Scrum meetings were applied in two large-scale, globally distributed Scrum projects both employing at least twenty Scrum teams. We conducted 58 semi-structured interviews of project personnel, including managers, architects, product owners, developers and testers. Our results show that Scrum-of-Scrum meetings involving representatives from all teams were severely challenged: the audience was too wide to keep everybody interested and the participants did not know what to report that might be valuable to other teams, often ending up not reporting anything. As a solution, one of the case projects introduced feature-specific Scrum-of-Scrums meetings for 3-5 teams working on the same feature, which turned out to work well. However, challenges with coordination at the project level remained. The other case organization tried a site-based SoS structure that still did not work well.

Teaching students scrum using LEGO blocks

In this paper, we present a LEGO-based Scrum simulation game that we used twice with Master’s level students at Aalto University. The game was initially developed as an internal training tool in F-Secure Corporation, a Finnish security software company, to support their agile adoption. In the game, student teams learn the Scrum roles, events and concepts in practice by simulating several development Sprints, while incrementally planning and building a product of LEGO blocks. Student satisfaction was measured by a survey at the end of the course, and student learning evalu- ated by learning diaries. Our results show that the students were highly satisfied with the game, and that students with various degrees of experience with Scrum all learned a lot. In particular, students reported gaining insights about require- ments management and customer collaboration, effective teamwork, and the Scrum roles.

Integrating Global Sites into the Lean and Agile Transformation at Ericsson

Transforming a large organization from a plan-driven process to agile development is challenging. Despite this, large organizations are increasingly adopting agile development and lean thinking. However, there is little research on how to conduct a successful transformation in large organizations, which often are globally distributed. In this paper we discuss how one R&D unit of Ericsson integrated three global sites into their lean and agile transformation involving 400 persons in Finland, Hungary and the US. We describe the challenges and success factors in integrating the global sites. We collected the data by 45 semi-structured interviews and longitudinally observing the transformation during over 20 site visits. Success factors include: early and broad involvement of global sites at all organizational levels, constant communication and cross-site visits, and creation of joint infrastructure. The challenges include: creating a shared understanding of the change, enabling end-to-end development, bridging cultural differences and creating transparency.

Continuous Release Planning in a Large-Scale Scrum Development Organization at Ericsson

Scrum development at large-scale requires a release planning process that supports the agile way of working and planning. Most of the existing release planning processes are plan-driven and ill suited for a large Scrum organization. This case study describes how release planning was conducted in a 350-person Scrum development organization with over 20 teams at Ericsson in 2011, and the related challenges and benefits. Data was collected with 39 interviews which were transcribed, coded and analysed. The release planning process was continuous and characterized by regular scoping and prioritization decisions, and by incremental elaboration of features. The challenges were the overcommitment caused by external pressure, managing non-feature specific work, and balancing between development efficiency and building generalist teams. The benefits were the increased flexibility and decreased development lead time, waste eliminated in the planning process, and increased developer motivation.

Experiences in Scaling the Product Owner Role in Large-Scale Globally Distributed Scrum

The Product Owner in Scrum is a crucial role responsible for managing customer requirements in the form of prioritized backlog items and communicating them to the Scrum team. When scaling Scrum to large projects consisting of tens of teams, one Product Owner is not able to work with all the teams; thus the role needs to be scaled. While the literature suggests different scaling approaches, e.g. the use of Area Product Owners, reported experiences of scaling this role are scarce. Based on 58 semi-structured interviews, we report experiences of scaling the Product Owner role in two large globally distributed projects, each with 20 or more Scrum teams. Lessons learned include having local product owner representatives at each site, forming a product owner team, relying on frequent communication between the Product Owner representatives and the Scrum teams, as well as keeping and communicating clear priorities of the backlog to all stakeholders.

Rigorous Support for Flexible Planning of Product Releases - A Stakeholder-Centric Approach and Its Initial Evaluation

This paper addresses the problem of product release planning in iterative product development. We propose a method which combines decision, process, and tool support. The method, which is called SCERP, facilitates the active involvement of stakeholders in the different stages of the planning process. SCERP is flexible in the number of stakeholders involved, in the number of releases, in the number and definition of planning criteria, and in the selection of the best plan out of a set of optimized alternatives. A proof-of-concept of the method is given by a case study of release planning for a tool called Agilefant, which is developed with a process partially based on Scrum. The benefits of the method as demonstrated by the case study are: (i) better decisions by the product manager by relying on more objective information, (ii) more transparency of release decisions, and (iii) efficient tool support accompanying the whole process.

Operational release planning in large-scale Scrum with multiple stakeholders – A longitudinal case study at F-Secure Corporation

Abstract Context The analysis and selection of requirements are important parts of any release planning process. Previous studies on release planning have focused on plan-driven optimization models. Unfortunately, solving the release planning problem mechanistically is difficult in an agile development context. Objective We describe how a release planning method was employed in two case projects in F-Secure, a large Finnish software company. We identify the benefits which the projects gained from the method, and analyze challenges in the cases and improvements made to the method during the case projects. Method We observed five release planning events and four retrospectives and we conducted surveys in the first two events. We conducted six post-project interviews. We conjoined the observation notes, survey results and interviews and analyzed them qualitatively and quantitatively. Results The focal point of the method was release planning events where the whole project organization gathered to plan the next release. The planning was conducted by the development teams in close collaboration with each other and with the other stakeholders. We identified ten benefits which included improved communication, transparency, dependency management and decision making. We identified nine challenges which included the lacking preparation and prioritization of requirements, unrealistic schedules, insufficient architectural planning and lacking agile mindset. The biggest improvements to the method were the introduction of frequent status checks and a big visible planning status board. Conclusion The release planning method ameliorated many difficult characteristics of the release planning problem but its efficiency was negatively affected by the performing organization that was in transition from a plan-driven to an agile development mindset. Even in this case the benefits clearly outweighed the challenges and the method enabled the early identification of the issues in the project.

A Revelatory Case Study on Scaling Agile Release Planning

A way to scale up agile release planning to meet the requirements of multi-team agile development is a practice called joint release planning. A software product company piloted the joint release planning method. The aim of the company was to improve coordination of work of multiple agile development teams who develop a large legacy software product. Another aim was to improve communication between product management and development. We conducted a case study to explore how the new release planning method was executed. We gathered data by observing two release planning events, observing event planning meetings, and by conducting surveys. The events were attended by approximately 140 stakeholders, including over 10 development teams, who spent several days in a common space. The participants liked the method and considered it efficient. This revelatory case study provides the first detailed empirical description of this emerging method for multi-team agile release planning.

Teaching university students Kanban with a collaborative board game

Kanban is a workflow management method especially suitable for managing continuous software engineering work. We attempted to teach Kanban and lean thinking in a software project management course in Aalto University with a collaborative Kanban board game. Our goal was to measure if the learning goals of the class were reached and to study the students perceptions of the game. Data was collected from two subsequent classes in 2014 and 2015. Quantitative data was collected with questionnaires and analysed descriptively and statistically. Qualitative data was collected from 57 learning diaries. The students perceived they had learned substantially from the game. They also evaluated the game very positively. However, the qualitative results and the measured learning indicated that the learning goals were only partially reached. The enjoyable game experience did not fully translate into effective learning.

Do high and low performing student teams use Scrum differently in capstone projects

In this paper, we present how student teams appliedScrum in their capstone projects and compare how the Scrum usage differed between the high and low performing teams. 16 student teams of 7–9 persons were taught Scrum during a lecture and a 4-hour Scrum simulation game, after which they applied Scrum in their capstone projects developed for external industrial customers during a six month period. We collected data by surveys (98 responses) and by interviewing all 16 teams at the end of the course. Our results show that the frequency of Scrum practice usage does not differ significantly between the low and high performing teams. However, the interviews showed that the high performing teams applied Scrum practices more thoroughly, e.g., by taking better advantage of the retrospective meetings and Daily Scrums and working more face-to-face, while low performing teams paid less attention to the proper way of applying the Scrum practices.