Agile Approaches on Large Projects in Large Organizations - Brossura

Hobbs, Brian; Petit, Yvan

Brossura

ISBN 10: 1628251751 ISBN 13: 9781628251753

Casa editrice: Project Management Inst, 2018

Riassunto

Creativity and productivity, rapid adaptation to change, value for the customer—these are just some of the advantages of implementing agile practices in project work. However, agile practices have been most widely and successfully undertaken in the context of small, colocated teams working on small software projects, known as the “agile sweet spot.”

In this monograph, Brian Hobbs and Yvan Petit explore the use and impact of agile outside of the agile sweet spot. Through a case study and survey questionnaire, they uncover research questions that have remained largely unexamined in the literature, on the project level as well as on the organizational level.

An illuminating study of this emerging field, Agile Approaches on Large Projects in Large Organizations opens the door to further investigation on the future role of project managers, the use of scaling frameworks at the program and portfolio levels, and the effects of DevOps, one of the recent trends in agile software development.

Su questo libro

Informazioni sull?autore

Dr. Brian Hobbs PMP founded the Project Management Chair in 2007and held the Chair until 2015. He holds a degree in Industrial Engineering, an MBA and a PhD in Management. He has been a professor at the School of Management of the University of Quebec at Montreal in the Master's Program in Project Management for more than thirty years. This program, of which he is a past director, is accredited by PMI’s Global Accreditation Center.

Estratto. © Ristampato con autorizzazione. Tutti i diritti riservati.

Agile Approaches on Large Projects in Large Organizations

By Brian Hobbs, Yvan Petit

Project Management Institute, Inc.

Copyright © 2017 Project Management Institute, Inc.
All rights reserved.

ISBN: 978-1-62825-175-3

Contents

1 Introduction, 
2 Literature Review, 
3 Methodology, 
4 Results, 
5 Discussion, 
6 Conclusion, 
7 Future Research, 
Acknowledgments, 
References, 
Appendix, 
About the Authors, 

CHAPTER 1

Introduction

Agile has taken software development by storm since the publication of the Agile Manifesto (Agile Alliance, 2001). In recent years, agile methodologies have become highly prevalent in the software industry (Abrahamsson, Conboy, & Xiaofeng, 2009; Dingsøyr, Nerur, Balijepally, & Moe, 2012). Today, it is one of the hottest topics in project management; Project Management Institute (PMI) has created the PMI Agile Certified Practitioner (PMI-ACP)® certification and Project Management Journal® has published a special issue on the topic. (Note that the special issue and this research monograph will likely be published at approximately the same time. For a summary of the present research, see Hobbs and Petit [2017].)

Although there have been multiple attempts to apply agile principles to non-software projects (Conforto, Salum, Amaral, da Silva, & de Almeida, 2014; Highsmith, 2003; Petit & Levesque, 2015), this research is limited to the field of software development — the field where agile has become prominent. It focuses on two levels of analysis: the individual project and the organizational context in which projects are carried out. The agile literature has focused almost exclusively on the former, while almost completely ignoring the latter.

The advantages of using agile identified in the literature include: a working environment that supports creativity and productivity, rapid adaptation to change, and value for the customer because of better identification of needs and priorities and faster multiple deliveries of functionalities (Schwaber, 2004; Thomke & Reinertsen, 1998). These advantages are more readily obtained with certain types of projects in certain contexts. Kruchten (2013) identified what is referred to as the "agile sweet spot," which consists of small colocated teams working on small, noncritical, green field, in-house software projects with stable architectures and simple governance rules. Most of the writings on agile report on situations that are close to the sweet spot. Projects and contexts with the opposite characteristics are examined much less extensively in the literature. Studies of projects outside the sweet spot have revealed that they are much more problematic. Leffingwell (2010) showed that there are a number of impediments to the scaling of these practices in large multisite, multi-customer, multi-project organizations. For more than five years, larger organizations have been adopting agile approaches and struggling to scale from a few agile teams to an organization-wide implementation of agile. In a survey of 3,880 participants, VersionOne (2016) found that organizations are continuing to scale agile beyond single teams and single projects and that more energy is put into scaling agile across the enterprise. However, little has been reported in the literature on either the practices employed on individual projects or the interplay between agile practices and the accompanying organizational arrangements (Kettunen, 2007) despite the fact that this is considered one of the top research topics among practitioners (Dingsøyr & Moe, 2013, 2014; Freudenberg & Sharp, 2010). The overall objective of the present research is to fill this gap by examining projects and contexts that are not in the agile sweet spot, specifically large software projects in large organizations.

The research question at the project level is: What challenges are encountered when applying agile methods to large multiteam software projects and what practices have been developed to alleviate these challenges? The literature that has examined these questions has most often taken an approach that contrasts and/or mixes agile and traditional project management approaches (Boehm & Turner, 2003, 2004, 2005; Conforto, Salum, Amaral, da Silva, & de Almeida, 2014; Conforto, Rebentisch, & Amaral, 2014; Sommer, Hedegaard, Dukovska-Popovska, & Steger-Jensen, 2015; Špundak, 2014). The present research aims to go beyond this somewhat simplistic approach based on a rich description of practice in specific contexts.

At the organizational level, the research examines the implementation of agile approaches in large organizations as it has unfolded over time by examining implementation strategies. The adoption of agile by a large, complex organization requires experimentation and adaptation of the agile practices to the organization's structure, culture, product/service strategy, human resource management policies, customer interfaces, project roles, and governance structures, including program and project portfolio management. At the same time, the organizational context is influenced by the implementation of agile. The research question at the organizational level is: How does the context of large, complex organizations affect the adaptation and adoption of agile approaches and vice versa?

CHAPTER 2

Literature Review

2.1 Agile Approaches

Agile methodologies are specific approaches to implement flexibility in the project management process, which have been designed in response to the specific challenges of the software industry (i.e., high uncertainty, ill-defined requirements, short development cycle, and no physical deliverable) (Agile Alliance, 2001; Lindvall et al., 2004). For example, Gruver, Young, and Fulghum (2013) describe how Hewlett-Packard went from spending 20% of their project budget on plans to 5%, the argument being that plans needed for business decisions do not require the detail and precision of traditional project plans and that the resources are put to better use developing the product rather than producing detailed plans that will be wrong. Conboy (2009) conceptualizes the agile approach from two related concepts: flexibility and leanness. Agile methodology was inspired by the flexible mass production systems, led by the Toyota production system of the 1950s. It further evolved into the lean manufacturing concept, which then became lean thinking within the quality movement (Abrahamsson, Warsta, Siponen, & Ronkainen, 2003; Carstens, Richardson, & Smith, 2013). The quality movement paved the way for agile software development. All of the agile approaches share common values and principles stated in the Agile Manifesto (Agile Alliance, 2001) and subsequent publications by authors of the manifesto (Levin, 2012; Schwaber, 2007). Of these methods, Scrum and Extreme Programming (XP) are by far the best known and most widely used (VersionOne, 2016).

The authors of the Agile Manifesto did not try to define what they meant by agile. Instead they proposed 12 principles and four values (see Table 1) that identify some areas where the focus of software projects should be changed.

Laanti, Similä, Abrahamsson, and Delta (2013) analyze how subsequent definitions of agile put more or less emphasis on some of the items identified in the manifesto. Kettunen (2009b) and Laanti et al. (2013) identify 10 definitions of agile ranging from "rapid and flexible response to change" (Larman, 2004), which primarily focuses on the adaptation to change in agile, to the Institute of Electrical and Electronics Engineers (IEEE) putting more emphasis on the iterative nature of agile as the "capability to accommodate uncertain or changing needs up to a late stage of the development (until the start of the last iterative development cycle of the release)" (Laanti et al., 2013). However, we prefer the more comprehensive definition of Ambler (2009), which covers the main principles included in the manifesto:

Agile software development is an evolutionary (iterative and incremental) approach which regularly produces high quality software in a cost effective and timely manner via a value driven lifecycle. It is performed in a highly collaborative, disciplined, and self-organizing manner with active stakeholder participation to ensure that the team understands and addresses the changing needs of its stakeholders. Agile software development teams provide repeatable results by adopting just the right amount of ceremony for the situation they face. (p. 6)

Conforto, Amaral, da Silva, Di Felippo, and Kamikawachi (2016) analyzed 59 definitions covering the "agile" concept. They propose a comprehensive definition of the agility construct covering the entity, the event, the degree, the trigger, the purpose, and the circumstance as follows:

Agility is the project team's ability to quickly change the project plan as a response to customer or stakeholders [sic] needs, market or technology demands in order to achieve better project and product performance in an innovative and dynamic project environment. (p. 667)

2.2 Benefits of Agile

Organizations might have very different reasons to implement agile. For example, their goal might be to improve quality, better respond to change, decrease lead time, release new product variants more often, reduce cost, or ensure that the product delivered corresponds better to what the customer wants (Kettunen & Laanti, 2008). Although many software developers could not imagine working any other way, surprisingly, very few studies have actually measured or demonstrated the benefits/improved performance due to agile. Many of the publications on agile are based on individual case studies or on observations by consultants implementing agile. Probably the most extensive study trying to assess the impact of implementing agile was performed at Nokia by Laanti, Salo, and Abrahamsson (2011). Their survey of more than 1,000 respondents in seven different countries in Europe, North America, and Asia reveals that:

Most respondents agree on all accounts with the generally claimed benefits of agile methods. These benefits include higher satisfaction, a feeling of effectiveness, increased quality and transparency, increased autonomy and happiness, and earlier detection of defects. Finally, 60% of respondents would not like to return to the old way of working. (p. 276)

Although agile approaches have provided flexibility in the software development process, most benefits have been achieved within the Executing Process Group (Project Management Institute, 2012) of small projects composed of one or a few dedicated self-managed teams (Kruchten, 2013).

2.3 Agile and Traditional Project Management Approaches

Agile methodology is often presented in opposition to the more traditional project management principles and practice (Fernandez & Fernandez, 2008). For example, the Agile Manifesto (Agile Alliance, 2001) positions the four core values over the alleged traditional values. However, Kettunen (2009a) suggests that further improvements in software development could be inspired by organization-oriented business concepts, many of which are long-established project management concepts, such as concurrent engineering, multi-project management, being proactive, and so forth (Boehm, 2002; Boehm & Turner, 2003, 2004).

Al-Zoabi (2008) recommends a balanced combination of plan-driven traditional project management and an agile approach to manage projects, stating that the flexibility of an agile approach should be balanced with the advantage of a more traditional approach through a risk-based analysis. This is observed in a combination of XP and Prince2 (Al-Zoabi, 2008).

Anantatmula and Anantatmula (2008) show empirically that such a combined approach may be very valuable for the management of projects in an IT environment. It has also been shown that agile could be combined with stage gates in large organizations such as ABB, Ericsson, and Vodafone (Karlstrom & Runeson, 2005, 2006). This might lead to a different combination and alignment of the software development phases with the project management phases. However, this leads to a different perception of control between upper management (used to a more traditional gating approach) and the development teams:

During the project, management was negative to the agile "method" used at the engineering level due to the fact that they felt uneasy with a different method. They felt less in control of the project and they missed the ability to squeeze extra functionality into the project without something else being removed. The developers[,] however, felt a strong sense of control in the project and were very pleased. The opinion was that the information that the management required existed, they just did not look in the right places. (p. 214)

Another option, according to Vinekar, Slinkman, and Nerur (2006), would be to have both the traditional and the agile approaches coexist in separate subunits within an ambidextrous organization, an approach referred to as Bimodal IT (Gartner, 2016). The issue then becomes to develop criteria for selecting which approach to use on each project based on the advantages and disadvantages of each, for example, between the waterfall model, the V-Model, or agile (Balaji & Murugaiyan, 2012). Barlow et al. (2011) suggest a selection framework based on the volatility, the nature of the project interdependencies, and the project team size. Adoption of one agile methodology or the other would often be based on the organization's corporate culture and/or maturity (Gruver & Mouser, 2015; Iivari & Iivari, 2011).

2.4 Scaling Agility

Observing that agile is bringing benefits to small software development projects, many organizations are now attempting to apply the same principles but to larger projects. For this research project, it was important to clarify what was meant by scaling (i.e., what is considered a large project or a large organization when the time comes to use agile).

Ambler (2009) proposes a scaling model, called Agile Scaling Model (ASM), based on factors such as team size, geographical distribution, regulatory compliance, domain complexity, organizational distribution, technical complexity, organizational complexity, and enterprise discipline.

Kruchten (2013) also identifies eight scaling factors (system size, criticality, system age, rate of change, business model, stability of architecture, team distribution, and governance), which might distinguish the contexts in which agile would be easier to introduce than others. Based on this model, an agile sweet spot refers to:

The conditions under which most "labelled" agile software development have been developed, and for which success is pretty much assured. This would be the case for example of a web-based e-commerce site, built on dot-net technology by a small team, interacting with their customers. (p. 355)

This would translate into a context with particular characteristics. An example of a context corresponding to the agile sweet spot (Kruchten, 2013) is shown in Table 2.

In other words, while agile methodologies seem suited for small, colocated teams where the customer can be directly involved, there are a number of impediments to the scaling of these practices in large multisite, multi-customer, multi-project organizations; for example, the question of the customer representative or product owner is often problematic (Leffingwell, 2010; Lindvall et al., 2004).

The exact definition of agility scaling is not clear (Dingsøyr & Moe, 2014) but Dingsøyr, Fægri, and Itkonen (2014) suggest a taxonomy of scale of agile software development projects based on the number of teams where small scale corresponds to one team, large scale to two to nine teams, and very large scale to more than 10 teams. Using this scale, the qualitative portion of this research examines large-scale projects, and the survey examines both large-scale and very large-scale projects.

2.5 Examples of Using Agile at Scale

There has been limited research on the topic of implementing agile in large projects in large organizations (Dyba & Dingsøyr, 2008; Razavi & Ahmad, 2014), although a number of specific cases have been investigated and documented. Grewal and Maurer (2007) studied the use of agile approaches in a medium-to-large-scale project in the oil industry over a period of two-and-a-half years. Gruver et al. (2013) published their experience of implementing agile in a large multisite project for a new series of printers at Hewlett-Packard, which subsequently led to a migration toward DevOps (Gruver & Mouser, 2015). The term DevOps is a derivative of development and operations, which is closely related to software engineering practices. DevOps has two components: an organizational change component that fosters improved collaboration among developers, testers, integrators and operators, and a technical component featuring automated testing, integration, deployment, and monitoring of the performance of systems in production (VersionOne, 2016). It is a more recent phenomenon within the family of agile techniques and is not the object of study in the present research.

Mahanti (2006) studied some of the challenges of introducing agile in organizations with four specific cases at ABB, Daimler-Chrysler, Motorola, and Nokia. He found that the primary challenge in adopting agile practices in large organizations was the integration of agile projects with the project environment's existing processes.

(Continues...)

Excerpted from Agile Approaches on Large Projects in Large Organizations by Brian Hobbs, Yvan Petit. Copyright © 2017 Project Management Institute, Inc.. Excerpted by permission of Project Management Institute, Inc..
All rights reserved. No part of this excerpt may be reproduced or reprinted without permission in writing from the publisher.
Excerpts are provided by Dial-A-Book Inc. solely for the personal use of visitors to this web site.

Dettagli dell?edizione

• Editore: Project Management Inst
• Data di pubblicazione: 2018
• Lingua: Inglese
• ISBN 10: 1628251751
• ISBN 13: 9781628251753
• Rilegatura: Copertina flessibile
• Numero di pagine: 133
• Contatto del produttore: non disponibile
• Persona responsabile: non disponibile