When Agile Harms Learning and Innovation: (and What Can Be Done About It)

Implementing Agile Methods in Company E

To gain insights into the large-scale implementation and outcomes of Agile, we closely observed over a five-year period (2012-2017) the implementation, execution, and consequences of Agile Scrum practices in large-scale software development settings in a major multinational corporation operating in the telecommunications sector, Company E. We interviewed more than 100 informants at the team level, middle management, and top management levels and added analysis of documents and archival records from the involved R&D units and relevant intra- and inter-unit community groups to corroborate and augment evidence from our interviews and observations. ⁹

At the time of Company E’s transition to Agile, the pace of change in the telecommunications market was increasing, as the telecom, IT, and media industries were converging into a broader ICT industry. The company decided to step up investments in its core product areas, involving an increased focus on software production and professional services. Company E also introduced programs to improve its marketing success by better satisfying customer needs. The adoption of Agile was also seen as a means to this end.

Our research particularly focused on agile implementation in eight large R&D units of Company E, which involved thousands of programmers and software developers, hundreds of middle managers, ¹⁰ and several senior managers. These R&D units were dedicated to the core products of Company E and all of them had transitioned to post-bureaucratic structures, abolishing hierarchies and embracing a flatter organizational model based on self-managing teams. (The firm also had R&D units devoted to more radical R&D in which Agile was not implemented.)

Agile was implemented because senior management wanted to better adapt to customer needs, increase the speed of software deliveries, and reduce the costs of software implementation. To support Agile organizationally, senior management changed the organizational design to allow for cross-functional teams and flatter structures that were believed to increase the speed of decision making. Thus, in the eight R&D units, team members with different backgrounds and experiences were asked to work together in a cross-functional manner. Internal product experts, who were embedded in cross-functional teams and participated in software development with their peers, were only occasionally involved in other teams’ product-design choices, whereas prior to the transition to Agile, their involvement had been mandatory and their suggestions were always implemented. Moreover, team members were explicitly told that they should not invest too much time in updating the project documentation, as the agile product-development process minimized handovers by allocating the design and development of pieces of software to the same team.

To compensate for this “lightweight” approach, team members were told to keep product code simple, and, hence, easily understandable. Similarly, they were instructed to respect the software architecture of their products as much as possible, as the intent was to use the system architectures to enhance inter-team coordination. To make team members better software developers, senior managers introduced the craftsmanship system, which was essentially a new approach to peer-to-peer training that engineers working in the agile teams needed to acquire.

To coordinate activities across teams, stakeholders of agile teams (such as product owners) divided work packages into smaller, independent functional items, which allowed them to allocate the items to different teams during each iteration cycle and assemble the developed parts at the end of each iteration. Management supported the Agile transformation process through a clear and consistent communication strategy that emphasized the main advantages of the application of Agile, including (1) an improved customer interface, which would lead to more frequent releases and more responsiveness; (2) an increased motivation for team members, as they expanded their competences beyond their core expertise; and (3) an improved IT infrastructure for test automation with the potential to improve product quality.

In some ways, the large-scale Agile transformation in Company E was successful. In some cases, R&D units succeeding in reducing end-to-end lead time by 60% and maintenance costs by 40%. However, the transformation also had consequences that were neither anticipated nor desired by Company E’s management.

Agile Challenges in Company E

Prior to the transition to Agile, Company E had emphasized the reuse of software assets, such that the development of new functionalities made systematic use of a core set of software assets, which contributed to realize economies of scale and scope. However, this also meant that newly developed software had to take into account a variety of existing assets that reflected past requirements and pre-defined architectural designs which necessitated a high degree of familiarity with the existing code. However, during the three-week iteration cycles, developers could only gain a temporary and weak understanding of the relevant part of the code. At the same time, the likelihood that this knowledge would be reused during the next iteration was remote.

The software products developed by Company E consisted of a mix of components produced in-house and components purchased from outside developers. With the transition to Agile, those components that had originally been assigned to few, specific teams were now assigned to multiple teams for parallel development, the aim being to reduce time to market. However, the coordination of software development across teams became costly and difficult after the transition to Agile because of a lack of effective knowledge-integration mechanisms. Interactions aimed at coordinating interfaces among components emerged spontaneously, but in an uncoordinated manner.

Thus, the initial intention to maintain a modular product design with a high degree of interdependency between components and documented standardized product interfaces was difficult to realize because a hierarchy of technical authority and effective inter-team coordination mechanisms were lacking. Given the parallel and decentralized development of product components, the information structures and standardized component interfaces were inadequately maintained in the design of new product solutions. Formal mechanisms that connected employees across teams (e.g., inter-team meetings and demonstrations) were insufficient to convey the complexity of the emerging product knowledge, which was volatile (renewed every three weeks) and often highly tacit.

Agile development stresses the relevance of “architectural” knowledge through the development of new products based on modular designs. However, the incomplete information structure surrounding the evolving product architecture had profound implications for the development process in Company E. In addition, the pre-existing code consisted of monolithic blocks of code that were difficult to navigate and read. In response, teams attempted to develop products by experimenting with new component designs and alternative arrangements of code components.

The existence of a large-scale legacy code, made up of millions of lines of code developed in a traditional manner as a monolithic block, made it difficult to update the software programs, especially given the lack of knowledge about the software system. Notably, the new knowledge-management strategies (i.e., decentralized software production and a lack of central coordination mechanisms for diffusing tacit knowledge) were not accompanied by the widespread emergence of modular product design, which could give rise to fewer software components that were easy to assemble. Customer requirements were modularized and decomposed into smaller chunks, and solutions were reassembled at the system level through the automated integration of software deliveries. However, due to the absence of knowledge-recombination mechanisms that could collect and organize the temporary and tacit knowledge developed within teams during each iteration cycle, team members could not regularly update themselves on the development of their products. Demonstrations designed to provide an overview of the work done by a single team at the end of each iteration cycle were rarely attended by members of other teams, as they were too busy with their own deliveries. Team members therefore found it difficult to identify the relevant impacts of the new customer requirements on their legacy products and to design product updates.

Team members also faced substantial uncertainty about whom to contact for advice concerning customer requirements. In essence, team members became users who interacted with a system that was evolving through an ecosystem of developers, and these users often had interchangeable roles. Most of the knowledge creation occurred within teams through the individual interactions but with some difficulty to be spread outside their teams. The integration of newly created knowledge emerging from teams into organizational knowledge requires an ability to systematically integrate the different sources of knowledge. However, Company E lacked such a systematic ability. Multi-team meetings were supposed to function as knowledge-transfer mechanisms, but they failed to convey complex and contextual knowledge. Such knowledge transfers may require stronger ties that are characterized by closer and frequent personal interactions among team members. They may also demand the use of more formalized routines or self-contained task teams. None of these were in place.

Still, managers felt they needed to identify processes that would support an agile approach in a large-scale context. Middle managers played a key role in facilitating the agile implementation, but they often struggled to make sense of the changes themselves. Charged with implementing such changes, they experienced intense confusion, as they thought of Agile as too vague to provide guidance for the managerial tasks associated with properly reshaping the intra-organizational boundaries. Managers were also aware that there were no standard large-scale implementations of Agile that they could imitate, and that they therefore had to improvise solutions. Therefore, they relied to a large extent on the existing coordination mechanisms that the company used to manage its dependencies. These dependencies were inherent in the structure of their products (e.g., components of a system may interact, thereby constraining the kinds of changes that can be made to a single component), in the decomposition of organizational goals into activities, and in the assignment of activities to actors and resources spread across different departments or units. As a result, decision-making and goal-setting procedures remained highly centralized. The way in which regular feedback loops and reporting between teams and managers was implemented enabled managers to retain tight control.

However, managers realized that some decentralization of decision making could facilitate the execution of project tasks. Thus, they canceled the previous multi-layered networks of knowledge consisting of product experts used for consultation by employees, and of product committees in charge of approving technical documents and of giving high level directions on proposed technical solutions. Before the Agile transformation, these networks were able to enrich individual tacit knowledge with explicit knowledge and practical judgment. Through this combination of knowledge, individuals could have better support in the realization of their exploitation activities and create robust dynamic organizations that enabled environmental adaptation and creation simultaneously.

Unanticipated Consequences for Learning and Innovation

Quite contrary to initial positive expectations regarding the implementation of Agile, management of Company E increasingly had to realize that its adoption had massive, unanticipated, and far from beneficial consequences. Thus, innovation initiatives increasingly failed, the number of new patents and product improvement ideas declined, and team members found it increasingly difficult to implement customer requirements. Agile—which was expected to greatly enhance individual initiative, improvisation, and collaboration—seemed to reduce individual learning and ideation activities. The company’s focus on the collection of new product improvement ideas also declined, as management resources were spent on implementing the transition to Agile, ensuring the quality of existing products, increasing the level of productivity, and reducing the time to market. Although the R&D units did not define specific key performance indicators (KPIs) on ideation performance, ideation was monitored through metrics such as the number of patents and ideas for product improvements, and these numbers showed that most of the observed R&D units exhibited declining ideation performance.

Moreover, R&D managers consistently observed that the application of Agile reduced individual employees’ motivation to learn. Thus, team members seldom went beyond learning what was strictly needed to implement a requested software update. Similarly, many team members felt that the transformation to Agile had negatively affected their colleagues’ interest in learning. In addition, R&D managers reported high levels of stress within the Agile teams, which further reduced the exploration of new technical solutions. According to these managers, such stress was due to the difficulty of keeping pace with the speed of the software development. Prior to the transition to Agile, the organization worked with delivery cycles lasting 18 to 24 months; but after the transition, software deliveries were scheduled every three weeks, while software integration and related integration testing activity took place every day. In addition to the perceived pressure, team members pointed to several other factors that seemed to inhibit their learning as well as their understanding of their current products and creativity (especially the absence of detailed product documentation). There was also a lack of clear and shared architectural knowledge among teams. Although senior management began to recognize the challenges, they were unable to point to specific contextual factors at the individual, team, or organizational levels that might have contributed to the inertia in individual learning or to the decline in organizational ideation capability.

#1: Learning and Ideation Behaviors Are Not Legitimized by the Team

The performance systems used to measure and reward team members along with the scheduling of their activities generated high levels of interdependence among team members. In addition, during daily scrum meetings, team members were asked to observe each other’s progress and highlight any obstacle or constraint within the team in order to minimize the risk of not accomplishing team tasks.

When team members are highly interdependent, they typically develop a shared perspective that allows them to coordinate actions in response to internal and external contingencies. High levels of interdependence also tend to create team norms (i.e., standards of approved behaviors inside a team) and team identities (i.e., rules of action for decision making that help resolve ambiguities). These become ways of controlling individual behaviors and cognition. However, our data point to a divergence between the goals set by managers in the observed R&D units and the professional norms developed by team members. Management continuously stressed the importance of pursuing learning and ideation behaviors to secure the constant evolution of the existing products, but team identities and norms did not include these behaviors as important.

The delegation of project tasks to teams with deliveries every third or fourth week, along with the presence of numerous feedback and reporting mechanisms, served to center team’s attention on short-term project-development activities, shaping the team’s identity so that it was completely focused on the need to deliver new product releases. As a result, team members did not devote time to generate new product improvement ideas or reserve time to explore the software functionalities embedded in the software systems. Thus they did not gain a better understanding of the required changes before implementation, they avoided engaging with communities of practice ¹² activities, and they dropped the monthly learning days organized by their units.

#2: Organizational Structure Drifting toward the Prioritization of Urgent Issues above Learning and Innovation

Team members were under constant pressure to deliver and the presence of short feedback loops within each work iteration increased the time pressure and the debilitating effects of stress that accompanied it. These loops were mainly defined at the boundary between the team and the organizational environment and involved frequent interactions between team members and members occupying (agile) organizational roles (i.e., product owners and middle managers). The loops served to inform teams about decisions of relevance for projects and to inform those in agile organizational roles about teams’ progress. However, the latter often exerted pressure on the teams and reinforced certain counterproductive behaviors.

Figure 1a and 1b shows two competing feedback processes implemented by the R&D units: one serving to introduce new project-development activities; the other aiming at generating new product and technology improvement ideas. The arrows in Figure 1a indicate the direct interfaces between the various agile roles and the teams, while Figure 1b shows the interactions of the innovation manager with the entire organization. As shown in Figure 1a, new product-development activities resulted in several interactions with different agile organizational roles at the team and individual levels. However, the organizational structure for innovation projects (Figure 1b) reduced individual social interactions with innovation stakeholders, reducing the chance that a team member would encounter an innovation champion.

OPEN IN VIEWER

Figure 1.

Agile feedback loops: (a) #2 the prevalent effect of agile feedback loops for project-development activities; (b) agile feedback loops for the news product ideas.

This organizational setup undermined the organizational ideation capacity, as it reduced the opportunities for innovation champions to present the generation of new product ideas as an important value. The absence of interactions between the two feedback networks created conditions for ideation initiatives to use the same organizational resources as development projects. However, the innovation network—which was based on a closed-loop structure that covered the innovation managers and individuals in teams—was unable to create opportunities for team members to spend time on generating new product improvement ideas. Shorter feedback loops and well-defined performance goals for new development projects consumed the resources and captured the team members’ attention and kept it on the accomplishment of new development goals instead of generation of new product improvement ideas.

#3: Reduced Knowledge Accumulation

Team members reported that the cross-functional and cross-product nature of Agile team activities dragged them into unrelated activities, such as working on different software systems or covering different roles. As a result, they forgot their knowledge related to specific software products. Attempts to learn and absorb the information needed to implement new software functionalities represented such a volume of new knowledge to that they taxed team members’ absorptive capacities. These difficulties were magnified when new information about variations in requirements arrived before the foundation of the software system was well understood. As a result, team members were unable to transform their experiences into meaningful learning, which they found frustrating. They consequently became slower and less productive than they had been before Agile was implemented.

Overall, teams were pushed by organizational stakeholders to stretch their competences and apply them across several organizational domains, which often resulted in team members working more in a cross-functional and cross-product manner within their team. The reduced differentiation of roles within teams (due to cross-functionality) and teams’ commitment toward the specific product releases undermined both the value and existence of team members’ product expertise within the organization. Consequently, given their reduced background knowledge, team members felt unable to understand the nuances of their jobs or to handle the complexity of their activities.

#4: Reduced Knowledge Integration

The Agile Scrum framework also failed to add new knowledge to the organization’s knowledge stock. Multi-team meetings were introduced more as a way to coordinate activities among teams than to transfer knowledge across them. For instance, few people could attend demonstrations owing to their high workloads and it was impossible to attend every demonstration given the high number of teams.

An inherent challenge is that knowledge that is produced in complex product development within Agile teams may be highly context dependent and may remain tacit—particularly when, as in the case of Company E, there is minimal focus on product documentation. Given the absence of organizational routines to incorporate new knowledge into daily operations and to facilitate access to the constantly evolving organizational knowledge, team members found it difficult to acquire new knowledge and even reported declining stocks of job-relevant knowledge after the transition to Agile.

Unless the information system is effectively integrated into a firm’s operational strategy, decentralized operations will not lead to goal achievement. ¹³ Managers provided team members with direction and focus by regularly communicating a topic of organizational importance. Team members were invited to offer their perspectives on the relevant topic, which they were then expected to back up with documentation. However, as senior managers were too far removed from the company’s operations and the teams, they often failed to define the right topics. In addition, initiatives such as the creation of communities of practice, the appointment of product experts, and “learning days” remained isolated instances of information diffusion rather than effective instruments for knowledge development and sharing. Therefore, evolving/emerging knowledge was not integrated into day-to-day team operations because of the lack of effective integration mechanisms.

#5: Loss of Know-Who Knowledge

As a result of the decentralized development of knowledge within teams, individuals found it difficult to easily identify who might have the knowledge they needed. This led to an erosion of “know-who” knowledge. Significant investments were made in promoting teamwork and collaboration among team members. However, no one was appointed to play an active role in initiating the change and improving cooperation among teams. Thus, no role was established to break up pre-existing norms, restructure individual behaviors, deal with teams’ isolation, systematically help team members develop innovative ideas, or determine contingency rewards that would motivate team members to more actively clarify problems and propose novel solutions. Therefore, Company E was increasingly suffering from an inability to utilize the vast amount of knowledge possessed by the individual teams.

Moreover, given the absence of formal support networks, team members increasingly turned to friendship and trust-based networks rather than to advice networks that could better direct them to relevant sources of knowledge, and which research suggests that are extremely important for innovation. ¹⁴

#6: Lack of Individual Self-Efficacy

Individual team members perceived a lower level of personal efficacy related to generating new product ideas, developing high-quality software products, and executing changes in the program code. Moreover, team members experienced more frequent failures in developing new product functionalities due to the daily results of the automatic integration tests, which confirmed that, given their limited experience and knowledge of the products, they were unable to master their products as well as in the past. In addition, they felt they lost the ability to modify and control the environment given the more volatile knowledge that the organization developed along with the shorter product-release cycles. In line with the central role played by efficacy expectations in reactions to tasks and in motivations for task engagement, individual team members showed cognitive inertia in terms of learning and ideation—they waited for others to solve their problems.

Diagnostic Tools for Addressing Agile Challenges and Pitfalls

We now offer a systematic approach to reducing the negative effects of Agile implementation on individual learning and ideation capabilities, effects that threaten upgrading existing products and innovating new ones. To understand the implications of Agile, we collected data not only from the R&D units that experienced problems with learning and ideation after the implementation of Agile, but also from one unit that did not fully implement Agile and reported fewer problems. This helped us develop two analytical tools to help managers create conditions for individual learning, ideation, and exploitation in a large-scale Agile setting. We subsequently tested these tools in Company E and in a multinational insurance company.

The tools are based on our understanding of how the implementation of Agile can influence individual behavior in relation to learning and ideation. To understand how individual behaviors are related to organizational influence, we analyzed individuals’ connections with the organizational environment, the feedback they received, and the routines they followed. We also explored individuals’ knowledge stock after the transition to Agile by asking team members about their daily operations and the cognitive means they used to accomplish them. Moreover, we asked team members about their emotional reactions to the Agile transformation.

Based on these data, we developed a framework (see Figure 2) of the main influencing mechanisms to help companies evaluate workplace sentiments after implementing Agile. It can also be used to examine the relationships between an organizational design based on Agile and individual behaviors related to individual proactiveness to learn and engage in ideation.

OPEN IN VIEWER

Figure 2.

Theoretical framework showing the mechanisms of influence on individual behaviors and solutions.

Many of the relevant factors in the framework have already been described in connection with the above potential pitfalls of Agile. We now organize them to make their direct influence on individual behavior toward learning and ideation activities more visible. Our findings strongly suggest that individual behaviors toward learning and ideation activities are influenced by the interaction of two types of feedback: positive (or self-reinforcing) feedback (which happens because of Agile Scrum routines) and negative feedback (which occurs from constant interactions with Agile stakeholders). We also observe that declining learning and ideation performance within self-managing teams arise from the decreasing ability of team members to absorb new competences, from difficulties in accessing relevant knowledge in the company due to the absence of knowledge-transfer mechanisms, and from low perceived self-efficacy due to the negative impact of past failures induced by the difficulty of implementing new customer requirements.

Our tools enable the identification of the feedback processes (see pitfalls 1 and 2) and other dimensions of the agile work environment that inhibit knowledge accumulation and access (see pitfalls 3, 4, and 5). They also highlight the dynamics leading to inertia in individual learning and ideation (see pitfall 6).

Diagnosis: Identify Conditions that Inhibit Learning and Ideation Activities

The questionnaire in Table 1 highlights key factors that influence the individual proactiveness to ideate and learn, which in turn affects the capacity to exploit existing products.

OPEN IN VIEWER

Table 1.

Diagnostic Questionnaire.

	Questions
Access to internal knowledge	1. Do members of your agile teams have the possibility to work systematically with people outside their teams or the organization? 2. Do members of your agile teams have the organizational support needed to exploit the product and inject fresh knowledge from outside the team?
Degree of knowledge accumulation	3. Do members of your agile teams work on a limited set of software functionalities that are easy to understand? 4. Do members of your agile teams work across products that are not very complex (e.g., count the lines of code, look for the presence of legacy system and the availability of architecture documentation)? [This also affects teams’ internal tensions]
Internal tensions within teams	5. Do members of your agile teams use a diversified set of performance goals by including, for instance, project and innovation goals when measuring their performance? 6. Do members of your agile teams have recurrent and formal routines for reflecting on what they have learned about the products they have just developed?
External tensions on teams	7. Are members of your agile teams interacting with different stakeholders (e.g., project development and innovation projects)? 8. Do those stakeholders (see 7) often interact via formal or informal meetings to discuss project or team performance? 9. Are members of your agile teams engaged in short feedback loops? Are they balanced between project deliveries and innovation/creativity activities? 10. Does the backlog contain items that indicate when it is necessary to innovate the product? 11. Are members of your agile teams constantly interacting with at least two specific actors (e.g., scrum master and innovation manager) who foster a balance in team activities focused on team projects and creativity (e.g., better quality in the developed product, faster delivery speed, number of new product ideas)? 12. Does the career development of the members of your agile teams depend on evaluations of their project-development and creativity performance?
Individual efficacy	13. Do members of your agile teams perform well in term of project results? 14. Are members of your agile teams familiar with the product they need to exploit?

Analyzing answers to the questions in Table 1 can help management assess how inertial individual learning and creativity behaviors are. Specifically, managers respond to each question using a scale ranging from 1 (“strongly disagree”) to 5 (“strongly agree”). The higher the score, the better the conditions for individuals within teams. Mean scores are computed for each of the five categories. These means serve as inputs for a more sophisticated diagnostic tool, depicted in Figure 3, which allows for an assessment of the nature and severity of the learning and innovation problems in an agile organization.

OPEN IN VIEWER

Figure 3.

The Agile diagnostic tool.

Addressing the Challenges

The results of the diagnostic questionnaire and the diagnostic tool in Figure 3 can be discussed with those members of senior management who can trigger changes that will improve learning and innovation in an agile context. Here are four key questions that senior management should ask to contextualize the data that emerge during the process of adopting an agile approach.

What aspects of the work environment may cause to learning and ideation inertia?

This question leads to an examination of three core elements in the work environment: the position of agile stakeholders with respect to teams, the specific interests of agile stakeholders in various teams’ work, and the scope of the routines enacted by team members in their daily working lives (questions 5-10 and 11-12 in Table 1). This allows for identification of the strengths and weaknesses of the current organizational structure. To define a benchmark for comparing and diagnosing problems, managers should consider the ideal organizational structure in an agile setting as one capable of reducing vertical tensions (e.g., performance feedbacks from managers) and horizontal tensions (e.g., peer pressure) by combining efficiency and learning goals. Such a structure would

embody team and individual goals (combining efficiency and learning) that will improve both the team’s project performance and each member’s learning competence;

include a regular update on each team member’s short-term competence growth (within the reporting system implemented in scrum);

limit the frequency of stand-up meetings and reports on the realization of project tasks;

ensure that the group of agile stakeholders surrounding a team (e.g., scrum master, product owner, middle manager) includes someone knowledgeable enough to drive that team’s competence growth, and to take responsibility for the execution of their learning and ideation in each iteration cycle; and

distribute the sprint effort between operative and learning activities and create space at the end of the sprint for experimental learning through the introduction of an initiator responsible for team learning—the initiator should focus on combining and integrating knowledge by working at a higher level of abstraction than the level on which the team is working, and by interpreting knowledge with the support of the team.

If employees working in such an ideal Agile environment exhibit low learning and ideation performance, the problem probably has little to do with the nature or design of the work environment. Instead, it is most likely related to the relationships between the team and the external environment.

Figure 4 offers suggestions for the actions that should be implemented depending on the level of inertia. Figure 2 instead illustrates the links between the identified learning and ideation problems and the specific solutions we are proposing. As such, Figure 2 translates our theory of maintaining multiple inconsistent and conflicting demands between the need to be efficient and to proactively learn and ideate into concrete action steps that will enable firms implementing Agile on a large scale to balance those conflicting demands. Proposed action steps refer to the routines and processes through which large-scale organizations can not only coordinate, seize, and integrate different and conflicting efforts, but also recombine resources and assets across differentiated demands after agile methods are implemented.

OPEN IN VIEWER

Figure 4.

The Agile change tool.

Improving Learning and Innovation in the Agile Context

Finally, we highlight six solutions that can help firms that use Agile balance efficiency in product development activities and ideation performance. Each solution entails specific actions that will improve the quality of team members’ working lives as well as their individual proactive behavior in relation to learning and ideation (see Figure 2).