"Modeling the impacts of agile SW implementation over learning and innovation in a multi-national company in the telecommunications industry"

(1)

D

IPARTIMENTO DI

I

NGEGNERIA DELL

’E

NERGIA DEI

S

ISTEMI

,

DEL

T

ERRITORIO E DELLE

C

OSTRUZIONI

RELAZIONE PER IL CONSEGUIMENTO DELLA LAUREA MAGISTRALE IN INGEGNERIA GESTIONALE

Modeling the impacts of Agile SW implementation

over Learning and Innovation in a multi- national

company in the telecommunications industry

RELATORI CANDIDATO

Prof. Antonella Martini Laura Peonia

Dipartimento di Ingegneria dell’Energia dei Sistemi,

del Territorio e delle Costruzioni Ing. Maria Carmela Annosi

Industrial Researcher

Ericsson Telecomunicazioni S.p.A Ing. Francesco Paolo Appio

Dipartimento di Ingegneria dell’Energia dei Sistemi,

del Territorio e delle Costruzioni

Sessione di Laurea del 24/09/2014 Anno Accademico 2013/2014

(2)

SOMMARIO

Questo progetto di tesi è il risultato di uno stage di sei mesi svolto presso un centro R&D di un’azienda svedese, leader mondiale nel settore ICT. L’obiettivo del progetto è comprendere la relazione tra l’implementazione della metodologia Agile e le performance innovative dell’organizzazione. Infatti, a seguito dell’introduzione di Agile avvenuta negli ultimi anni su scala mondiale, il quartier generale ha osservato criticità correlate al dominio dell’innovazione. Il mio progetto, nato dalla collaborazione tra l’azienda, il Royal Institute of Technology di Stoccolma e l’Università di Pisa, ha fornito ad una Product Development Unit (PDU) (sede centrale di Stoccolma) una valutazione estensiva ed approfondita del problema, allo scopo di comprenderne le cause scatenanti e individuare possibili soluzioni. La raccolta dati è stata eseguita all’interno di quattro organizzazioni appartenenti a tale PDU, attraverso interviste, collezione di documenti aziendali e risultati di una precedente survey globale interna. I dati sono stati analizzati con l’ausilio di un apposito software (MaxQDA) al fine di elaborare un modello che mostrasse le relazioni tra i concetti emersi e le conseguenti ipotesi di ricerca. Tutti i risultati ottenuti sono stati presentati a Stoccolma durante diversi meeting con il leadership team della PDU e con gli sponsor coinvolti. L’analisi ha mostrato come l’adozione della metodologia Agile abbia comportato effetti negativi sull’apprendimento e sull’innovazione di prodotto. Nell’ultima fase del progetto è stata costruita una survey, per validare le ipotesi formulate. Tale survey è stata testata su un campione rappresentativo per essere poi somministrata ai circa 1700 dipendenti, coinvolgendo tutti i livelli aziendali.

ABSTRACT

This thesis is the result of the six months internship carried out at a R&D center of a Swedish company, world leader in ICT. The thesis project’s aim is to deepen the relationship between Agile implementation and the organizational innovative performances. In fact, after the global adoption of Agile methods, the company headquarter observed some issues tied to innovation domain. My project, born from the collaboration between the company, the Royal Institute of Technology (Stockholm) and the University of Pisa, provided a Product Development Unit (PDU), headquartered in Stockholm, with an extensive and in-depth assessment of the problem, to understand its

(3)

root causes and provide possible solutions. Data collection was performed within four organizations belonging to the PDU, through interviews, collection of internal documents and previous internal global survey’s results. All data were analysed with the support of a specific mixed-methods tool (MaxQDA), to develop a model showing the linkages among the emerged concepts and to formulate research hypotheses. All results achieved were presented in Stockholm during several meetings with the PDU leadership team and the project sponsors. The analysis showed how Agile adoption brought negative effects over product learning and innovation. As last project phase, a survey was built up to validate the research hypotheses. The survey was tested on a representative sample and then distributed to the 1700 employees, involving all organizational levels.

(4)

CHAPTER 1. THE CONTEXT

1.1 OVERVIEW OF THE CONTEXT: THE COMPANY AND THE

PRODUCT DEVELOPMENT UNIT W

The company was founded in Sweden in 1876, and since then has grown, becoming a multinational provider of communication technology and services and the world leader in 2G/3G/4G mobile network infrastructure market, with more than 110.000 employees worldwide and customers spread in more than 180 countries. It is divided into four Business Units (BU) that, in turn, are broken up into Development Units (DU). Each DU is in charge of a number of Product Development Units (PDU), among which there is also the PDU W, object of this thesis’ analysis. In Figure 1. 1, the hierarchical structure previously described is shown.

PDU W is responsible for the design, development, deployment and maintenance of software product systems. It is organized into Requirement Areas (RA), representing a domain of product features relevant for customers, to which employees are assigned semi-permanently. In this way, the organization was able to limit the functional area and the portion of code that people need to deal with. There are also separate lines responsible for Continuous Analysis and Continuous Integration, which cover a supporting

Company Business Unit (BU) Development Unit (DU) Product Development Unit (PDU) Figure 1. 1: Company Chart

(7)

2

role to the Requirement Areas, a specific unit devoted to concept development activities and a unit dealing with maintenance activities that does not have its own resources but takes people from the requirement areas in turn. In the PDU W there are also supporting units for Financial Control and Human Resources.

The organizational headquarter is in Sweden, but it has also other sites in different countries inside and outside Europe, with more than 1700 employees. The organizational chart is clarified through Figure 1.1.

Figure 1.1: PDU W Organizational Chart

1.2 BRIEF DESCRIPTION OF AGILE SW DEVELOPMENT

According to Agile Alliance, a non-profit organization committed to advancing agile principles and practices, agile software development is described as the collection of new methodologies that emerged in the late 1990s that focused on:

 Close collaboration between the programmer team and business experts

 Face-to-face communication, seen as more efficient than written documentation

 Frequent delivery of new deployable business value

 Tight and self-organizing teams

 Ways to craft the code and the team such that the inevitable requirements churn was not a crisis

Moreover, agile software development follows the principles and values expressed in the Agile Manifesto (Beck et. al, 2001) written on February 2001, during a meeting of seventeen independent-minded experts of different programming methodologies. The participants found an agreement on four main values. In fact they stated:

PDU W

RA 1 RA 2 RA 3 RA 4 Development Concept Unit

Continuous

Integration Continuous Analysis Maintenance Unit Human

(8)

3

“We are uncovering better ways of developing software by doing it and helping others does it. Through this work we have come to value:

1. Individuals and interactions over processes and tools 2. Working software over comprehensive documentation 3. Customer collaboration over contract negotiation 4. Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more”.

Since 2001, a lot of development methods following the agile principles have raised up, giving the chance to software developers to apply these methods and combine them with other philosophies for an effective product development, like Lean and Kanban. Two examples of these methodologies are Extreme Programming and Scrum (Schwaber, 2004) project management method. The Agile Alliance has created a list of 47 different agile practices, enriched with a full description of each one.

The agile software development approach is based on the assumption that software requirements are turbulent, since they are depending on market forces (Fowler, 2002; Cockburn and Highsmith, 2001). In fact, agile software development methods rose up as a way to respond to the difficulty of traditional plan-driven approaches to handle the dynamic and rapidly changing environments (Highsmith 2002). Cockburn and Williams (2003) state that agile development is particularly suitable in case of high level of changes. As a matter of facts, agility is defined as the ability to be sensitive and responsive to business plans through adaptability and flexibility, in order to be inventive and survive in an unstable and unpredictable business environment (Highsmith, 2002). The agile approach to development applies the concept of agility to the entire development process, the development teams and the environment in which they operate. (Boehm and Turner, 2004). This approach embeds shared values from different stakeholders, basing on the philosophy of regularly releasing product features to customers, in short time-boxes (Southwell, 2002). This systematic and frequent feature delivery is achieved by adopting a team-based approach (Coram and Bohner, 2005). Agile teams are generally made up of individuals with different backgrounds (Fowler, 2002). The development teams are supported by on-site customers’ representatives, with the

(9)

4

necessary domain knowledge to help teams understanding the different requirements (Abrahamsson et. al, 2002). Teams’ work is organized in short iterative development cycles, helping them to satisfy requests for product changes and to detect new emerging requirements (Highsmith, 2002). The agile approach enhances small project plans that allow teams to provide more accurate estimations for the deliveries’ scheduling (Smits, 2006). Lindvall et. al, (2002) grouped the previous working definitions of agile software methodologies, defining them as a set of software development processes that are:

 Iterative since several cycles are required to complete;

 Incremental, since the software product is not delivered as a whole but divided in workable pieces;

 Self-organizing, since teams determine by themselves the best way to perform their work;

 Emergent, since the processes, principles, and work structures are not predetermined but identified along the project.

On the other hand, Abrahamsson et. al, (2003) attributed to agile software development the following characteristics: incremental, cooperative, adaptive and straightforward. In another definition, Boehm and Turner (2005), stated that agile methods are processes relying on short iterative cycles, on the active involvement of users to establish prioritizations and to check the requirements, and on the teams’ tacit knowledge rather than on documentation.

Agile software development approach strongly differs from the traditional one. Boehm (2002) reports that the agile software development methods are primarily focused on providing customers with rapid value whereas the traditional ones are centred on high assurance. Nerur et. al, (2005) performed a comparison between both methods and stated that traditional development systems are easily identifiable and predictable and are built through an accurate and extensive planning, while agile development leads to a high-quality adaptive software, developed by small cross-functional teams who adopt the principles of continuous design improvement and testing basing on quick feedback and changes.

Moreover, according to Dybå and Dingsøyr (2008), agile methods address the challenge of an unpredictable world relying on people adaptability, flexibility and responsiveness,

(10)

5

so emphasizing the value that people could bring to software development. On the contrary, traditional methods seek the optimization of the development process through a well-planned and formalized procedure. Another important difference is the sequence of development process phases: in agile software development, the design, the testing and the implementation cannot be separated and are done iteratively, while in the traditional approach the design precedes the implementation and the testing phase. Among the traditional approach (Pfleeger and Atlee, 2006), the waterfall model is one of the first described framework of a traditional, planned software development. In the waterfall approach, the different phases of the development process, from the requirement analysis, the system design, the program design, the coding, the unit and integration testing, to the system and the acceptance testing, are performed in clearly distinct and consecutive stages. One stage cannot begin until the previous one is finished. In correspondence to each step there are milestones and deliverables, used for project management. The waterfall approach has been subject of criticism, since it is considered not very well adapting to changes and to the software development process.

Summing up, the main differences between the traditional approach and the agile one are the following, reported in Table 1.1.

Table 1.1: Traditional VS Agile Approach

Traditional Approach Agile Approach

Focus on high assurance Focus on rapid value

Easily identifiable and predictable system High quality and adaptive software

Built through accurate and extensive planning Principles of continuous improvements: quick feedback and changes

Optimization through well planned and formalized procedures

Optimization through people’s flexibility Design precedes implementation and testing that are

separate phases

(11)

6

1.3 AGILE TRANSFORMATION IN PDU W: WHY, WHEN, WHO, HOW

Why

At the beginning of 2010, the PDU W Leadership Team decided to change something in the organizational way of working, since they were extremely challenged by their roadmaps, they were following behind their competitors and there was no more money to invest for increasing the organizational capability. The Product Line realized that something radical different was needed in order to become more efficient and to improve quality. In fact, a lot of employees were stuck fixing the trouble reports (TRs) coming from the released product. Also innovation was an issue, since the organization was not able to stay ahead the competition. So some of the Leadership Team members went visiting another PDU under the same company that, at that time, was already implementing agile practices with pretty good results in terms of product quality. After this visit, they realized the same approach was needed inside their PDU too, with the ambition to let people become as much flexible as possible. What above is shown in Figure 1.2.

(12)

7

When

In October 2010 a first pilot was performed gradually: at the beginning, only a pilot team started working on new features and their behaviours were observed by the Leadership Team. Then, in April 2011 a first core team followed and, step-by-step, other teams were added until the end of 2012, when all the 90 teams concluded all the projects run with the waterfall approach. Hence, after two years from the first pilot, the agile transformation was considered finished, since all the people in the organization had new roles and all the teams worked in Agile. In summer 2013, the first product containing only features completely developed by agile teams was released. The agile transformation timing is synthetized in Figure 1.3.

Figure 1.3: Agile Transformation at PDU W

Who and How

The head of the system department (current system development unit) was appointed to drive the agile transformation, and some senior project managers, together with the department managers for design and verification were allocated to deeply study agile methods. These people were selected because of their strong process background in the waterfall approach and therefore they were involved in understanding how to protect the integrity of the product in the new context. The transition was supported by the Finnish PDU, who assigned some of its agile coaches to PDU W, so that the Finnish approach was applied and modified to fit the organizational context.

The organizational change mostly involved the set-up of:

 continuous programs instead of the old projects

 new processes

 new roles

 requirement areas

Oct. 2010

First Pilot Team

Apr. 2011

First Core Team

Nov. 2012

End of the Agile Transformation

Jul. 2013

First Release completely

(13)

8

The agile transition’s responsible studied a set of standard agile practices and adapted them in order to scale agile in such a large organization. They set up some principles to inspire the entire agile transformation. Then, more detailed practices were adapted directly by people working. The Leadership Team decided to apply different agile methodologies in each department. In detail, it selected:

 Scrum methodology for teams working in product development;

 Kanban methodology for teams working in concept development, maintenance, continuous integration and continuous analysis.

Product development teams were designed to be cross-functional, so they included people with different backgrounds: system design, software design and tester. The average number of people in each team was seven. The organization encouraged job-rotation inside the teams, so that all team members performed both design and test activities. This configuration was selected in order to:

 solve the communication issues between designers and testers

 let people within teams growing in competence

 increase team members’ flexibility

Moreover, each cross-functional team (XFT) rotated between product development and maintenance. In fact, at given time, certain teams working within the RAs were assigned to maintenance department. They typically worked six-nine months with maintenance activities and then turned back into product development activities. This additional teams’ rotation was conceived for getting new insights, improving the teams’ understanding of the product, considered useful for stimulating product and process. To summarize all above, the following core concepts are proposed:

Pull based approach:

o Kanban to visualize early phase studies and to control queues o One product owner and one product backlog with strict priorities

Requirement areas as scaling concept

o Enables independent prioritization of features per RA o Enables transparent R&D capability

(14)

9

Continuous programs in product development

o Release projects started as late as possible

Co-located end-2-end cross functional teams

o Scrum (100% resources) for feature development (R&D) o Kanban for Maintenance

Continuous Integration

o Frequent SW deliveries from XFTs to main SW branch o Automated, continuous and fast feedback to XFTs

o Branching of Main SW track as late as possible (in relation to the release date)

First Results

The agile transformation has brought several benefits since the earlier phases. In particular, the Leadership Team noticed improvement in the lead-time and in the number of TRs that was considered as an indicator of the overall product quality. These first results motivated the organization to continue with the agile implementation.

1.4 EVIDENCE OF THE PROBLEM: AGILE CREATES PROBLEMS FOR

PRODUCT INNOVATION

As the agile transformation went on, the strategic department at corporate level started to observe a negative trend concerning product innovation. The empirical evidence of the organizational innovation performance after the agile implementation was obtained by collecting longitudinal data on the organizational product and process innovation performances, for different firms belonging to the same company. This information came from different indicators such as the number of patents, the number of system improvements, the number of new product ideas brought at the idea box (a web-based suggestion box software to which every employee have access and may drop his new ideas) and the number of new process ideas as they came from the process methods and tools departments. As evident from the histograms presented below in Figure 1.4, representing PDU X, a German organization under the same company as PDU W, there has been a progressive increase in process innovation performance along the agile transition, which started in 2010, while, on the contrary, there has been a strong

(15)

10

decrease of all the three indicators of product innovation performance since the agile transition.

Figure 1.4: Process and Product Innovation at the PDU X

A secondary assessment conducted on an Italian unit, here called Organization A, showed quite clearly that the combination of Lean and Agile approaches potentially impedes organizational learning and innovation, calling for new Knowledge Management (KM) practices and different leadership behaviours to avoid potentially negative effects. Also in this case, an evaluation of product innovation was done considering as indicator the number of new product ideas brought at the innovation board, that was the only mean the organization had for collecting new ideas. The histogram in Figure 1.5 clearly shows that product innovation performance has been decreasing since the agile transformation that happened in 2010. In this case, the number of patents remained almost the same since 2009, given that most of the patent applications were made by the senior system management team, which was not heavily involved in the agile dynamics at that time.

(16)

11

Similar trends were observed in other PDUs and in other companies implementing Lean and Agile methods, such as Scania AB, leading the strategic department to call for more rigorous investigations on the effect of the agile transformation on both product and process innovation, with the aim to identify possible trade-offs and to develop solutions that mitigate potential undesirable consequences.

1.5 DELILA PROJECT

In response to the strategic department’s call for a deeper analysis on Agile effects on product and process innovation, a collaborative research project was built up at the end of 2012, involving people belonging to the same department and researchers from different universities. The project was named DELILA (DEsigning for Learning and Innovation in a Lean and Agile context) by the project consortium, whose vision was to increase organizational learning and innovation capabilities fruitfully utilizing lean and agile approaches in a sustainable manner.

The project aimed to:

1) explore the impacts of Agile and Lean methods on innovation by examining their effects on teams innovation performance and learning;

2) provide management actions (in terms of leadership models, KM strategies, KM practices, etc) needed to define suitable strategies for the organizations’ sustainability.

More in general, the project aimed to explore the current status of Lean/Agile implementation and its influence on business and innovation performances in at least four R&D organizations belonging to the same company.This was considered helpful in order to:

 Develop a better understanding of issues associated with the Lean/Agile characteristics and their contingencies in terms of different organizational factors

 Use the comparison between organizations as a way to review each specific situation and to better identify and understand the different dimensions of the problem at company level, in order to work on relevant contributions, propositions and recommendations.

(17)

12

 Elaborate, in a second phase of the project, a set of propositions or recommendations and to promote it to decision makers, company networks and stakeholders.

DELILA project had an impact on three levels:

 First level: it provided a better understanding of the current situation at local and

global level on a concrete basis, since it seemed there was no general view and estimation of situation.

 Second level: it analyzed concretely the existing situation in four R&D

organizations provided by the Project consortium and identidied present and potential issues.

 Third level: it took stock of best practices developed in other companies and

helped people to work on solutions and new approaches. A brief description of DELILA project is provided through Table 1.2.

Table 1.2: Overall description of DELILA Project DELILA PROJECT

Project Duration November 2012 – March 2014

Project Type Collaborative Research Project between the company and different universities in Sweden and Italy

Focus of the project At least four R&D Organizations under the same company

The following graph (Figure 1.7) clearly describes the project activities and planning. In particular, before the project started, a first pilot study was conducted in the Italian Organization A in May 2012, in order to start focusing the main issues connected to lean and agile implementation. After that, a German organization was involved in the assessment, lasting from November 2012 to March 2013. The last organization involved was the PDU W with its four R&D organizations.

(18)

13

1.5.1 PDU X ASSESSMENT

The assessment involved three research and development (R&D) organizations belonging to PDU X, each of whom adopted full agile scrum methodology. The study was conducted at the end of 2012, so 18 months after their transition to Agile.

The relevance of learning and innovation to maintain organizational competitive advantage justified the following research question:

RQ. How does the use of agile methods impact on product and process related innovation and learning in teams?

Data were collected through different sources:

1. Initial interviews with PDU X managers and Innovation coaches 2. Two workshops :

i. innovation and learning in agile teams; ii. stress in agile teams

3. An online survey of 73 multiple-choice questions and five open-ended questions addressed to agile team members

4. In-depth semi-structured group interviews with organizational stakeholders and new agile roles.

5. Collection of internal documents and presentations describing the main business processes and activities with their outcomes.

All these data were analyzed and the key results showed a tight linkage between product innovation and product learning. In particular, it was evident that the team’s self-regulated learning (SRL) fostered product innovation in the agile context. In fact, the principles of self-organization in Agile team transformed learning into a self-regulatory process. The SRL model underlined that the engagement in learning and innovation tasks was determined by the current knowledge and beliefs that contributed to build an interpretation of the tasks themselves, which enabled goal setting. The goals, in turn, are achieved by applying tactics and strategies that resulted in teams’ behaviors and teams’ outcomes. Internal and external feedback provided information that might confirm or refute the interpretation of the task and the adopted approach for learning.

(19)

14

The main results concerning learning and innovation domains were:

 The organization did not set any goal concerning learning and innovation at team level, and neither the teams did so spontaneously.

 As a consequence, teams did not commit themselves to product learning and innovation, and did not select any specific tactic or strategy for driving product innovation and learning. In fact they reported not to have time to dedicate to learning and innovation.

 What above justified the absence of product ideas generated by the teams. In fact,

there was no available spare time because of the continuous delays experienced during teams’ work.

 From the survey data, it was evident that teams were deeply involved in achieving operational goals, short delivery times, and in solving problems related to shipping delays.

 There was also some evidence that agile team members were not able to absorb new product knowledge after the conclusion of their work tasks. This was due to different reasons:

o Teams’ learning was mainly “by doing”, and there was very short time allocated to the transformation of teams’ tacit knowledge into explicit concepts that could be spread within the team and with other teams;

o Team members had very limited time and no external direction to improve their background and skills in other areas than the ones needed for the immediate project activities;

o Teams’ product learning was mostly fragmented due to the decentralization of product development tasks which were divided among different teams, and the difficulty they had to be updated with the functional changes implemented by agile teams not belonging to the same team.

o There were very limited ties allowing the diffusion and sharing of cumulated knowledge among teams and the level of documentation was poor.

o Most of agile teams had a “quick fix” approach to learning and did not spend time in deepening what they learnt.

(20)

15

 Concerning the teams’ beliefs, it emerged that people believed that quality was the most important goal to achieve.

 The evaluation of project performance was centred on cost, speed, quality and value dimensions

 Team’s internal performance was continuously monitored and supported by the team’s stakeholders.

All above could be synthetized through Figure 1.7, showing the above cited self-regulated learning model.

Figure 1.7: Self-regulated learning model

Another important result showed the linkage between the agile implementation and team’s learning. This was obtained through the analysis of the effect of agile routines on team’s behaviours and decisions, to better understand the effect of agile methods on product and process learning. This analysis led to the following discoveries.

The short, iterative, time-boxed development cycles promoted a fast and constant rhythm of work for teams. Hence, team’s product learning in the agile context seemed mainly characterized by:

 small windows of opportunity to exploit the product due to the high and constant work rhythm;

 different perceptions on the value of such opportunity among team members and convergence to pre-defined beliefs;

(21)

16

 the proximity of this opportunity to the features under development.

All above brought to a perceived reduction of team’s capability to absorb new product knowledge.

On the other hand, the agile excellence practices helped agile teams to continuously renew their process knowledge and contributed to shift the attention of the teams and the organization to process management. This was reinforced by the fact that the whole teams took the responsibility for processes and practices, by establishing a lateral communication layer made up of communities of practices and dense coordination activities.

The usage of agile practices formed and controlled team’s beliefs. It was quite clear that team members were enacted by the team’s stakeholders, who were jointly responsible for promoting agile/lean principles and operational project goals, which left very limited room for learning and innovation.

The influence of agile characteristics on team’s learning could be summarized through Figure 1.8. Additionally, the organizational design was analyzed. It seemed built up for favoring process innovation instead of product one. It is evident from the figures below Figure 1.9 and Figure 1.10) that there was a great imbalance of roles and structures for

driving activities tied to process and product innovation.

(22)

17

Figure 1.9: Organizational Design for Process Innovation

Figure 1.10: Organizational Design for Product Innovation

As evident from Figure 1.9 and Figure 1.10, product innovation interested only the higher levels in the company and did not seem to affect the middle and operational levels. Instead, process innovation was indirectly addressed at the strategic level through a focus on agile excellence practices, and was brought at the middle and operational levels of the organization through the role of the scrum master. Several management roles are designed to be Lean/Agile coaches for the agile teams: scrum master, product owners, line responsible. Teams were guided by their appointed scrum masters who injected new knowledge about agile/lean values and practices. Innovation coach role is a secondary role for a line manager belonging to the unit leadership team which was not appointed to the team and recognized as expert in any product learning domain. Concerning product domain, the firms relied on high levels of interactions among people in agile teams who

(23)

18

self-organized and are supposed to spontaneously generate product innovation ideas. On the contrary, for process domain, the organizations sustained process learning through the role of the Scrum masters who :

i. had good knowledge of lean/agile principles to be able to drive team’s evolution towards high performance;

ii. served as change managers in the team’s self-renewal process, encouraging their teams to challenge the status quo and improve their ways of working;

iii. promoted active inter-teams collaboration through the establishment of communities of practices.

For process innovation, all the unit members actively sought process innovation, in fact each agile team member was aware of the need of process improvements and made an individual judgment of the problem. He then communicated his judgment to other team members. A team level decision was made through a majority of vote of all members and was reported to the managers. Each manager discussed with other managers in the management team.

For product innovation, each member only followed the methods that he was most familiar with, as he had been trained by the organization, and made individual decisions merely based on how a similar problem was handled previously. So each individual made his judgment about what to innovate relying on his experience. Then, each single member passed his judgment to the designed innovation coach, who processed the information received and made his decision before processing further. The innovation manager made the organizational decision on his own.

Summing up, it is possible to argue that product innovation was seen as an individual activity, for which the organization did not set any rule. Process innovation was instead seen as a teamwork activity, completely aligned with flexible job responsibilities.

The innovation coach was only in charge to monitor, plan and provide infrastructures for product innovation, while the scrum master is a less narrow role, who encouraged team members to broaden their skills and competences and drove process innovation within teams. All the results obtained from the PDU X assessment needed a further validation in order to be considered accurate and reliable. This is why the DELILA project consortium decided to go on with another organizational assessment. The selected firm was PDU W.

(24)

19

CHAPTER 2. THEORETICAL OVERVIEW

In this chapter an in-depth description of the literature role within the project phases is provided and to follow, a review of the extant research used for the purpose of the project is presented. In particular, core concepts related to agile methodology are described, putting the emphasis on Scrum that is the methodology adopted in the four organizations object of this study, together with the existing literature on agile SW methodology and its potential connections with teams’ innovation and learning performances.

2.1 LITERATURE ROLE WITHIN THE PROJECT

Literature, both methodological and theoretical, was an essential source of information along all the project phases.

Methodological literature was analysed before undertaking the corresponding operative activities, while theoretical one was used as data source in parallel to empirical data with the aim of shaping the results and developing significant models.

The following flow-charts show the role performed by literature along the project phases, using red boxes.

In Figure 2.1, the preliminary project phase is represented. In particular, after the comprehension of the problem concerning organizational innovative performances after agile introduction, an in-depth analysis of the context was required. So, the researchers identified and studied the relevant literature on agile characteristics and, to follow, previous researches on the potential effects of agile implementation over organizational innovative performances, in order to understand if the problem had already been explored. In general, most research on agile methodologies has focused on the phases of its introduction and adoption (Dybå and Dingsøyr, 2008), whereas fewer studies investigate their effects on innovation (Abrahamsson et al., 2009). This lack of relevant studies led the researchers to decide for an exploratory research on the phenomenon, relying on a qualitative approach based on semi-structured interviews. So, literature on the topic was deepened in order to select the most suitable approach and an abductive research approach (Peirce, 1931) was selected. In fact, an “...abductive approach is considered fruitful if the researcher’s objective is to discover new things, other variables

(25)

20

and other relationships.” (Dubois and Gadde, 2002, p.559). Similar to grounded theory, the researchers’ aim was not to confirm an existing theory, but to generate new concepts and develop plausible theoretical models. Moreover, the abductive approach prescribes to begin with a generic formulation of the problem under investigation, then to start reviewing the relevant literature on the topic and to keep this task in parallel with the fieldwork (Ong, 2012). Therefore, before proceeding with the assessment, literature on exploratory and exploitative innovation was analysed in order to identify its key determinants. This literature review enabled the researchers to develop a first theoretical model that was used as a guideline for the following project phases.

After the preliminary phase, the concrete assessment began with the first-run assessment, outlined in Figure 2.2. The first step was to deeply investigate methodological literature on sampling selection, in accordance with the chosen abductive approach, in order to be able to select the most suitable sample for the interviews. Then, specific templates were developed for each organizational role and the interviews were performed.

Having a huge amount of data to organize and handle, software for qualitative data analysis was required. So studies were endorsed in order to select the most appropriate tool and MaxQDA® was chosen.

Before going ahead with data analysis, a further in-depth investigation on the abductive methodological approach for data analysis was carried on in order to understand the key steps to perform.

The results of the data analysis were then compared with the first theoretical framework to check if any change or enrichment was required. Since the empirical data introduced several improvements and modifications to the first model, a refined theoretical model was developed.

As second project phase, a secondary source of data coming from an organizational survey was analysed. So after the extraction of significant qualitative data from the survey’s free comments, the analysis was driven, in accordance with the abductive approach and the triangulation of results with the first data set was performed.

Then, in order to validate and enhance the emerging concepts and their relationships, pertinent literature was deepened and both literature and empirical data contribute developing a paradigm model for each identified concept (see Figure 2.3).

(26)

21

The development of paradigm models allowed the researcher to move from an exploratory to a confirmatory research, focused on a survey. In Figure 2.4, all the relevant steps for the survey design are shown. To get confirmation about the emerging theory, hypotheses needed to be developed, so the researchers had to pass from concepts to variables and to formulate the consequent hypotheses basing on the paradigm models. These activities were supported by an accurate study of the relevant methodological literature.

After the variables’ identification, theoretical literature was investigated in order to find appropriate constructs that were then modified to fit the agile context. This activity allowed the researchers to build the survey. Since the survey had to be administered to all the 1700 organizational employees worldwide, an online survey tool was necessary. Again, a comparison between different software was endorsed considering different factors such as data security, cost, usability, layout, features and answers’ manageability. Netigate tool was selected and questions were loaded.

Before the survey launch, a pilot test was performed in order to identify unclear questions or problems that might lead to biased answers. The first step of this pilot phase involved a methodological literature study to guide the researchers and to select a proper sample to which administer the questionnaire. After that, individual follow-up interviews were endorsed to collect people’s feedback and suggestion for improvements. Then, basing on the collected responses, the phrasing of the items was further improved and the survey was finalised and re-loaded on the tool (seeFigure 2.5).

A summary of the relevant research identified and studied along the project phases is provided in the next paragraphs.

(27)

22

(28)

23

(29)

24

(30)

25

(31)

26

(32)

27

2.2 LITERATURE REVIEW

2.2.1 AGILE METHODOLOGY

In this section an overview of the most common agile methodologies is provided, together with an in-depth description of Scrum that is the most widespread and also the methodology applied in the organizations assessed.

Lean and Agility

In the last decades, an increasing attention has been dedicated to the idea of “lean manufacturing (Womack et al., 1990), and to the broader concept of a “lean enterprise” (Womack and Jones, 1996). Lean approach is basically focused on the elimination of waste or muda (Towill and Christopher, 2002). Christopher (2000) stated that lean concepts fit in a context where the demand is rather stable, so relatively predictable, and the level of customization is low. In contrast, in the contexts of volatile demand and highly customizable products, a much higher level of agility is necessary. Agility is defined as “a business-wide capability that embraces organisational structures, information systems, logistics processes and, in particular, mind- sets” (Towill and Christopher, 2002, p.301). Flexibility is the core feature of an agile organisation. Hence, the concept of agility in the business environment takes its origins in flexible manufacturing systems (FMSs). Then, as time goes by, the idea of flexibility was broadened beyond the manufacturing context so that agility became a delivery philosophy (Towill and Christopher, 2002). For the purpose of this thesis, the concept of agile will be deepened focusing on the software development context.

Agile software development methods

Agile so ware development methods are a set of prac ces for so ware development, theorized by experts (Agerfalk and Fitzgerald, 200 ). These methods grow as a form of response to tradi onal or waterfall methods (Dyba and Dings yr, 2008). In fact, in contrast to the traditional approach in which every problem is claimed to be fully specifiable and to have an optimal and predictable solution, agile processes face the unpredictability trusting on people and their creativity instead of processes (Cockburn and Highsmith,2001) . Larman and Basili (2003) recognise as first agile method the Dynamic Systems Development Method (DSDM), followed by extreme programming (XP),

(33)

28

born in 1996 from the Chrysler C3 project (Anderson et. al, 1998). In 1998, the word ‘‘agile” and ‘‘software process” were combined for the first time (Aoyama, 1998). Afterwards, other methods were created, among which the Crystal family of methods, EVO, Feature-Driven Development, Lean Development and Scrum. In 2004, a new version of XP was developed (Beck, 2004). In Table 2.1 an overview of the best-known agile development methods is provided.

Table 2.1: Main Agile Development Methods and References

Agile Method Characteristics Reference

Crystal Methodology

Family of methods (Clear, Yellow, Orange, Red, Blue) for co-located teams with different sizes and criticality. Crystal Clear, the most similar to agile methods, focuses on communication in small teams developing not life-critical software. It is based on seven properties: frequent delivery, osmotic communication reflective improvement, personal safety, focus, easy access to expert users, Technical Environment with Automated Tests, Configuration Management and Frequent Integration. Cockburn, 2004 Dynamic Systems Development Method (DSDM)

Splits each project in three phases: pre-project, project life cycle, and post project. DSDM involves nine principles: active user involvement, team’s empowerment in decision making, focus on frequent delivery, correspondence to current business needs, iterative and incremental development, possibility of reversing changes, definition of the high-level scope before the project starts, testing during the project lifecycle, and efficient and effective communication.

Stapleton, 2003

Extreme Programming (XP, XP2)

Emphasizes the best practices for development. It is made up of twelve practices: the planning game, small releases, metaphor, simple design, testing, refactoring, pair programming, collective ownership, continuous integration, 40 hours week, on-site customers and coding standards.

The version ‘‘XP2” is composed by the primary and corollary practices. The primary ones are: sit together, whole team, informative workspace, energized work, pair programming, stories, weekly cycle, quarterly cycle, slack, 10-minute build, continuous integration, test-first programming, and incremental design.

Beck, 2000 Beck, 2004 Feature-driven development (FDD)

Mixes model-driven and agile development focusing on initial object model, work divided in features and iterative design for each feature. It is suitable for critical systems’ development. Each iteration of a feature is made up of two phases: design and development.

Palmer and Felsing, 2002

Kanban Kanban is a flavour of agile focusing on the workflow and continuous delivery. This allows Kanban teams to manage quality closely and to continuously deliver work to the customer.. It requires to: visualize the work flow through the system, limit the work in process at each step to ensure not to exceed the capacity, measure and optimize the work flow through the system to make continuous improvements.

Anderson, 2003

Lean SW development

An adaptation of lean production principles, in particular from the Toyota production system for software development. It is composed by seven principles: eliminate waste, strengthen learning, postpone decision making, deliver as fast as possible, empower the team, build integrity, and see the whole picture.

Poppendieck and

Poppendieck, 2003

(34)

29

Scrum It is suitable for project management in situations where it is difficult to plan ahead, embeds mechanisms for process control where feedback loops constitute the key part. Software is developed by a self-organizing team in short iterations called sprints, starting with planning and ending with a review. Features to be developed are listed in a backlog. The product owner decides the prioritisation for the backlog items to be developed in the following sprint. Team members coordinate their work in a daily stand-up meeting. One team member, the scrum master, is appointed to solve problems that stop the team from working effectively.

Schwaber and Beedle , 2001.

The following pie chart shows the distribution of agile methodologies, as resulted from the 2011 “State of Agile Survey Results” by VersionOne Inc. As evident from the Figure 2.6, Scrum is the most widespread methodology.

Figure 2.6: Distribution of agile methodologies

Moreover, according to Forrester research (West and Grant, 2010), the agile development methods have reached a wide range of adoption. In fact 35% of IT professionals responding to Forrester/Dr.Dobbs global developer technographics® survey, in Q3 2009, described their development process as agile, and Scrum resulted to be the most used agile methodology. This is also in line with the report by Evans Data Corp. (EDC) about their 2009 North American Development survey, stating that agile development was the primary approach for 39% of respondents, meaning that it has become the most popular methodology in North America.

52% 14% 9% 8% 3% 3% 2% 2% 2% 1% 4%

Agile Methodology Used

Scrum Scrum/XP Hybrid Custom Hybrid Don't Know Kanban ScrumBan FDD XP Lean DSDM

(35)

30 Scrum development method

Scrum overview

Scrum is an agile approach for the development of innovative products. A standard agile development approach is presented in Figure 2.7.

Figure 2.7: Agile development approach (Rubin, 2012, p.2)

The first step is to create a product backlog, that is a prioritized list of the features required to develop the product. The backlog ensures that the team always works on the highest prioritized items first. The work is performed in short iterations called sprints, usually lasting from one to four weeks. During each sprint, a self-organizing and cross-functional team performs all the required tasks – like design, build and test - to produce finalised and working features to be included in the software product. In general, the total amount of tasks put in the product backlog is too big to be concluded by a team within a sprint. So, at the beginning of each sprint, the team gathers for a meeting called

sprint planning, in which team members plan the sub-set of the backlog items on which

focus their efforts in the upcoming sprint. At the end of the sprint, the team reviews the work performed with the stakeholders and gets their feedback in order to improve for the next sprint, and has a potentially shippable product, to be released when required. Origins and history

Scrum’s origins can be referred to a 198 Harvard Business Review article, “The New New Product Development Game” (Takeuchi and Nonaka 1986), reporting how firms such as Honda, Canon, and Fuji-Xerox produced outstanding results using a scalable, team-based approach to the product development. The article also underlines the importance of empowered and self-organizing teams and schematizes the managerial roles in the

(36)

31

development process. This paper gave birth to the concepts characterising what today is called Scrum. The term Scrum comes from rugby, referring to a method of restarting the game after an accidental infringement or when the ball has gone out of play. Takeuchi and Nonaka (1986) used the metaphor of rugby to describe the product development: in fact, in contrast with the standard approach to product development that could oppose the goals of speed and flexibility, a holistic or rugby approach, where a team sticks together and passes the ball back and forward, may better fit the actual competitive requirements. In 1993, Jeff Sutherland’s team at Easel Corporation developed the Scrum process for software development combining concepts from Takeuchi and Nonaka (1986) with the ones from empirical process control, iterative and incremental development, software process and complex adaptive systems (Rubin, 2012). In 1995, Ken Schwaber produced the first article on Scrum (Schwaber, 1995). Although Scrum is mostly adopted for the development of software products, the key Scrum values and principles can be used to develop different kinds of products or to manage different work flows, such as hardware development and marketing programs.

When to use Scrum

Before Scrum, many organizations had survived by being no worse than their competitors (Rubin, 2012). The organizations that have meticulously applied Scrum are experiencing several benefits, such as:

- Delighted customers, since they receive what they really want. - Improved ROI by delivering smaller and more frequent releases. - Reduced costs, uncovering the organizational dysfunctions and waste. - Fast results thanks to the focus on deliveries.

- Confidence to succeed in a complex world where they must quickly adapt.

- Improved job satisfaction, due to the frequent collaboration that improves interpersonal relationships and mutual trust among team members.

Although Scrum could be an excellent solution for many situations, it is not the appropriate solution in all environments. The Cynefin framework (Snowden and Boone, 2007) helps to distinguish the situations in which the firm operates and to select an appropriate approach. It identifies five domains: simple, complicated, chaotic, complex and disorder (see Figure 2.8).

(37)

32

Figure 2.8: Cynefin framework

Complex Domain

Things are mostly unpredictable, so it is important to explore in order to learn more about the problems and then to adapt basing on what learned. Working in these domains requires creative and innovative methods and an experimental environment. This domain includes both innovative new product development and improvements to existing products with innovative features.

Scrum is especially suitable for operating in these complex domains.

Complicated Domain

This is the domain of good practices dominated by experts that are called to assess the situation, to analyse different options and to base their decisions on those good practices. Scrum can work with these problems, but it might not be the best solution. Much of daily software maintenance falls into this domain.

Simple Domain

In case of simple problems, it is not difficult to see causes and effects, so usually the correct answer is obvious. This is the domain of known solutions coming from best practices. After the assessment of the situation, it is possible to identify the appropriate predefined solution.

Scrum can be used for simple problems, but it is not the most efficient tool.

Chaotic Domain

(38)

33

case, Scrum is not the best solution, since it is important to act immediately and decisively.

Disorder

The disorder domain occurs when it is not easy to understand in which other domain the firm operates. In this case, the best option is to break down the situation into fundamental parts and assign each one to one of the other four domains. So the only thing to do is trying to get out of this domain.

In case of highly interrupt-driven work it is not possible to plan ahead the sprint work, so Scrum is not suitable. Instead, in these cases, the better approach to adopt is inspired to Kanban (Rubin, 2012).

To summarize all above, it is possible to argue that Scrum can help firms to face the changes that come with all complex product development efforts and disclose the malfunctions and waste that inhibit organizations from reaching their true potential (Rubin, 2012).

Scrum Framework

Scrum is not a standardized process but is a framework helping firms to organize and manage their product development work. The Scrum framework is built on a set of values, principles, and practices that constitute a base for the organization, to customize by adding its peculiar practices and approaches. The result will be a version of Scrum that is unique for each organization (Rubin, 2012). The main scrum values are fairness, openness, bravery, respect, focus, confidence, empowerment and teamwork, while the Scrum principles will be described in the following paragraph. The Scrum practices are represented by specific roles, activities, artefacts, and associated rules (see Figure 2.9).

(39)

34

Figure 2.9: Scrum Framework

Scrum Roles

The Scrum framework prescribes the presence of one or more Scrum teams, made up of three different roles: product owner, scrum master and the development team, as shown in Figure 2.10.

(40)

35

Product Owner

The Product Owner is responsible for the features to develop and for their priority. He also conveys to all the stakeholders the vision of what the team is trying to achieve. So he is responsible for the overall success of the solution being developed. The product owner has to make sure that the most valuable work possible is always performed, collaborating with the Scrum Master and the development team (Rubin, 2012).

Scrum Master

The scrum master is responsible for assuring that the agile team respects scrum practices, principles and values. This role is seen also as a process owner for the team, who balances the requests from the project key stakeholders and is in charge of solving impediments that inhibit teams from working effectively, or escalating them (Cohn, 2009). The Scrum Master has no authority over the team, so this role differs from the traditional role of project manager or development manager; he is more like a leader than a manager (Rubin, 2012).

Development Team

Traditional software development approaches prescribe different roles, such as architect, programmer, tester, designer. Scrum, instead, refuse the traditional roles in favour of a development team, in which everyone should work together and cooperate to complete the set of activities they have committed to during the sprint (Cohn, 2009). The team is built through the cross-functional combination of people responsible for the design, the construction and the test of the required software product. The development team self-organizes to decide the best way to accomplish the goals established by the product owner. The team is made up from five to nine people, with different backgrounds in order to be able to produce good-quality and workable pieces of software (Rubin, 2012).

Scrum Activities and Artifacts

The product owner has his own vision of the product. Because this vision can be large, a

grooming activity is required to break it down into a set of features that are collected into

a prioritized list called the product backlog. A sprint starts with a meeting called sprint

planning, involves the development work along the sprint, called sprint execution, and

ends with the review and retrospective. The number of items in the product backlog is usually big, so that the team cannot complete all of them within a sprint. So, before the sprint starts, the team needs to gather and select a sub-set of tasks to be accomplished

(41)

36

during the upcoming sprint. So the team produces a forecast of what team members would be able to deliver each sprint (Schwaber and Sutherland, 2011) and then committed to this forecast. To make sure that the commitment made is realistic, during the sprint planning the team members build another backlog called sprint backlog. It describes all the tasks the team plans in order to design, build, integrate, and test the selected sub-set of features from the product backlog during the upcoming sprint. Then, there is the sprint execution, during which the team performs the tasks required to develop the features. Every sprint day the team gathers for the daily stand-up, focusing on what each team member accomplished the day before and will accomplish the coming day, with the aim to fully understand what work has been done and what still remains to do. At the end of the sprint the team has produced a workable and potentially shippable

piece of software and performs two different activities: the sprint review or demo during

which the team shows the product owner, customers, management and developers from other teams what has been completed during the sprint and the sprint retrospective to spontaneously reflect on how the team is doing and to find ways to improve. The outcome of these activities could be adaptations to be put into the product backlog or be included to the team’s development process. Then the sprint cycle restarts as described above. After a reasonable number of iterations, the product owner’s vision will be accomplished and the product could be released.

Agile scrum principles

The agile principles that underlie Scrum are taken from the Agile Manifesto (Beck et. al, 2001) and from “the Scrum Guide” (Schwaber and Sutherland, 2011). They can be organized in the following macro-categories (Rubin, 2012):

- Variability and uncertainty: Scrum leverages the variability and uncertainty, typical of product development, to come up with innovative solutions. The core principles are: o Take Up Beneficial Variability: a certain level of variability is required to produce a

different product each time: each feature built within a product is ad should be different from any other feature within the same product.

o Apply an Iterative and Incremental Development: both ideas are used during the sprint to take all the possible advantages.