Nils Brede Moe

Anastasiia Tkalich, Nils Brede Moe, Rasmus Ulfsnes

With the increasing availability of software usage and the influence of the Lean Startup mindset, more and more companies choose to innovate through internal software startups. Such startups aim at developing new business models while at the same time relying on the resources from the companies where they emerged. The evidence from both researchers and practitioners indicates that driving internal software startups is challenging. This paper seeks to address this problem by asking the research question: how to make internal software startups work? We examined a unique case of a venture builder, a company primarily focusing on building internal software startups and launching them as independent companies. Applying a Grounded Theory approach, we analyzed data on four internal software startups at the case company. The results suggest that four strategies drive the examined startups, cultural, financial, personnel, and venture arrangement. We interpret our results by drawing on earlier literature on intrapreneurship and internal ventures and suggest four recommendations to succeed with internal software startups 1 establish shared arenas for the employees, 2 provide necessary resources for experimentation in the initial phase and increase them incrementally, 3 build up in-house product management competence through coaching, and 4 harness employees own motivation to develop their own ideas.

Nils Brede Moe, Rasmus Ulfsnes, Viktoria Stray et al.

Software development companies organize hackathons to encourage innovation. Despite many benefits of hackathons, in large-scale agile organizations where many teams work together, stopping the ongoing work results in a significant decrease in the immediate output. Motivated by the need to understand whether and how to run hackathons, we investigated how the practice affects productivity on the individual and organizational levels. By mapping the benefits and challenges to an established productivity framework, we found that hackathons improve developers' satisfaction and well-being, strengthen the company culture, improve performance (as many ideas are tested), increase activity (as the ideas are developed quickly), and improve communication and collaboration (because the social network is strengthened). Addressing managerial concerns, we found that hackathons also increase efficiency and flow because people learn to complete work and make progress quickly, and they build new competence. Finally, with respect to virtual hackathons we found that developers work more in isolation because tasks are split between team members resulting in less collaboration. This means that some important, expected hackathon values in virtual contexts require extra effort and cannot be taken for granted.

Marius Mikalsen, Nils Brede Moe, Sut I Wong et al.

We report findings from a case study of a large agile information systems development (ISD) organization`s sudden transformation to distributed, digital work in the context of the Covid-19 pandemic. It seeks to understand how knowledge creation and sharing changes. The findings show various forms of distance being introduced, digital tool usage, increased task orientation, and variations across teams. To analyze the findings, we use the concepts of large-scale collaborations and sociability. Large-scale collaboration offers a socio-technical perspective on tackling distributed knowledge sharing and creation in the presence of multiple, loosely coupled partners using digital tools for collaboration. We show what the digital tools afford using the concept of sociability. We discuss how distributed digital practices make teams more task-oriented and that creating and maintaining sociability, a key issue for knowledge sharing in agile ISD organizations, require relation oriented communication during practical problem solving using digital tools.

Tor Sporsem, Anastasiia Tkalich, Nils Brede Moe et al.

Software product innovation in large organizations is fundamentally chal-lenging because of restrained freedom and flexibility to conduct experi-ments. As a response, large agile companies form internal startups to initiate employ-driven innovation, inspired by Lean startup. This case study investi-gates how communities of practice support five internal startups in develop-ing new software products within a large organization. We observed six communities of practice meetings, two workshops and conducted ten semi-structured interviews over the course of a year. Our findings show that a community of practice, called the Innovation guild, allowed internal startups to help each other by collectively solving problems, creating shared practic-es, and sharing knowledge. This study confirms that benefits documented in earlier research into CoPs also hold true in the context of software product innovation in large organizations. Henceforth, we suggest that similar innova-tion guilds, as described in this paper, can support large companies in the in-novation race for new software products.

Anastasiia Tkalich, Nils Brede Moe, Tor Sporsem

To keep up with the pace of innovation, established companies are increasingly relying on internal software startups. However, succeeding with such startups is a challenging task because internal startups need to find a balance between the interests of the company and the interest of the innovator. One approach that is argued to strengthen innovation in existing companies is employee-driven innovation (EDI). This study explores this argument by examining two internal software startups in companies aligned with the principles of EDI and with a strong focus on innovation. The preliminary findings indicate that startups with EDI are characterized by commitment towards innovation, cooperative orientation, and autonomy. The findings suggest that internal software startups may be strengthened when the parent companies practice EDI.

Darja Smite, Marius Mikalsen, Nils B. Moe et al.

Along with the increasing popularity of agile software development, software work has become much more social than ever. Contemporary software teams rely on a variety of collaborative practices, such as pair programming, the topic of our study. Many agilists advocated the importance of collocation, face-to-face interaction, and physical artefacts incorporated in the shared workspace, which the COVID-19 pandemic made unavailable; most software companies around the world were forced to send their engineers to work from home. As software projects and teams overnight turned into dis-tributed collaborations, we question what happened to the pair programming practice in the work-from-home mode. This paper reports on a longitudinal study of remote pair programming in two companies. We conducted 38 interviews with 30 engineers from Norway, Sweden, and the USA, and used the results of a survey in one of the case companies. Our study is unique as we collected the data longitudinally in April/May 2020, Sep/Oct 2020, and Jan/Feb 2021. We found that pair programming has decreased and some interviewees report not pairing at all for almost a full year. The experiences of those who paired vary from actively co-editing the code by using special tools to more passively co-reading and discussing the code and solutions by sharing the screen. Finally, we found that the interest in and the use of PP over time, since the first months of forced work from home to early 2021, has admittedly increased, also as a social practice.

V. Stray, N. B. Moe, M. Mikalsen et al.

In globally distributed projects, virtual teams are often partially dispersed. One common setup occurs when several members from one company work with a large outsourcing vendor based in another country. Further, the introduction of the popular BizDevOps concept has increased the necessity to cooperate across departments and reduce the age-old disconnection between the business strategy and technical development. Establishing a good collaboration in partially distributed BizDevOps teams requires extensive collaboration and communication techniques. Nowadays, a common approach is to rely on collaboration through pull requests and frequent communication on Slack. To investigate barriers for pull requests in distributed teams, we examined an organization located in Scandinavia where cross-functional BizDevOps teams collaborated with off-site team members in India. Data were collected by conducting 14 interviews, observing 23 entire days with the team, and observing 37 meetings. We found that the pull-request approach worked very well locally but not across sites. We found barriers such as domain complexity, different agile processes (timeboxed vs. flow-based development), and employee turnover. Using an intellectual capital lens on our findings, we discuss barriers and positive and negative effects on the success of the pull-request approach.

Tor Sporsem, Anastasiia Tkalich, Nils Brede Moe et al.

Large global companies need to speed up their innovation activities to increase competitive advantage. However, such companies' organizational structures impede their ability to capture trends they are well aware of due to bureaucracy, slow decision-making, distributed departments, and distributed processes. One way to strengthen the innovation capability is through fostering internal startups. We report findings from an embedded multiple-case study of five internal startups in a globally distributed company to identify barriers for software product innovation: late involvement of software developers, executive sponsor is missing or not clarified, yearly budgeting and planning, unclear decision-making authority, lack of digital infrastructure for experimentation and access to data from external actors. Drawing on the framework of continuous software engineering proposed by Fitzgerald and Stol, we discuss the role of BizDev in software product innovation. We suggest that lack of continuity, rather than the lack of speed, is an ultimate challenge for internal startups in large global companies.

Darja Smite, Nils Brede Moe, Eriks Klotins et al.

The COVID-19 outbreak has admittedly caused a major disruption worldwide. The interruptions to production, transportation, and mobility have clearly had a significant impact on the well-functioning of the global supply and demand chain. But what happened to the companies developing digital services, such as software. Were they interrupted as much or at all? And how has the enforced Working-From-Home mode impacted their ability to continue to deliver software? We hear that some managers are concerned that their engineers are not working effectively from home, or even lack the motivation to work in general, that teams lose touch and that managers do not notice when things go wrong. In this article, we share our findings from monitoring the situation in an international software company with engineers located in Sweden, USA, and the UK. We analyzed different aspects of productivity, such as developer satisfaction and well-being, activity, communication and collaboration, efficiency and flow based on the archives of commit data, calendar invites, and Slack communication, as well as the internal reports of WFH experiences and 18 interviews. We find that company engineers continue committing code and carry out their daily duties without significant disruptions, while their routines have gradually adjusted to the new norm with new emerging practices and various changes to the old ones. In a way, our message is that there is no news, which is good news. Yet, the experiences gained with the WFH of such scale have already made significant changes in the software industry's future, work from anywhere being an example of major importance.

Viktoria Stray, Anastasiia Tkalich, Nils Brede Moe

It is increasingly common to introduce agile coaches to help gain speed and advantage in agile companies. Following the success of Spotify, the role of the agile coach has branched out in terms of tasks and responsibilities, but little research has been conducted to examine how this role is practiced. This paper examines the role of the agile coach through 19 semistructured interviews with agile coaches from ten different companies. We describe the role in terms of the tasks the coach has in agile projects, valuable traits, skills, tools, and the enablers of agile coaching. Our findings indicate that agile coaches perform at the team and organizational levels. They affect effort, strategies, knowledge, and skills of the agile teams. The most essential traits of an agile coach are being emphatic, people-oriented, able to listen, diplomatic, and persistent. We suggest empirically based advice for agile coaching, for example companies giving their agile coaches the authority to implement the required organizational changes within and outside the teams.

Torgeir Dingsøyr, Nils Brede Moe, Helena Holmstrom Ohlsson

Large development projects and programs are conducted using agile development methods, with an increasing body of advice from practitioners and from research. This sixth workshop showed in increasing interest in scaling frameworks and in topics related to achieving business agility. This article summarizes four contributed papers, discussions in "open space" format and also presents a revised research agenda for large-scale agile development.

Viktoria Stray, Nils Brede Moe, Rashina Hoda

According to the principles articulated in the agile manifesto, motivated and empowered software developers relying on technical excellence and simple designs, create business value by delivering working software to users at regular short intervals. These principles have spawned many practices. At the core of these practices is the idea of autonomous, self-managing, or self-organizing teams whose members work at a pace that sustains their creativity and productivity. This article summarizes the main challenges faced when implementing autonomous teams and the topics and research questions that future research should address.

Torgeir Dingsøyr, Nils Brede Moe, Eva Amdahl Seim

Software development projects have undergone remarkable changes with the arrival of agile development methods. While intended for small, self-managing teams, these methods are increasingly used also for large development programs. A major challenge in programs is to coordinate the work of many teams, due to high uncertainty in tasks, a high degree of interdependence between tasks and because of the large number of people involved. This revelatory case study focuses on how knowledge work is coordinated in large-scale agile development programs by providing a rich description of the coordination practices used and how these practices change over time in a four year development program with 12 development teams. The main findings highlight the role of coordination modes based on feedback, the use of a number of mechanisms far beyond what is described in practitioner advice, and finally how coordination practices change over time. The findings are important to improve the outcome of large knowledge-based development programs by tailoring coordination practices to needs and ensuring adjustment over time.