Agile on a large scale

Agile is sometimes seen as an approach that’s best suited to small project and small teams. Julian M. Bass FBCS shows how, through methods and practice, Agile can work equally well on global scale projects too

How product owner teams scale agile methods to large distributed enterprises

Software development teams in large scale offshore enterprise development programmes are often under intense pressure to deliver high quality software within challenging time contraints. Project failures can attract adverse publicity and damage corporate reputations. Agile methods have been advocated to reduce project risks, improving both productivity and product quality. This article uses practitioner descriptions of agile method tailoring to explore large scale offshore enterprise development programmes with a focus on product owner role tailoring, where the product owner identifies and prioritises customer requirements. In globalised projects, the product owner must reconcile competing business interests, whilst generating and then prioritising large numbers of requirements for numerous development teams. The study comprises eight international companies, based in London, Bangalore and Delhi. Interviews with 46 practitioners were conducted between February 2010 and May 2012. Grounded theory was used to identify that product owners form into teams. The main contribution of this research is to describe the nine product owner team functions identified: groom, prioritiser, release master, technical architect, governor, communicator, traveller, intermediary and risk assessor. These product owner functions arbitrate between conflicting customer requirements, approve release schedules, disseminate architectural design decisions, provide technical governance and propogate information across teams. The functions identified in this research are mapped to a scrum of scrums process,and a taxonomy of the functions shows how focusing on either decision-making or information dissemination in each helps to tailor agile methods to large scale offshore enterprise development programmes

Do the scaled agile practices from s@s help with quality requirements challenges and if so, how do they do it?

Quality Requirements (QRs) pose challenges in many agile large-scale distributed enterprise systems. Often, enterprises counter such challenges by borrowing some heavyweight practices, e.g. adding more documentation. At the same time, agile methodologists proposed several scaled agile frameworks to specifically serve agile enterprises working on large and distributed systems. Little is known about the extent to which the proposed scaled frameworks address QRs and the specific ways in which this happens. Moreover, do these frameworks approach the QRs challenges in ways consistent with the Agile Manifesto? This paper treats these questions by analyzing one well-documented scaled framework, namely Scrum@Scale. We evaluated the alignment of Scrum@Scale with the Agile Manifesto, by means of the 4-Dimentional Analytical Tool proposed by other researchers. We then analyzed the practices of Scrum@Scale from the perspective of practitioners responsible for the QRs in a project, in order to understand how the Scrum@Scale practices mitigate those QRs challenges reported in previous work. Our analysis indicated that Scrum@Scale supports the agile values defined by the Agile Manifesto. Plus, we identified 12 Scrum@Scale practices that could (partially) mitigate one or more of the reported QRs challenges. Four of the reported QRs challenges got no remedy offered by Scrum@Scale.</p

Unraveling the Process of Knowledge Integration in Agile Product Development Teams

Agile product development seems to be the solution for many companies to drive innovation and shorten time-to-market, but what mechanisms lie behind the promises of faster development times and more innovative products? Defined as locus of innovation and driver of dynamic performance, the concept of cross-functional knowledge integration and the organizational learning literature have the potential to provide answers here. Recent empirical studies imply that knowledge integration happens on multiple levels that influence each other, and that environmental uncertainty leads to changes in the knowledge integration process. However, the interplay of individual-level and group-level knowledge integration has not yet received adequate attention and prior studies do not show how knowledge integration changes over shorter periods of time. This paper takes a grounded theory approach to explore the knowledge integrating mechanisms in two agile product development teams. The resulting iterative process model shows how agile teams integrate diverse contributions of individual team members into a new product, how internal and external factors trigger alterations in knowledge integration practices, and how agile teams adapt to changes in coordination and collaboration demands. Keywords: Agile product development; knowledge integration; cross-functional teams; organizational learning.Agile product development seems to be the solution for many companies to drive innovation and shorten time-to-market, but what mechanisms lie behind the promises of faster development times and more innovative products? Defined as locus of innovation and driver of dynamic performance, the concept of cross-functional knowledge integration and the organizational learning literature have the potential to provide answers here. Recent empirical studies imply that knowledge integration happens on multiple levels that influence each other, and that environmental uncertainty leads to changes in the knowledge integration process. However, the interplay of individual-level and group-level knowledge integration has not yet received adequate attention and prior studies do not show how knowledge integration changes over shorter periods of time. This paper takes a grounded theory approach to explore the knowledge integrating mechanisms in two agile product development teams. The resulting iterative process model shows how agile teams integrate diverse contributions of individual team members into a new product, how internal and external factors trigger alterations in knowledge integration practices, and how agile teams adapt to changes in coordination and collaboration demands. Keywords: Agile product development; knowledge integration; cross-functional teams; organizational learning

The Scrum Product Backlog as a Tool for Steering the Product Development in a Large-Scale Organization

Vesiputousmalli ja sen variaatiot ovat olleet laajalti käytössä ohjelmistotuotannossa. Näiden mallien vikojen korjaamiseksi, eli markkinoiden vaatimuksiin mukautumisen kohentamiseksi sekä evolutionististen toimitusten tekemiseksi, on syntynyt ketteriä ohjelmistokehitysmenetelmiä. Näistä eniten käytetty on scrum-viitekehys. Suomen Ericsson on ottamassa scrum-menetelmän käyttöön. Muutoksen tukemiseksi, tämä diplomityö tunnistaa product backlog -tehtävälistan asianosaisia sekä heidän tarvitsemaansa ja tuottamaansa tietoa. Kirjallisuuskatsauksen, tietoliikennealan yritysten vertailun, strukturoimattomien haastatteluiden (n = 6) sekä puolistrukturoitujen haastatteluiden (n = 11) avulla tutkimuksessa tunnistettiin asianosaiset ja heidän toimintansa eri päätöspisteissä. Pohjana tutkimuksessa käytetään yrityksen uutta päätöksentekoviitekehystä. Diplomityö esittelee taulukon avulla asianosaisten toimenpiteet eri päätöspisteissä nimenomaan product backlog -tehtävälistaan liittyen. On oleellista huomata, että eri asianomaiset tarvitsevat eri tietoa. Lisäksi eri vastuuhenkilöille sopivat erilaiset visualisointitavat. Näin ollen, työ esittelee myös viitekehyksen, jonka avulla visualisointia voidaan kohdentaa eri asianomaisille. Tutkimuksessa havaittiin kolme seikkaa, joita tulee kohentaa. Ensinnäkin, useat asianomistajat haluavat oman backlog -tehtävälistan. Toiseksi, tehtäviä ja vastuita siirretään useassa kohtaa toiselle henkilölle. Kolmanneksi, innovaatioprosessi on erillään uuden tuotteen kehittämisestä. Toisaalta, useita kaavailtua tapaa tukevia löydöksiä havaittiin kirjallisuudesta. Esimerkiksi, yrityksen tiimit ovat monialaisia, tuotevastuu on hajautettu useammalle henkilölle sekä uuden ominaisuuden sisältö on rajattu vastaamaan markkinan todellista vaatimusta.The Waterfall model has been widely applied in the software development. However, agile software development methods have emerged to enhance the adaptability to the changing market demands and to utilize evolutionary releases. The most widely adopted agile method is the Scrum framework. Ericsson Finland is implementing Scrum. To support the transition, the thesis identifies the stakeholders of the product backlog and the data the stakeholders demand and provide. With a simplification, it can be stated that the product backlog is a prioritized list of items to be performed to complete a feature. Based on a literature review including a benchmark of other telecommunication domain companies, open-ended interviews (n = 6), and semi-structured interviews (n = 11), the thesis lists the stakeholders and their actions at each decision point. The decision framework, which has emerged in-house, was utilized to structure the thesis. A matrix mapping the actions by each stakeholder at each decision point was formed. The primary data, which the stakeholders require directly and indirectly from the product backlog, are the velocity, work to be done, the date of feature completion, dependencies, costs, and business value. It is important to note that the stakeholders need the data on different levels and for different purposes. Hence, the feasible visualization of the data varies among the stakeholders. In addition to identifying the stakeholders and the requirements for data, the thesis points out three findings regarding areas to be enhanced. First, multiple stakeholders currently demand their own product backlog. Second, multiple handovers are conducted. Third, the innovation process is isolated. However, multiple findings supporting the current organizational thinking of the implementation emerged. For instance, the teams are cross-functional, the product ownership responsibility is shared, and the scope of a new feature is optimized to not to include additional functionality that the market does not demand

Are Product Owners communicators? A multi-method research approach to provide a more comprehensive picture of Product Owners in practice

Product Owners have an important role in the agile and hybrid software development process. While this role is supposed to maximize the value of a product, there seem to be several scattered results on how they achieve this, as well as what actually constitutes this role in practice. To consolidate current research results and to further analyze the key attribute of Product Owners, we conducted a multi-method research approach spanning a systematic mapping study and a consecutive case study in a hybrid development environment. The results of the mapping study states that Product Owners are communicators. We further investigated on this and used the shadowing technique to observe three Product Owners' communication activities. The results support that statement, as the gained data reveal that Product Owners spend 65% of their time in meetings. But rather than just providing the team with the necessary requirements for the product under development, Product Owners need this time to synchronize and align their work, streamline the agile process of large-scale Scrum, discuss team-based topics, and to solve upcoming issues addressed by the team. These results contribute to draw a more comprehensive picture of the important but yet complex role of Product Owners in practice. © 2020 John Wiley & Sons, Ltd

Supporting the tailoring of the product owner role to hybrid development environments

Product Owners have an important role in the agile software development process. While the description of the Product Owner role heavily depends on its particular agile framework, the application of a single development framework is seldom in practice. In fact, customized hybrid development approaches, where frameworks/methods are tailored or combined with others, are state of the art. Although it is common knowledge that processes need to be tailored to project needs, as they become, otherwise, a project risk - the tailoring of the Product Owner role has been neglected in research so far. Consequently, there is a lack of knowledge about how to tailor the Product Owner role to hybrid development environments. As this knowledge gap can put projects in a hybrid environment to a risk, the goal of this thesis is to close this gap. To achieve this, a knowledge-base of Product Owner peculiarities needs to be established and consolidated with knowledge from the area of Software Process Tailoring. To generate the knowledge-base of the Product Owner peculiarities, a number of case studies as well as a systematic mapping study was conducted to identify Product Owner tasks, characteristics and structures in hybrid development environments. This resulted in the identification of 13 frequently conducted tasks, 6 favorable characteristics and 12 different structures of Product Owners that apply in hybrid development environments. From the area of Software Process Tailoring, 14 influencing factors on the Product Owner role were extracted along with its respective action items. The consolidation of this knowledge results in a catalog which combines the influencing factors, the Product Owner tasks, characteristics & structures as well as the respective implications on the Product Owner role according to the research results of this thesis. Based on this catalog, any project environment can be assessed and distinct recommendations for a tailored Product Owner role can be deduced. Overall, this thesis generated 84 different recommendations on how to tailor the Product Owner role to a particular hybrid development. With this, so far missing knowledge was gained to systematically support the tailoring of the Product Owner role to hybrid development environments and thus, to support projects to complete successfully. To share the gained knowledge to other researchers as well as practitioners, this thesis also provides an expert system in the form of a proof of concept web-application. The so-called Hybrid Product Owner (short: HyPrO) Expert System represents the research results of this thesis. Its user-friendly interface enables the user to assess the project environment and displays the respective recommendations. The HyPrO Expert System validated the results of this thesis, as it surpassed human experts by providing more comprehensive recommendations in a comparative case study

Dependency Management in Large-Scale Agile: A Case Study of DevOps Teams

Managing dependencies between teams and within teams is critical when running large-scale agile projects. In large-scale software development, work is carried out simultaneously by many developers and development teams. Results are delivered frequently and iteratively, which requires management of dependencies on both the project and team level. This study explores coordination mechanisms in agile DevOps teams in a large-scale project and how the mechanisms address different types of dependencies. We conducted a case study where we observed 38 scheduled meetings and interviewed members of five DevOps teams and two teams supporting the DevOps teams. By using a dependency taxonomy, we identified 20 coordination mechanisms (eleven synchronization activities and nine synchronization artifacts). Eight of these mechanisms seem essential for coordination in large-scale projects because they addressed more than four types of dependencies. The main implication is that project management needs to combine many practices handling all the dependencies in large-scale projects

Understanding the structured processes followed by organisations prior to engaging in agile processes: A South African Perspective

There appears to be a lack of knowledge on the phases South African (SA) organisations go through while adopting agile methods. As a means to address this gap, this study uncovered empirical evidence on the phases SA organisations go through whilst adopting agile methods as well as the disparities between agile prescriptions and the way SA organisations actually implement agile methods. The data collected using a case study approach was analysed through the lens of Actor-Network Theory (ANT). The results reveal that there is no structured process for adopting agile methods and organisations go through various phases in their attempts to adopt agile methods. During the various phases, organisations face challenges which are culture as well as people related. Through this study South African practitioners could now be aware that before adopting an agile methodology, there has to be a common understanding of the problems at hand and the envisioned solution. The findings also inform aspiring adopters in South Africa that adoption of the methods does not have to be as prescribed. They are free to adopt only those aspects the organisations need most