Agile Practices in Commercial Saas Teams

SAMINT-MILI 2036 Master’s Thesis 30 credits May 2020

Agile Practices in Commercial

SaaS Teams

A case study on the adoption of agile practices in non-software teams

Bruno Petersen

Master’s Programme in Industrial Management and Innovation Masterprogram i industriell ledning och innovation Abstract

Agile Practices in Commercial SaaS Teams

Bruno Petersen

Faculty of Science and Technology Agile software development methods have seen great success in software Visiting address: Ångströmlaboratoriet teams. Research on the topic of adopting agile methods in development teams Lägerhyddsvägen 1 is extensive. In the literature key enabling factors are identified and numerous House 4, Level 0 benefits of agile ways of working are named. Less attention has been payed to Postal address: the non-software functions in software development organizations, though. Box 536 Moreover, little is known about how well the enabling factors and benefits for 751 21 Uppsala software teams translate to other teams in the organization. The goal of this Telephone: study is to evaluate what benefits agile methods provide to non-software teams, +46 (0)18 – 471 30 03 whether the enabling factors are similar and what the challenges and drawbacks Telefax: for adopting agile methods in commercial teams are. Using the case of the +46 (0)18 – 471 30 00 Swedish Software-as -a-Service company Funnel, which introduced agile Web page: practices into their commercial teams, these questions are tackled. The study http://www.teknik.uu.se/student-en/ finds that knowledge transfer and governance are core areas that need to be engaged in during the adoption process. With decisions being made more autonomously ensuring the exchange of relevant information is crucial. The autonomy creates new demands for the governance structure, making a guiding vision and clear strategic direction crucial for individuals to remain capable of acting. An additional focus is laid on the interplay of organizational values and agile methods.

The study concludes that the introduction of agile methods to commercial teams is beneficial for the organization and helps teams solve more complex problems. It further argues that the distinction drawn between agile practices and agile enablers is misleading because of the reciprocal dependence. Finally, it is argued, that the distinction of benefits and drawbacks arising from agile methods favors agile adoption as an end in itself. The actual benefit of adopting agile practices may lie with how it makes an organization practice change, engage proactively with organizational challenges and, as a consequence, develop a greater exaptive potential.

Keywords: Agile in non-software development, agile enablers, agile methods, case study

Supervisor: Ville Svärd Subject reader: David Sköld Examiner: Åse Linné SAMINT-MILI 2036 Printed by: Uppsala Universitet

Popular Science Summary

Writing and developing a new software programs is a very difficult problem. As the problems that software can solve grow day by day, so does the difficulty of writing it. The first computer programs were written by individuals. But as computers became more powerful more things could be done with them and writing a new software program was getting so difficult, that it often required the collaboration of multiple people. In response to these difficult challenges software companies and programming teams started planning out how to develop software. They made lists of all the features they wanted to include in the new program (e.g. it has a search function, the buttons have change colors etc.). They then planned the time it would take to build the features and in what order they would need to be built. Only then did they go ahead and write the software. What became clear, though, was that this was not working very well. Customers changed their mind or did not like the features they had asked for initially. The approach of planning out the development of a piece of software from start to finish did not deliver the results expected, for both the programmers and customers. A new kind of method emerged to better deliver the expected results. Instead of planning long into the future, the software-program would be created in small pieces and every piece was double checked with the customer, to see if things were going in the right direction. This new approach is called agile software development and became hugely successful. There are now many different variations of agile, but the core values remain the same. What agile software development made possible was for teams of people to solve very difficult, complex problems, that the normal methods could not solve.

Seeing how successful these new agile methods were for software development, other people began to take notice. Many of the agile software development methods did not have anything to do with software. They were principles on how to communicate, or how to plan work in small chunks and then talk to the customer. Slowly these agile methods are being used in other areas outside of software teams and changes are made so that they fit better.

This study looks at one example where agile methods are being used in teams that do not develop software. Specifically, this study looks at the people and teams that are working in customer support, sales and marketing in a Swedish company called Funnel. This company also produces software, and the software teams in the company use agile methods. The other teams in that company are only getting started in using these methods though. Because agile ways of working are such a new thing for non-programming teams this is a very interesting case. The study asks three questions:

1. What are the things that a team or company need to have in order to make it possible for them to use agile methods? (How do the enabling factors make agile methods possible?) 2. How does this make the non-software teams (sales, marketing etc.) work better (or worse)? 3. What are the biggest difficulties do teams have when trying to us agile methods?

The study looks at one company, Funnel, in great detail. In this study 19 people from different jobs in the company were interviewed and the results were analyzed carefully.

iii

There are a couple of changes that happened at Funnel with the introduction of agile methods. Teams divided themselves up into new groups and many people are also paid in a different way. It might be surprising that pay has something to do with working agile. The reason behind it is as follows. Just as the software programming teams needed to work together to write very complicated programs, many people in the commercial department (i.e. the salespeople, marketers and customer support employees) at Funnel need to work together to solve difficult problems. It is very common, though, that salespeople for example are payed based on their individual performance. That means the more you concentrate on your own work, the better your results are, meaning you get paid better. This makes it difficult if you want to work together. At Funnel this system was changed to encourage working together. With that out of the way people formed new, small teams. Another big part of ‘agile’ working is that people can make their own decisions and do not need to wait for their boss on every small thing.

With all these teams it was suddenly very difficult to know what everyone was up to. And being able to make your own decisions it can sometimes be hard to know what to work on. What the study showed was that the teams have to find new ways of sharing information. In addition, now that people make more and bigger decisions it has become even more important for people to know the general direction everyone is moving in. This can be imagined like pulling on a rope. If everyone is pulling in different directions, nobody will move. But if everyone pulls in the same direction you move very quickly. For that to work, people in the company need to know what that shared direction is, it is often called a shared vision. There are many more things and nuances that came out of this study and that are explained in the study itself. Overall, using agile methods in the commercial teams at Funnel was successful in improving how people work together.

Answering the first of the three questions on the enabling factors, the result was that the idea of specific conditions or enabling factors that a company needs to have to adopt agile methods is misleading. For a company or a team, what matters is that they improve in solving difficult problems. Agile methods are just as much a part of that as the ‘enabling factors’ are. The distinction made in the research literature does not add much to the practical work of the teams.

The second question on the advantages and drawbacks of agile methods shows that there are definite advantages to starting to work agile. The plus of working with agile methods, though, may not actually come from the new way of working. Instead, it seems, that part of the benefit for the teams comes from them thinking about how they work and want to work. It is almost like the company is doing exercise in how to change. And when the world changes they are better prepared to deal with changes, just like someone who works out regularly is better prepared to go for a run when they suddenly need to.

The last question on the difficulties shows that many new problems still come up. There needs to be a shared vision for example. Another difficulty is that it is very difficult to set expectations with people. How do people know what to do, when everything changes all the time? And how do you hold someone accountable if you can’t agree on what they are expected to do in the first place. These are questions that future studies must find an answer to.

Table of Contents 1. Introduction ...... 1 1.1. Theoretical motivation ...... 1 1.2. Aim and purpose of the research ...... 2 1.3. Research questions ...... 2 2. Theory ...... 4 2.1. Agile Values and Principles ...... 5 2.2. Agile Frameworks and Practices ...... 5 2.2.1. Backlogs for both Product and Sprint ...... 6 2.2.2. Change Management...... 7 2.2.3. Continuous planning ...... 9 2.2.4. Cross-functional and self-organizing teams ...... 9 2.2.5. Customer involvement ...... 10 2.2.6. Daily Stand-up / Daily Scrum ...... 10 2.2.7. Face-to-face Communication & Media Richness ...... 11 2.2.8. Iterative and incremental development ...... 12 2.2.9. Kanban Boards ...... 12 2.2.10. Pair programming ...... 13 2.2.11. Requirements prioritization ...... 13 2.2.12. Retrospectives ...... 14 2.2.13. Specification by example & User Stories ...... 14 2.2.14. Timeboxing ...... 14 2.2.15. Bringing practices together – reciprocal reinforcement ...... 15 2.3. Agile Enablers and success factors ...... 16 2.4. Analytical Frameworks ...... 17 2.4.1. Agile Adoption and Improvement Model ...... 17 2.4.2. The Competing Values Framework ...... 18 3. Methodology ...... 20 3.1. Study design ...... 20 3.2. Epistemology and ontology ...... 21 3.3. Methods used for empirical data collection...... 23 3.4. Relating methodology and epistemological position ...... 24 3.5. Choice of methods ...... 25 3.6. Analysis ...... 26 3.7. Limitations ...... 26 3.7.1. Validity, Credibility, Transferability and Dependability...... 27 3.7.2. Bias ...... 27 3.8. Ethical considerations ...... 28 4. Empirical Material and Analysis ...... 30 4.1. About Funnel.io ...... 30 4.2. Agile at Funnel and in Non-Software teams – A Brief History ...... 31 4.3. Knowledge ...... 33

4.3.1. Relevant knowledge and silos ...... 34 4.3.2. Bridging the gap - Cross-functional interaction ...... 34 4.4. Governance ...... 37 4.4.1. Reasons for being Agile from a governance perspective ...... 37 4.4.2. Giving up Control for Organizational Leaders ...... 38 4.4.3. Scoping & Working Towards Strategic Objectives ...... 38 4.4.4. Creating Accountability ...... 40 4.4.5. Setting Clear Expectations and Defining Ownership in a Changing Environment.. 41 4.4.6. Decision Fatigue and Uncertainty ...... 43 4.5. Methods core...... 44 4.6. Organizational Values and Critical Enablers ...... 44 4.6.1. Hierarchies and Differing Competitive Values ...... 44 4.6.2. Explicit and Implicit Organizational Culture ...... 47 4.6.3. Moving too fast – Agile Fatigue ...... 48 4.7. Interactions - Knowledge, Governance, Culture & Enablers ...... 49 5. Discussion and Conclusion ...... 50 5.1. Enabling Agile Adoption – An Illusory Category ...... 50 5.2. Constant Collaboration – Advantages of Agile Teams...... 51 5.3. Finding a North Star – Challenges of Agile Adoption ...... 52 5.4. COVID 19: Remote Work, Unexpected Pivots and Exaptation ...... 53 5.5. Connecting the Dots – Conclusions from the Research ...... 54 5.6. Implications for Future Research ...... 55 5.7. Ethical and societal implications ...... 56 Appendix ...... 63

1. Introduction Organizations developing software increasingly employ methods of work referred to as agile software development. These methods focus on delivery speed, customer interaction and flexibility among other things. The prominence of the software and technology industry broadly and the widespread success of agile software development within these companies specifically have led to widespread adoption of agile practices. The success software teams have with this new way of organizing has led to an increasing push in using these methods in non-software teams. This study explores how agile practices are adopted and what benefits and challenges arise for non-software teams from doing so. By looking at the commercial organization of a Swedish software-as-a-service company, the questions of the necessary enabling factors for such a transition, its benefits and its challenges will be explored.

1.1. Theoretical motivation The adoption and associated challenges of agile practices and methods in software development have been widely studied. The majority of this has taken the form of case studies as the systematic literature reviews by Dikert and Inayat show (Dikert et al., 2016; Inayat et al., 2015). In this research, different success factor categories are identified to be “management support, choosing and customizing the agile model, training and coaching, and mindset and alignment.” (Dikert et al., 2016). The customization of agile methods is explored in the field of agile methods tailoring (Conboy and Fitzgerald, 2010; Fitzgerald et al., 2000; Kurapati et al., 2012) where the adoption and adaptation by way of method engineering and other practices are discussed. As part of that research, frameworks for the evaluation of adoption and strategic value were developed such as the SAAP (Strategic Analysis for Agile Practices) framework, the Sidky Agile Management Index (SAMI) (Esfahani et al., 2011; Sidky et al., 2007) or the Agile Adoption and Improvement Model (AAMI)(Qumer and Henderson-Sellers, 2008).

In their systematic review Dikert et al. identify 35 challenges and 29 success factors for large scale agile transformation, large scale being defined as “software development organizations with 50 or more people or at least six teams.”(Dikert et al., 2016). One such challenge is integrating non-software functions into the transformation since the software development function needs to interact with other parts of the organization. Within this category Dikert et al. define further sub-challenges: “Other functions being unwilling to change, adjusting to the incremental delivery pace, adjusting product launch and the rewarding[compensation] model not being team-work centric”. Other functions in this context are taken to mean marketing, sales, customer service, infrastructure, operations, user experience and design, documentation, legal, security and finance (Dikert et al., 2016).

There are clear challenges to the adoption of agile practices that lie outside the part of the organization dealing with software development. Yet the research on the advantages of agile practices (Dybå and Dingsøyr, 2008), the adoption of agile methods and their tailoring revolves almost exclusively around software development. Where research has stepped outside software development functions it has done so entirely and dealt with agile project management in different fields like construction or engineering projects (Conforto et al., 2014; Owen et al., 2006). What is missing is a closer look at what lies in between those two cases. How agile practices for non-software functions within a software organization affect the teams themselves, by providing the same advantages seen in software development, and the organization as a

1 whole, by mitigating the challenges that arise from misalignment of the development and non- software functions in the organization.

An empirical study of this kind can make a meaningful contribution to the field of industrial engineering in three ways: Firstly, by evaluating the use of agile methods as a viable form of organizing and working in non-software functions. Secondly, by raising the possibility of resolving challenges to agile adoption within development functions by implementing agile practices outside development. Thirdly, by outlining what unique challenges non-software functions face when adopting agile practices.

1.2. Aim and purpose of the research

The aim of this project is threefold: First, to evaluate the viability of utilizing agile methods for non-software teams in a software development context. Delineating what fundamental pre- requisites are necessary for the adoption of agile practices and where these pre-requisites are or are not met by other business functions. This then can lead to considerations on where agile practices meet their inherent limitations.

Second, to test whether agile practices deliver the same or similar advantages to teams in non- software functions as they do to teams in development functions. Such as: “improving customer collaboration, work processes for handling defects, learning, thinking ahead for management, focusing on current work, and estimation” among other things (Dybå and Dingsøyr, 2008). This also includes identifying second-order consequences from adopting agile practices in non- software functions. To give some examples of what these are: Improved communication and collaboration between development and non-software functions, more transparency and understanding about working methods throughout the organization, development of transferrable skills and increased cross-departmental career development, greater cultural cohesion and sense of purpose through following a shared approach, overwhelmed leadership unable to cope with new structures, diffuse accountability or, the entrenchment of the status quo in response to change efforts.

Third, evaluating the challenges for non-software functions when adopting agile methods given the different environment these organizational functions operate in.

1.3. Research questions

To fulfil the objective of this study these four research questions have been formulated:

RQ1. How do enabling factors affect the successful adoption of agile practices in non-software functions of a software organization?

RQ2. How do direct and indirect advantages and disadvantages arise from the adoption of agile practices in non-software functions of a software organization for the function (team/department/unit) adopting the practice and the organization as a whole?

RQ3. What challenges do non-software functions face when adopting agile ways of working?

1.4. Addressing the Research Questions

The research questions are answered by examining the case of Funnel AB and contrasting the case of Funnels commercial organization with an adoption framework and literature on enabling factors for agile methods. Interviewing people from both parts of the organization, the development and non-software functions respectively, made evaluating the impact on the wider organization possible. The analysis of the empirical material provided advantages and challenges for the non-software functions. In connection with the framework, these findings are unified into a larger picture, providing a more coherent view of the situation at Funnel.

The limitation of this approach is first, that the timeframe of the adoption process is longer than the period of study. At the time of writing the adoption process is still ongoing and challenges brought up in this study are being addressed. A complete picture of the advantages and disadvantages can therefore not be drawn. Some advantages or drawbacks may only manifest over a longer time. Second, the empirical material provided through the interviews and, to a lesser extent, observations limit the conclusions that can be drawn. Certain issues may not be mentioned or be overlooked by the interview subjects and therefore not appear in the empirical material. Thirdly, by focusing on a single instead of multiple cases the thesis cannot compare companies going through a similar process. The primary limitations of this study are the limited time, the accessible empirical material and the scope in coverage created by the choice of method.

2. Theory

The theory section is divided into three parts. First section 2.1. introduces general agile values and principles. The second section 2.2. and 2.3. introduces a set of practices that are influenced by the values and principles. The practices introduced in this section correspond to those adopted in the organization being studied. They are addressed to give substance to the building blocks that the analytical frameworks later relate to one another. Additionally, this section (2.3.) covers the idea of enabling factors, that is prominently addressed in the literature and is the subject of RQ1. The third section, 2.4. presents the analytical frameworks that guide the analysis. These frameworks form the conceptual lenses through which the analysis will be viewed. In this, they are distinct from the first two sections of theory.

To outline how agile methods and foundational principles can be understood relating to one another a hierarchy can be established between them. This categorization (see figure 1) aims to provide explanatory clarity and not establish a strict order or relationship between the aspects of agile ways of working. At the foundation of the adoption of agile lay the underlying values. These values inform a set of principles upon which different frameworks are built. The different frameworks include practices and methods, these are the concrete actions and activities taken by individuals and teams. Values and principles are more abstract and less practical than frameworks and practices which are actionable and more concrete. This is also reflected in their numbers: there are a small number of core values but several principles and many more frameworks with innumerable practices.

Figure 1 - Relationship between agile values, frameworks and practices. Agile values do not necessitate certain frameworks or practices. But frameworks and practices require the overarching values and principles.

In conjunction, these different levels reinforce each other. An agile practice by itself provides little benefit. It is the interplay of the differences between them that make practices successful. Frameworks are sets of practices that have proven themselves to work well together and so provide a general latticework for adoption. Frameworks and practices can nevertheless be ambiguous. The principles and values help resolve some of that ambiguity by providing an abstract notion of what a framework or practice is aiming for.

In the following section agile values and principles will be briefly explained, followed by some of the most common frameworks and the practices. In each category the objects are not mutually exclusive, there is great overlap between principles, frameworks and practices. Besides the theoretical concepts underlying agile software development, this section will explore common challenges to agile adoption and enabling factors for said adoption that have been identified in the academic literature.

2.1. Agile Values and Principles

Agile methods encompass a variety of different methodologies and organizational structures that have been shown by Petersen & Wohlin to provide tangible advantages, especially at smaller companies (Petersen and Wohlin, 2009).

At the root of many agile practices stands the agile manifesto which states:

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

Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation 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.” (Beck et al., 2001)

Along with the values outlined in the manifesto, 12 principles were published for further clarification on these values.

2.2. Agile Frameworks and Practices

Even before the publication of the agile manifesto different ‘agile’ methods existed. Since then an increasing variety of different frameworks and practices for agile software development have been developed, partly inspired by or based on the agile manifesto’s values and principles. These include Adaptive software development (ASD), Agile modelling, Agile Unified Process (AUP), Disciplined Agile Delivery, Dynamic Systems Development Method (DSDM), Extreme Programming (XP), Feature-driven Development (FDD), Lean Software Development, Lean Startup, Kanban, Rapid Application Development (RAD), Scrum, Scrumban and even methods for agile adoption ‘at scale’ such as the Scaled Agile Framework (SAFe) or Large Scale Scrum (LeSS) (Abrahamsson et al., 2003; Highsmith, 2000; Ladas, 2008; Leffingwell, 2007; Martin, 1991; Palmer and Felsing, 2002; Poppendieck and Poppendieck, 2010; Schwaber, 2004; Stephens and Rosenberg, 2003). These frameworks and methodologies have in common that they are first and foremost aimed at software development which is where they originated. They include practices that are primarily applicable in software development such as Acceptance test- driven development (ATDD), Agile testing, Behavior-driven development (BDD), Continuous Integration (CI), Domain-driven design (DDD), Low-code development platforms, Refactoring and Test-driven development (TDD) (Beck, 2000; Booch, 1991; Evans, 2004; Martin, 2002; Pugh, 2011; Smart, 2015).

Other practices, however, like the following adapted from a systematic review by Inayat et al. are not as strictly tied to software development (Inayat et al., 2015):

• Backlogs for both Product and Sprint • Change Management • Continuous planning • Cross-functional and self-organizing teams • Customer involvement • Daily Stand-up / Daily Scrum • Face-to-face communication • Iterative and incremental development (IID) • Kanban Boards • Pair programming • Requirements prioritization • Retrospectives • Specification by example / User Stories • Timeboxing

This list does not claim to be exhaustive but captures central practices of what is considered ‘agile’, instead, concepts and practices were listed that were encountered at Funnel and that played a role throughout the interviews. The underlying logic of each will be explained briefly in the following section.

2.2.1. Backlogs for both Product and Sprint

The product and sprint backlogs are terms used in the Scrum framework. In Scrum, the product backlog is defined as “[…] an ordered list of everything that is known to be needed in the product. It is the single source of requirements for any changes to be made to the product.” (Schwaber and Sutherland, 2017). The sprint backlog is a subset of items in the product backlog selected to be worked on for a fixed period called the sprint. In the Scrum framework, it is the product owner who is responsible for the content and order of the product backlog, but this responsibility can be taken on by a team as well. Crucially, the items in the backlog change continuously and new items are added, dropped or changed. As Schwaber and Sutherland, the creators of Scrum, put it: “A Product Backlog is never complete. The earliest development of it lays out the initially known and best-understood requirements. The Product Backlog evolves as the product and the environment in which it will be used evolves. The Product Backlog is dynamic; it constantly changes to identify what the product needs to be appropriate, competitive, and useful.” (Schwaber and Sutherland, 2017). To understand whether a given item in the backlog is ‘appropriate, competitive and useful, close collaboration with customers is needed. This is where the practice of customer involvement (See 2.2.5.) becomes relevant. Even with customer collaboration, decisions on what items in the Backlog to work on must be made, for this, different requirements must be prioritized using a variety of practices and tools further explained under 2.2.11. – Requirements Prioritization. Backlogs can also be used outside the Scrum framework and the idea of an ordered list of needs, requests or work items is, for example, being applied in conjunction with Kanban boards (see 2.2.9.), sometimes referred to as Scrumban. In these systems, the backlog serves as an inventory from which new work items are ‘pulled’ to be worked on (Ladas, 2008).

2.2.2. Change Management

Adapting to change is a central value of the agile manifesto which states “We value responding to change over following a plan”(Beck et al., 2001). Change management covers a wide area of approaches to transform an organization. These approaches have their roots outside software development. Jurgen Appelo defines change management as an “approach for transforming organizations by way of transitioning individuals, teams and even whole businesses in a specific future direction. Perhaps even a better term could even be transformational management.” (Appelo, 2012).

Change Management Processes: Depending on the circumstances, different approaches are put forward. In Leading Change, John P. Kotter gives an eight-step process for transformation efforts starting with (1) establishing a sense of urgency, (2) creating a guiding coalition, (3) developing a vision and strategy, (4) communicating the change vision, (5) empowering employees for broad-based action, (6) generating short-term wins, (7) sustaining acceleration by consolidating gains and producing more change and (8) anchoring new approaches in the culture (Kotter, 2012). Jeff Hiatt’s ADKAR model is similar to Kotter’s eight steps. ADKAR is an acronym for (A) awareness of the need for change, (D) desire to support and participate in the transformation, (K) knowledge of how to change, (A) the ability to implement required skills and behaviors and (R) reinforcement to sustain the change (Hiatt, 2006). Whereas Kotter and Hiatt imply a start and end of the change process with intermittent periods of stability, the PDCA-cycle is more focused on continuous improvement. PDCA, however, tries to maintain change through the introduction of standards. The Plan-Do-Check-Act (PDCA)-Cycle, often called the Deming Cycle after W. Edwards Deming (Koiesar, 1994) begins with planning a change or test aimed at improvement (P). Then that change is carried out – preferably – a small scale (D), the results are then studied and what went well or wrong is learned (C). Lastly, the change is adopted or relinquished (A) and the process repeated (Moen and Norman, 2006). This approach is similar to the iterative and incremental methods at 2.2.8. that it precedes.

Adoption of Change: As change takes place throughout an organization Rogers’ theory of innovation diffusion is used by Appelo and others to explain the adoption of change (Appelo, 2012, 2011). As with other innovations, change starts with initiators and innovators followed by the early adopters, early majority and then the late majority and laggards (Rogers, 1995). This process of adoption can fail, particularly at the so-called ‘chasm’, the gap between early adopters and the early majority. Agile practices aim to deliver value to the customer fast and continuously, changing requirements in the backlog are essential to that. Changing customer demands require that the processes built to fulfil these demands vary too. The consequence is that the organization needs to change fundamentally. This is why change management is an integral part of agile practices. It allows organizations themselves to adapt.

Complex change & the adjacent possible: The processes for managing change give the impression, that successful change is a matter of execution and avoiding pitfalls. There are, however, some changes that cannot take place in a single step or at all, as Dave Snowden argues. According to Snowden, three stages are necessary to change a system like an organization. First, mapping “the current dispositional state of the system” identifying “the attractors at play, and their stability”(Snowden, 2016). Attractors are clusters or behavior patterns that form from the interactions between the entities in the system. Second, having mapped the state of the system, we can now identify desirable patterns of behavior that are adjacent to the current state of

7 behavior. Snowden draws on Kauffman’s concept of the adjacent possible. The adjacent possible is the reachable ‘adjacent’ state of the system in relation to its current ‘actual’ position (Kauffman, 2003). Identifying the ‘adjacent possible’ is desirable because larger shifts are harder or impossible or bring with them unintended consequences. The present, therefore, brings with it an evolutionary potential, rather than endless possibilities (Snowden, 2015) that can be reached through incremental change. Lastly, Snowden acknowledges, that some systems might not have an adjacent possible, or that the energy required to escape the current attractor is too great. In this situation, the recommended course of action is disrupting the attractor to allow the natural emergence of a new adjacent possible. Figure 2 illustrates a system with four visible patterns of attractors. Instead of transitioning from the two present (actual) states to the goal state, a transition to the centrally located adjacent possible can take place.

Two give an example: looking at a sales team on two dimensions, compliance with the process and job performance, we can identify four clusters of people. 1) Low compliance and low performance, 2) low compliance and high performance, 3) medium compliance and medium performance and lastly, 4) high compliance and high performance. Ideally, all salespeople would have high process compliance and high performance. That is an unrealistic expectation, though. The adjacent possible for both low compliance groups are joining their peers in the medium compliance medium performance ‘pattern’. This intermediate position is the adjacent possible for both of the groups.

Figure 2 - Two-dimensional illustration of the adjacent possible in relation the current actual state and the desired goal. The axes represent the relevant dimensions for change. The system is spread out and parts of the system are already at the desired state. Adapted from David Snowden (Snowden, 2016)

2.2.3. Continuous planning

As with change management, continuous planning is a manifestation of the value agile ways of working place on welcoming changing requirements. As Inayat et al. explain: “Continuous planning is a routine task for agile teams (Liu Jun et al., 2010). The team never sticks to fixed plans and adapts to the upcoming changes from customers as the project progresses. This flexibility facilitates changing requirements in later stages of projects.” (Inayat et al., 2015). Continuous planning is made possible by work taking place in small increments rather than big releases. The priorities are then revisited at regular intervals such as the end of a sprint or time box – see 2.2.15. Time Boxing. Using different prioritization practices (2.2.11.), sometimes by involving the customer (2.2.5.), a new priority is selected from the backlog (2.2.1.). The other agile practices enable continuous palling and helps to scope the work to what is valuable to the customer. Iterative working practices (2.2.8.) mean that a problem can be revisited at a later time if the need for improvement arises.

2.2.4. Cross-functional and self-organizing teams

In continuously fast-changing environments, completely new problems arise for which good practices do not yet exist. In such an environment these problems nonetheless need to be solved quickly, for the organization to succeed. This means that individuals cannot solve an increasing number of issues by themselves. As Dougherty and Tolboom write in the Handbook of Organizational Creativity: “Managers are increasingly faced with the need to use cross- functional teams of relative strangers with a temporary membership to solve complex novel problems under time pressure. This requires knowledge integration through transformation. Despite the wide diffusion of best practices for encouraging cross-functional team performance, organizations continue to struggle” (Dougherty and Tolboom, 2008; Majchrzak et al., 2012). In a complex domain, the problems are solved with emergent practice by probing the system, sensing the response and then responding either by amplifying or dampening a behavior (Snowden and Boone, 2007). This stands in contrast to best- or good-practice where a solution can be found by sensing, analyzing or categorizing and then responding. In both these instances, one or multiple optimal solutions exist and can be found. In a situation with evidence for conflicting hypotheses that cannot be resolved in the available time a situation is complex and calls for emergent practice. It is this emergent practice that cross-functional teams excel at, and because organizations increasingly find themselves facing complex problems, cross-functional teams have become common.

Cross-functional teams are comprised of individuals from different backgrounds, departments, functional disciplines or with different skill sets that have joined a team to contribute to a joint problem. Capitalizing on their composition is what makes cross-functional teams successful (Edmondson and Nembhard, 2009).

The function of the team is to share knowledge between team members, but more than that, to solve a problem that no individual or functional team would be able to solve by themselves. Majchrzak et al. suggest that transcending knowledge differences rather than traversing them is a crucial characteristic of successful cross-functional teams (Majchrzak et al., 2012). Teams were successful at ‘transcending’ knowledge differences when they “avoided interpersonal conflict, fostered the rapid cocreation of intermediate scaffolds, encouraged continued creative

9 engagement and flexibility to repeatedly modify solution ideas, and fostered personal responsibility for translating personal knowledge to collective knowledge.” (Majchrzak et al., 2012). It is worth highlighting the parallels to agile practices in rapid cocreation, repeated modification of intermediate solutions (prototypes) and personal responsibility contribute to the success of the team.

Cross-functional teams are good at complex problem solving, but in situations that require expert knowledge and analysis, a different approach is preferable. Calling on experts in the field is a more promising approach for solving complicated situations and in a chaotic environment establishing some form of order by taking quick action helps to stabilize the system (Snowden and Boone, 2007).

2.2.5. Customer involvement

Customer collaboration over contract negotiation is one of the four values of the agile manifesto. Involving and collaborating with the customer is seen as the best way to achieve product/market- fit and deliver value to the customer. Models like the Business Model Canvas (Osterwalder et al., 2010), Value proposition design (Osterwalder et al., 2014) and the Lean Startup Cycle all aim to facilitate this process. The idea is to talk to “potential users, purchasers, and partners for feedback on all elements of the business model, including product features, pricing, distribution channels, and affordable customer acquisition strategies” (Blank, 2013). The ideas from the lean start-up and value proposition design are preceded by earlier, similar ideas. Previous definitions of customer involvement define it as “those processes, deeds and interactions where a service provider collaborates with current (or potential) customers at the program or project level of service development, to anticipate customers’ latent needs and develop new services accordingly.” (Matthing et al., 2004).

In addition to delivering a product or service in line with the customers most recent specifications, customer involvement has another advantage: increasing the speed of the development process and improving the technical quality of the service or product. According to Carbonell et al. “Product and marketing managers will do well to appreciate that customer involvement in new service development will lead to increased market outcomes, but the relationship is indirect. Improved market outcomes are achieved through innovation speed and technical quality.” (Carbonell et al., 2009).

2.2.6. Daily Stand-up / Daily Scrum

The daily stand-up or daily scrum is a daily recurring meeting by a team to get a status update on everyone’s work. If work is being visualized on, for instance, a Kanban board, the stand-up tends to take place at the board. The name comes from the fact that the meeting is held standing, to keep it short. The central questions individuals tend to answer during the meeting are some variation on ‘What did I do yesterday?’, ‘What will I do today?’ and most importantly ‘What obstacles or roadblocks are impeding my progress?’. The stand-ups help synchronize the teams, and help them understand their respective goals, coordinate joint efforts the team is working on, share improvements and problems so that others benefit from them or help out. Through regular engagement this meeting makes individuals identify with the team (Yip, 2016). Stand-ups lower the bar for communicating problems or asking for help, thereby allowing potential issues to be

10 caught and resolved early. Most agile frameworks feature some variation of the daily stand-up. The ubiquity and the daily recurrence, though, can make the meeting frustrating to its participants. Several things can indicate that stand-ups are going array, according to Jason Yip. For example, when the stand-up is being used to ‘report to the leader’, used to socialize, obstacles are withheld or not removed after being brought up. Another example is participants either forgetting what they worked on or providing too much detail and ‘telling a story’(Yip, 2016). The incremental and iterative nature of the work in an agile organization makes the challenges of knowing the goal the team is striving for and coordinating their efforts even more pressing than under ‘traditional’ ways of working. The daily stand-up, when executed well, is a practical way of meeting these challenges.

2.2.7. Face-to-face Communication & Media Richness

The first value on the agile manifesto is to value “individuals and interactions over processes and tools” this is further expanded upon in the principles stating: “The most efficient and effective method of conveying information to and within a (development) team is face-to-face conversation.”(Beck et al., 2001). While face-to-face communication is a value and a principle, it profoundly impacts agile practices. Agile teams aim to be collocated, meaning working in the same space, and practices such as Pair Programming (2.2.10) have a strong component of Face- to-Face communication. The stand-up meeting is another example of face-to-face communication within the team. The reason face-to-face communication is preferred goes back to Trevino, Lengel and Daft’s concept of media richness. The concept posits that the media richness continuously lessens (in descending order) from fact-to-face, video conferencing, telephones, emails, wikis and web-based tools to bulletins, documents and memos (Trevino et al., 1987).

Regardless of what medium is chosen, Trevino et al. suggest that the deliberate choice of medium is a distinguishing factor of successful communication “The appropriate media choice may make common sense only for high-performing managers. Low-performing managers select media for communications without considering the requirement of the message.” (Trevino et al., 1987). The number of low richness communication media has increased from 1987 to 2020, and the richness of these media has improved. Yet, face-to-face communication, and video conferencing as an alternative, nevertheless remain the highest richness media.

Media richness – the answer to complex & un-analyzable tasks: David Snowden’s Cynefin Framework distinguishes between simple, complicated, complex and chaotic domains. In the complex domain, in contrast to the complicated or simple domain, clear cause and effect relationships do not exist and therefore cannot be known. It is here that high richness communication is especially valuable. Simple and complicated tasks can be called analyzable as they are tasks “for which predetermined responses to potential problems, and well-known procedures, are available and useful because outcomes are well-understood” (Rice, 1992). Un- analyzable tasks have no well understood procedures and outcomes. “For innovation-driven horizontal networks engaged in predominantly un-analyzable tasks, the use of high richness media such as face-to-face meetings, video conferencing and telephones are advantageous. Where geographical proximity or location is an issue, the use of telephones and video conferencing channels is preferred for such tasks.” (Oke and Idiagbon-Oke, 2010). The focus on individuals and interactions and face-to-face communication in the agile manifesto is another manifestation of dealing with a complex environment.

2.2.8. Iterative and incremental development

Whether for building a product, writing code, managing change or involving the customer iterative and incremental development is a crucial part of solving these challenges. Both the lean startup cycle build, measure, learn (Ries, 2011) and PDCA (see 2.2.2. – Change Management) have iterative and incremental components. Incremental and iterative, while related, are distinct ideas though, as Alistair Cockburn points out: “The word increment fundamentally means add onto. The word iterate fundamentally means re-do. Unfortunately, iterative development has come to mean either incremental or iterative, indiscriminately. That was an unfortunate turn since each serves a different purpose and needs to be managed differently. Incremental development gives opportunities to improve the development process, as well as adjust the requirements to the changing world. Iterative development helps you improve the product quality. Yes, it is rework, and yes, you probably need to do some rework to make your product shine. The development process, feature set, and product quality all need constant improvement. Use an incremental strategy, with reflection, to improve the first two. Use an iterative strategy, with reflection, to improve the third” (Cockburn, 2008). Cockburn’s emphasis on reflection for incremental and iterative strategies will be expanded upon in 2.2.12 – Retrospectives.

The advantage of using an incremental strategy, especially when the customer is closely involved, is that mistakes or development in the wrong direction can be discovered and corrected early. Incremental work has two major advantages. Firstly, since incremental changes are rolled out regularly, discovering mistakes is easier because one change is made at a time instead of multiple changes with confounding variables being made all at once. This, in turn, leads to the second advantage. Teams and individuals learn from their mistakes. Working incrementally is helpful because the reason for failure is more readily apparent (i.e. the last addition or change caused the problem), which helps build more robust knowledge. It reduces the time between an action and the consequence. Learning from failure is more difficult when feedback is delayed (Maddox and Ing, 2005). The regular troubleshooting and problem solving that follow from incremental working makes people learn from their mistakes and gives more opportunities for troubleshooting problems

For an incremental strategy to truly work, the organization needs to allow and not punish failure. The enabling factors that need to be in place, chief among them psychological safety, will be discussed in 2.3. Incremental working is enabled by the fact that later iteration can improve quality, which is why these concepts work so well together. The last advantage of incremental and iterative strategies is that they allow for constant delivery of value to the customer. So instead of waiting for a big release, a customers’ problem will be progressively solved.

2.2.9. Kanban Boards

Kanban is a system from lean manufacturing to increase manufacturing efficiency. It originated at Toyota but has been adopted in other industries. A Kanban board is one way of using a Kanban system. In this form, it “is a physical or digital project management tool designed to help visualize work, limit work-in-progress, and maximize efficiency (or flow). Kanban boards use cards, columns, and continuous improvement to help technology and service teams commit to the right amount of work” (Rehkopf, 2020). A crucial part of a Kanban system is that is functions as a pull system. That means new tasks are only taken on when a request is made, and capacity

12 for them is available. This stands in contrast to a push system where demand and output are forecast and then scheduled. Different than in manufacturing, where work-in-progress is visible, in an organization doing knowledge work, clear limits on work in progress have to be set. One major reason that throughput wains when people work on too many tasks at once can be explained by the associated switching costs: “responses are substantially slower and, usually, more error-prone immediately after a task switch” (Monsell, 2003).

2.2.10. Pair programming

Pair programming is a practice coming out of the eXtreme Programming (XP) framework. As the name implies, it involves pairs of people working on the same problem, where one person is ‘in the driver’s seat’ while the other is continuously reviewing their work. These roles switch repeatedly. The benefit that pair programming provides can lead to better design quality, fewer defects, improved learning, communication and team-building and higher satisfaction with the solution (Beck, 2000). These advantages arise, particularly in an environment with vague and constantly changing requirements or when complex problems are being solved. Here the pair- programming approach results in faster completion time at the cost of higher effort, a meta- analysis found (Hannay et al., 2009). It is worth noting that the same meta-analysis found “signs of publication bias among published studies on pair programming.”(Hannay et al., 2009). Because pair programming is focused on delivering working software, whether the advantages of joint problem solving listed above translate into non-software teams is unclear.

2.2.11. Requirements prioritization

With a long list of tasks in the backlog and continuously changing requirements that come through customer involvement finding an effective way to prioritize and re-prioritize is essential to deliver value to the customer. Many organizations develop or use their own approaches and a large variety of practices and techniques are used today. Example techniques used in agile organizations include: Round-the-group prioritization, Ping Pong Balls, $100 allocation cumulative voting, Multi-voting system, MoSCoW, Pair-wise analysis, Weighted criteria analysis, Analytic Hierarchy Process (AHP), Dot voting, Binary Search Tree, Ranking based on product definition, XP: Planning Game/ Poker, Quality function deployment (QFD), Wieger ́s matrix approach, Mathematical programming techniques, Technique of bucketing requirements, Kano Model, Eclipse Process Framework, Relative weighting, Larman, Theme screening / scoring (Bakalova et al., 2011).

What is helpful in connection with these practices is a clear understanding of what the organization is trying to achieve. Because setting a priority entails deciding what tasks are most urgent and impactful that begs to answer the question ‘impactful on what?’. Here organizational strategy plays a role, but customer involvement again helps identify what matters to the customer and that in turn helps clarify priorities for the organization.

2.2.12. Retrospectives

Organizations in knowledge-intensive industries can suffer from ‘organizational amnesia’ and often face the risk of knowledge loss at the end of a project (Schindler and Eppler, 2003). Especially when a cross-functional team is formed and abandoned after completing their tasks. Incremental and iterative strategies, as they are found in agile, offer frequent learning opportunities but equally frequent chances of missing these opportunities. Retrospectives are what bridge the gap between theory and practice and allow teams to capitalize on these opportunities. By systematically integrating time for reflection into the processes, they help alleviate the problem of organizational amnesia. The idea of continuous and repeating reflection is part of the PDCA-cycle (see 3.2.2. Change Management) where the Check-step (C) represents the inbuilt reflection. In the lean start-up cycle (iterate-measure-learn), it is the learning step. Retrospectives are “a special meeting where the team gathers after completing an increment of work to inspect and adapt their methods and teamwork. Retrospectives enable whole-team learning, act as catalysts for change, and generate action.” (Derby and Larsen, 2006). In their seminal book on the topic of agile retrospectives Diana Larsen and Esther Derby describe a five-step structure that underlies most retrospectives, it consists of: (1) Setting the stage on what it is that will be discussed, (2) gathering data on the topic which can happen before or during the retrospective, (3) generating insights from the data, (4) deciding on actions and assigning follow up tasks and then (5) closing the retrospective (Derby and Larsen, 2006). The execution of these steps varies, and there is a multitude of exercises that Derby, Larsen and others suggest making them effective.

2.2.13. Specification by example & User Stories

User stories are an instance of specification by example. “A user story describes functionality that will be valuable to either a user or purchaser of a system or software. User stories are composed of three aspects: a written description of the story used for planning and as a reminder; conversations about the story that serve to flesh out the details of the story; tests that convey and document details and that can be used to determine when a story is complete. Rachel Davies (2001) has said that cards "represent customer requirements rather than document them." While the card contains the text of the story, the details are worked out in the Conversation and recorded in the Confirmation.” (Cohn, 2004). The advantage specification by example offers is that it makes customer or user needs more accessible and readily understandable to other members of the organization. This invites feedback and collaboration across teams, which makes cross-functional teaming efforts easier. Another advantage is the clarity they provide on the job that needs to be solved, which makes it possible to apply different approaches to solving a problem rather than following one specified approach. Specification by example offers the flexibility that collaboration requires.

2.2.14. Timeboxing

Timeboxing is an approach to manage tasks and time that follows from the assumption underlying agile ways of working. Given that requirements change constantly, and the aim of continuously delivering value, time cannot be allocated to fit the task. Instead of allocating time depending on the size of the tasks or activity, the size of the activity is scoped to the time available for its completion. In software development, this approach is used to scope the

14 functionality being developed during an iteration, for instance. “By dividing the time box into stages, pipelining concepts are employed to have multiple time boxes executing concurrently, leading to a reduction in the delivery time for product releases. In timeboxing, as in other iterative development approaches, some software is developed and a working system is delivered after each iteration.” (Jalote et al., 2004). The idea of timeboxes can be applied at different scales, setting larger time boxes for overarching goals and smaller time boxes for daily activities. The crucial point is that time boxes set a cadence to step back, reflect and retrospect and re-prioritize based on new information instead and scoping activities to fit within the allocated timeframe realistically.

2.2.15. Bringing practices together – reciprocal reinforcement

What has potentially become apparent throughout the list above of selected agile practices is their interdependence and the way in which practice benefits from one another. To paint a more holistic picture here is how some of the components interact: Customers’ demands are constantly changing, and this change is tracked through close customer involvement. These needs are specified using examples, making them more accessible and understandable to the entire organization, and captured in a backlog. Since the number of items in the backlog is too large to be solved completely, prioritization techniques help identify the most impactful items. Their progress is tracked and visualized using a Kanban board. Daily stand-ups help identify problems early and again aid the communication within the team. The work-in-progress limit is applied, ensuring that people can focus on their work. While people are working on a problem, they collaborate with the people from other teams, working cross-functionally. To avoid misunderstandings as much as possible and convey necessary information, face-to-face communication is used as the preferred method of communication. On some tasks working jointly on the same problem (pair-programming) helps improve quality and increase knowledge sharing. To ensure that the most impactful issues are being solved and work is completed, time boxes set a limit to the time a task can take on. At the end of a unit of work, a retrospective is then used to learn from the work that has been done and ensure the team works well together. Early failure is encouraged, so long as it leads to faster learning, and problems are solved incrementally and later iteration on the same problem improves quality. As larger shifts in the environment of the organization take place, this iterative approach is applied to the organization as a whole.

From another perspective, the question could be asked, ‘what if we refrain from retrospectives, daily stand-ups or communicate face-to-face?’ At first, probably little would change, but a host of advantages would be lost. Without a retrospective, a team finds it harder to identify areas of improvement or share learnings from solving a certain problem, the dissatisfaction that would get addressed in the retrospective does not get addressed etc. Without a stand-up, roadblocks would not be brought up as early, thereby taking longer in being resolved, and potential chance- synergies are not utilized. Without a Kanban board people may find it harder to know what they themselves, others on their team and other teams are working on, leading to overcommitment (no work-in-progress limit) and double work as multiple people work on the same problem.

A set of ideas that work particularly well together Jurgen Appelo calls a ‘memeplex’, these are things such as Kanban boards and daily stand-ups which, in combination, deliver more benefit than either alone.

2.3. Agile Enablers and success factors

The use of practices and their respective advantages and drawbacks has been thoroughly investigated in the research literature. In this literature, agile practices and the conditions that are required for these practices to be utilized successfully are distinguished. In a systematic review Conforto et al. address this distinction and introduce the term Agile Enablers which they define as “internal or external factors to the organization that are directly or indirectly related with the implementation of the agile management approach that impact the performance and use of a given practice, technique or tool” (Conforto et al., 2014). The study distinguishes between enablers on the organizational level and agile project management enablers. Only the former organizational level enablers shall be discussed here. The enablers identified by Conforto can be seen in in table 1:

1. Organizational structure type 8. Emphasis on speed 2. Organizational culture 9. Performance measuring 3. Entrepreneurial culture 10. Knowledge management systems 4. Learning organization 11. Multidisciplinary teams 5. Agile-style work environment 12. Resource competition 6. Acceptance of agile methodology 13. Strong executive support 7. Adequate reward for agile use 14. Decentralized decision making Table 1 - Organizational Enablers for agile practices; Adapted from (Conforto et al., 2014)

The intention behind identifying these success factors is that they help estimate the success of adopting agile practices. Dikert et al. have identified similar success factor as well as key transformation challenges. The most salient success factor categories in their meta-analysis were mindset and alignment, coaching and training, carefully choosing the agile model and having strong management support (Dikert et al., 2016). The success factors have a clear normative element to them and are formulated in the imperative. With ‘mindset and alignment’ Dikert et al. refer to a strong focus on agile values which helps clarify the reasoning behind the change and motivates people to play an active part in the transition. Focusing too strongly on the practices being implemented can lead to problems. The use of regular social events and participation in an agile community is reportedly helpful. Particularly the use of internal success stories can build a common language around agile ways of working throughout different parts of an organization.

When new practices are being adopted providing the necessary training and coaching teams while they familiarize themselves with new ways of working is a crucial success factor for the organizational transformation (Dikert et al., 2016; O’Connor and Duchonova, 2014). The decentral decision making that agile ways of working entail require that management give up certain control and decision-making authority. This, in turn, means that management must support the transformation efforts for a successful change to take place. Active support from managers reportedly encourages employees to adopt new practices. For managers to be able to endorse the transition, though, they need to be educated on agile ways of working and understand the ramifications this has for their role. A common property that many of the agile enablers and success factors share is their focus on ‘soft’ factors such as values, organizational culture and an aligned mindset. This makes them qualitatively different from the practices which can be observed and to which and organization can adhere. In the analysis section, this distinction is picked and the relationship between practices and values explored.

2.4. Analytical Frameworks

Frameworks that comprehensively cover the adoption of agile methods are primarily focused on agile software development. Because of this focus, they do not fit the application they are for in this study in two distinct ways. First, they lack explanatory power in some areas and second, they explain things that are not applicable in this context. Regarding the first issue, other frameworks can fill these gaps. The adoption frameworks generally overlook intra- organizational boundaries such as those between the development and non-software functions. Similarly, insofar as cultural differences are considered, the adoption models assume a single, homogenous organizational culture. This culture can be problematic for the adoption of agile ways of working, but it is nevertheless seen as homogenous. When using the agile adoption and improvement model as the primary framework for analysis, these shortcomings are made up for by introducing a supporting framework on organizational culture, the competing values framework by Iivari and Iivari. On the second issue, that of non-applicable aspects of the framework, these aspects are dismissed as not being applicable whenever necessary and appropriate.

2.4.1. Agile Adoption and Improvement Model

In the analysis, the agile adoption and improvement model (AAIM) by Qumer and Henderson- Sellers is used in an adapted form to make sense of the data. The framework was developed to assess the required degree of agility and appropriate ways of introducing that agility into software teams. The comprehensive structure of the framework makes it a useful tool for analysis. Especially because governance and knowledge transfer are part of the framework. The purpose of the framework is “to guide the behavior of self-organizing and empowered agile teams with a cohesive set of shared information in large and complex project development environments.”(Qumer and Henderson-Sellers, 2008).

The Agile Conceptual Aspect Model includes Knowledge, Governance and the Method core (see Figure 1). Qumer and Henderson-Sellers regard software development as a particularly knowledge-intensive process. Any process that creates and shares information as a primary form of value creation, like the work in non-software development functions, falls under this aspect of the framework. Since most of this knowledge is tacit the agile methods and the way in which they are adapted need to consider how knowledge can be actively maintained, captured and used for learning and improvement (Qumer and Henderson-Sellers, 2008).

Governance covers the interactions between stakeholders of the organization such as teams, managers, leadership and customers. Qumer acknowledges it to be unusual to include governance in relation to agile methods. Rather, Qumer argues that this inclusion, so long as it avoids incurring “unnecessary overhead”, helps introduce accountability and responsibility into the organization by monitoring and controlling performance and managing risk (Qumer, 2007). This, in turn, helps create business value.

The method core which constitutes the aspects of agility, people, process, product and tools “attempts to provide a vision-guiding or mental-model for an agile methodology” – the absence of which is one of the main factors agile projects fail (Qumer and Henderson-Sellers, 2008).

Figure 3 - Agile Solution Framework. Adapted from the Agile Software Solution Framework by (Qumer and Henderson-Sellers, 2008)

Before utilizing other aspects of the framework, the three central elements of Knowledge, Governance and Method Core is used as a first lens to analyze the data.

2.4.2. The Competing Values Framework

To supplement the Agile Solutions Framework in the area of Governance, the Competing Values Framework by Iivari is used (See Figure 5). This categorization framework identifies four different types of organizational culture based on two dimensions. Internal vs external focus refers to the focus on maintenance of the organizational system (internal) vs a focus on contact with the environment of the organization and the competition (external). The other dimension stability vs change identifies whether the organization is focused on order, continuity and control (stability) or on flexible reaction and quick responses (change) (Iivari and Iivari, 2011).

C) D)

A) B)

Figure 4 - The Competitive Values Framework, adopted from Iivari, distinguishes organizational cultures along a Focus (internal/external) and a stability/change dimension. (Iivari and Iivari, 2011)

The four different cultures identified this way are A) the hierarchical culture (internal focus and stability) which, according to Iivari “is oriented towards security, order and routinization. It emphasizes control, stability and efficiency through the following of regulations.” (Iivari and Iivari, 2011). B) Rational culture (external focus and stability) with a focus on achievements, productivity, efficiency and goal-attainment. C) Group culture (internal focus and change) values flexibility and relations between people. Especially trust, participation and belonging are central values (Iivari and Iivari, 2011). Lastly, D) developmental culture (external focus and change) “is future-oriented, considering what might be. The effectiveness criteria emphasize growth, resource acquisition, creativity and adaptation to the external environment.” (Iivari and Iivari, 2011). Enterprise agility is located in the quadrant of developmental culture. Organizations, however, will likely reflect more than one culture, and a certain balance between the four is desirable. As Iivari and Iivari state: “Agile methods illustrate this need for a reasonable balance. Although they are usually introduced as adaptive and flexible methods responsive to the environmental volatility (especially requirement change) corresponding to the developmental culture and emphasize values of the group culture such as trust, motivation and commitment, features such as timeboxed deadlines and team effectiveness reflect values of the rational culture. Furthermore, agile methods are often applied in a business context that tends to emphasize values of the rational culture such as productivity and goal achievement. The framework suggests that it is naïve to believe that there are no contradictions with agile methods in their emphasis of productivity and efficiency:” (Iivari and Iivari, 2011) The biggest incompatibility between cultures in this framework arises between diametrically opposed cultures such as a developmental and hierarchical culture.

3. Methodology

The choice of method for this study is a result of epistemological considerations and an abductive research approach. The organization being studied is regarded as a complex system. This classification entails that the choice of method was not strictly defined at the outset of the study, so as to not limit the range of possible outcomes. The methodology developed over the course of the study and resulted in an approach that carefully considers not only individual elements of the system but their interactions. In a back and forth between empirical observation, interviews and scientific literature, the study was systematically developed. By first using unstructured interviews, the scope of the research was outlined and then investigated using semi- structured interviews. The choice of method simultaneously benefited from and was limited by the author being a member of the organization studied.

3.1. Study design

This study takes an abductive approach using the notion of systematic combining by Dubois and Gadde (Dubois and Gadde, 2002). This entails a constant matching, directing and redirecting between theory, empirical world, the case and the framework. The study can be seen as having different phases, although these are less distinct as this delineation makes them seem. These phases go from broad and general towards the increasingly specific. From initial discovery to broad exploration, narrowing of focus and targeted questioning. At every stage, the interviews were the primary source of empirical data, although these will change in type from unstructured interviews in the beginning to increasingly structured interviews.

The study has already started out in the ‘empirical world’. The topic of agile practices in non- software environments rose the interest of the author. It seemed relevant to what was happening at Funnel. This then informed the literature being reviewed. In the first phase of this study, the research has been and continues to be exploratory. The reasoning is that the topic and research question around agile practices in non-software functions was defined less clearly as this study makes it seem. Rather, there were several, initially unrelated developments that pointed in a similar direction. In a series of unstructured interviews, the reasoning for the decisions being made are explored to give a perspective on the decision process as it unfolds from different perspectives. Key decision-makers within the organization and people affected by or involved in the change were interviewed for this purpose.

Over the course of these interviews, the topic was narrowed down to its current definition, which happened both as a result of reviewing the literature and the development of decision making within the organization. From the literature and the first empirical material, an interview guide was developed based on the underlying research questions. This guide was used for further interviews with new stakeholders and for interviews with some of the same stakeholders three months after the first interviews to provide a frame of reference on what changed.

At the outset of this study, no single problem definition existed. There were multiple areas of interesting development around agile practices prescient at the beginning of the study. The research question was, therefore, undefined at the outset of the study. Rather, they developed as the strategic direction within the case company emerged. The first set of ten unstructured interviews, each between 45 minutes to an hour in length, was held from the end of December

2019 to the end of February 2020. This first exploration clarified the challenges within the organization and led to the research question in their current form.

In addition to the interviews, further literature review played a significant role in shaping the research questions. Agile practices have mostly been studied in a software development context. In that context, particular enabling or disabling factors have been identified to be necessary or helpful for the successful implementation of agile practices. Some ‘agile-enablers’ translate well from a development context to other organizational functions, but some of these enablers do not. Additional factors come into play with non-software functions. By answering RQ1 the enablers for agile adoption in non-software functions are determined and by contrasting these with the enabling factors necessary for agile in development functions, which have been identified in other studies (Conforto et al., 2014), universal and situational drivers can be developed. Agile enablers reflect the structure and functioning of the organization for which they apply. The differences and similarities in agile enablers can, therefore, provide indirect insight into the organization and the difference between development and non-software functions.

The motivation for the adoption of agile practices within software development has primarily been the direct advantages in terms of delivery speed, customer satisfaction, more collaboration and cost reduction and others (Petersen and Wohlin, 2009). Indirect benefits, such as higher job satisfaction and lower employee turnover were welcome side-effects (Tripp et al., 2016). In adopting agile practices, other parts of an organization with different functions aspire to arrive at the same benefits seen in software development. Again, the question arises, which of these benefits translate to non-software teams. This is addressed in RQ2.

Software teams may adopt agile practices for the expected direct benefits alone. For the non- software functions in a software organization, there may be additional expected outcomes by aligning their work practices with that of the software organization. These benefits accrue to the non-software teams and software development functions alike and the organization as a whole. As Dikert et al. point out in their systematic literature review: a key challenge to the adoption and functioning of agile practices for software development teams is coordinating with non- software functions. The key aspects of this particular challenge according to the study are “other functions being unwilling to change, challenges in adjusting to the incremental delivery pace [of the software teams], challenges in adjusting to product launch activities and the rewarding model not being teamwork centric.” (Dikert et al., 2016). Introducing agile practices helps overcome these challenges and thereby be of benefit to the organization as a whole and by extension, the non-software functions. Whether this is the case will be covered through RQ3.

3.2. Epistemology and ontology

The “complexity paradigm” heavily influenced the different agile practices and the school of thought related to them. Much of the agile methods can be seen as a new approach to dealing with complexity. Both Stacy with his Agreement & Certainty Model (Griffin et al., 1998) and Snowden with the Cynefin Framework (Snowden and Boone, 2007) have developed models that distinguish between the different domains of order, complexity and chaos. One central argument of Snowden’s is that the different domains require different approaches. Snowden draws up a three-step process for each of the four domain he distinguishes (Clear, Complicated, Complex, Chaotic). In the clear domain, cause and effect relationships exist and are obvious to anyone.

The problem-solving process in the clear domain consists of sensing, categorizing and responding. In the complicated domain, cause and effect relationships exist but are not self- evident. The problem-solving process in the complicated domain consists of sensing, analyzing and responding. This means it can be managed with analytical methods such as six-sigma and others. In the complex domain, according to Snowden, the relationship between cause and effect is only visible in hindsight. That means no amount of time spent on analysis will solve a problem. Instead, the problem-solving approach is probing, sensing and responding. In other words, the environment requires experimentation and iteration.

This is what agile methods provide. These frameworks acknowledge the understanding of a system to be the relevant factor. The empiricist, rationalist epistemology, therefore, makes way for a constructivist philosophy.

If this study acknowledges that the organizations operate in a complex domain, which is where the need for agile methods fundamentally comes from, it needs to find methods that are in line with the “complexity paradigm” and are capable of making sense of it. Paul Cilliers discusses this issue at some length in Complexity and Postmodernism. He starts by questioning the realist ontology that underlies the thinking with which systems and even complex systems are often approached. “When is a theory an adequate description of the phenomena it tries to explain? Solutions to these questions have been suggested, but they usually postulate a one-to-one correspondence between elements of the system and specific external causes. This atomistic approach is the legacy of the analytical method and usually takes the form of splitting the structure of the system, and the meaning of that structure, into separate levels.” (Cilliers, 2002, p. 11).

Cilliers then goes into the problem of representation and suggests a connectionist approach with distributed representation. An ‘atomistic’ approach and the corresponding epistemology assumes a direct, one-to-one correspondence of the external object of the study and it’s representation by the study. It, therefore, fails to capture a crucial aspect of complex systems, such as an organization: it fails to capture the relationships between components of the system and its past states and path dependence. This distributed representation is hard to reconcile with the empiricist experimental design. Rather, a narrative case study can be used to account for the historical factors. These are the previous states of the system, and the relationships within the system and its environment. Examining how different parts interact and what emergent properties arise as a result.

A complete representation of all the interactions of the system will not be possible regardless of the chosen approach, though. If a system is complex, constructing a theory of how that system functions would require a system of equal complexity. Ross Ashby formulated this idea called the law of requisite variety (Ashby, 1961). The methodological implication this has is that even with a narrative approach that seeks to examine the relationships between components of the system, an adequate description of a complex system is not possible. Reduction of complexity will have to take place when constructing a theory of the interactions and analyzing the behavior of the system. (Cilliers, 2002, p. 70). Quantitative methods using questionnaires or similar tools would reduce the complexity to an even greater extent than the interviews and an analysis of interactions. Cilliers argues strongly for an epistemology sensitive to complexity. He states: “there is no imperative to subscribe to the post-structural position when we deal with complex, dynamic systems. I find it extremely helpful, and therefore important, but it is possible to make

22 points similar to mine from other perspectives. […] My central point has been that our descriptions of the world need to have an inherent sensitivity for complexity.” (Cilliers, 2002, p. 136) This will especially affect the interpretation and analysis of the interview material, as this empirical material cannot be viewed or understood in isolation and instead only in relation to the other data and the system as a whole.

In science, there has generally been a strong focus on using the correct method, with excellent results. Large amounts of data would otherwise make it difficult for researchers to interpret the results. Studies, therefore, are designed to reduce the variation in outcomes by controlling the number of variables. While this approach is helpful in taming the data, by limiting the variables, the possible range of outcomes is similarly restricted. Cilliers argues that by deciding on a method before beginning the research, the researcher is already restricting the range of possible solutions. The same goes for the choice of the framework the researcher decides on. The sooner the decision for a specific type of method and framework are made, the more limited the possible range of outcomes. As an alternative Cilliers suggests a ‘playful’ approach: “When dealing with complex phenomena, no single method will yield the whole truth. Approaching a complex system playfully allows for different avenues of advance, different viewpoints, and, perhaps, a better understanding of its characteristics.” (Cilliers, 2002, p. 23). This ‘playful’ approach is the reason for the abductive design of this study and the open exploration with unstructured interviews at the outset of the study. To keep the number of possible outcomes of the study high, this back and forth, or systematic combining, between observation and theory was chosen as the methodological approach.

3.3. Methods used for empirical data collection

The empirical data was collected mainly through interviews. To develop an understanding of the organization, the first set of nine unstructured interviews was conducted (see Figure 3). These interviews led to the research literature and applied management literature selected for the literature review. From the unstructured interviews and the literature, an interview guide was developed, which was then used to conduct a set of ten semi-structured interviews. The 19 interviews were each around one hour long, ranging from 40 minutes to 1 hour 15 min. The interviews were recorded and transcribed in full and then coded.

In addition to the interviews, the author held a series of 15 one-hour workshops on different aspects of agile values and practices over the course of the study. These weekly sessions were recorded (for the benefit of other members of the organization), but not transcribed or coded. Excluding the workshops in the empirical material was a deliberate choice to guarantee the participants privacy. These workshops contributed to the study in two ways, though. On the one hand, the workshops affected the organizational environment, and on the other hand, the conversations, questions and observations from the workshops influenced the coding process, the analysis and the literature reviewed for this research. This means there is an element of action research in the study. The author was not, however, assigned a consultancy role in the organization or given authority to suggest or implement experiments. For this reason, this study is not regarded as an action research project by the author.

The theoretical literature, influenced by empirical material, led to a selection of frameworks that supplied the theoretical lens through which the coded material is grouped and made sense of. Limitations and gaps between the coded material and the literature are discussed in the analysis.

Figure 5 - Structural overview of the study, divided into the theoretical, the case and the empirical. Dotted lines indicate influence, solid lines the flow of data. Example: the unstructured interviews influenced the literature selection & were transcribed

3.4. Relating methodology and epistemological position

The reason for the open interviews is that “The advantage of the case study is that it can ’close in’ on real-life situations and test views directly in relation to phenomena as they unfold in practice.” (Flyvbjerg, 2006). This is reflected in moving from broad and exploratory open conversations to more targeted semi-structured ones once a direction is beginning to emerge. This is to say the study will seek to falsify the author’s beliefs. As Flyvbjerg notes, a case study is characterized by falsification rather than verification, and any subjective bias is no more present with this approach than it is with other methods.

A further advantage of this approach is, as has been mentioned before that it allows for more room to discover. Flyvbjergs point here is similar to that of Cilliers talking about the danger of reducing the number of possible outcomes. As Flyvbjerg states: “There are more discoveries stemming from the type of intense observation made possible by the case study than from statistics applied to large groups. With the point of departure in the learning process, we understand why the researcher who conducts a case study often ends up by casting off preconceived notions and theories.” (Flyvbjerg, 2006).

Another parallel exists between Cilliers’ epistemological considerations and Flyvbjerg’s methodological ones. Cilliers argues that characterizing complex systems requires an equal level of complexity in the describing system (the law of requisite variety comes to mind again), is reflected in what Flyvbjerg calls “The irreducible quality of good case narratives”. “Knowledge

24 at the beginner’s level consists precisely in the reduced formulas that characterize theories, whereas true expertise is based on intimate experience with thousands of individual cases and on the ability to discriminate between situations, with all their nuances of difference, without distilling them into formulas or standard cases.” (Flyvbjerg, 2006). The challenge lies in constructing such a narrative of ‘irreducible quality’ that reflects, at least in part, some of the complexity Funnel has as an organization.

3.5. Choice of methods

The motivation for the choice of methods has several aspects to it. First and foremost, stood the epistemological considerations that, while not entirely ruling out a quantitative approach, heavily influenced the decision to utilize qualitative interviews. Secondly, the choice of these methods enabled exploratory conversations and the back and forth between theory and observation when the problem definition and the possibilities were still unclear. The situation within the organization, the planned changes to different teams and the high number of new people joining the organization made it clear that a new and interesting change was beginning. Because the situation was fluid, it required an approach that would acknowledge changing circumstances without damaging the integrity of the study. The third major motivation for the choice of method was the unique opportunity. Before beginning the research, the author had already been working in the organization for about eight months. This meant higher levels of trust and better access to data, both in the form of interviews as well as observations. When changes in the commercial part of the organization began, this presented a unique opportunity for study. Given the considerations above, a qualitative case study promised to be the best fit, both epistemologically and practically.

There are, however, limitations to the chosen methods. One of them goes back to Cilliers’ point: the level of complexity present in the organization cannot be fully reflected in a case study of this scope. Acknowledging the connections within the system instead of conducting isolated analyses of different aspects of agile methods will alleviate that drawback to a tolerable extent.

The high pace of change in the organization is both a drawback and an advantage. Change in this context refers to the manifest changes in behavior, process and procedures, and it refers to the change in attitude and understanding in the people throughout the organization. Since the data was captured through interviews, the perception people have of the changes has a great impact on the data collected. The challenge posed here is that the amount of data that can be collected and analyzed for any given point in time is limited making it difficult to see these observations as a complete snapshot of a point in time. It is positive, though, because it allowed for actual change to be observed and if the data is seen to be points on a progression from one place to another, they can be connected. Another challenge of using interviews is that interviews do not capture the practices ‘in action’. The author was able to observe such practices in the organization and was himself a participant in enacting these practices. This provided a richer context for guiding the interviews, and helped, moreover, to interpret and analyze the results.

Through being part of the organization, the author had a preunderstanding of the setting, meaning having knowledge and previous experience in the context being studied. “They know the history, key events, and jargon used within the organization and who to turn to for information.” (Bryman and Bell, 2011, p. 414). The author faces a role duality between their role as a researcher and organizational participant, which can be problematic if the research

25 threatens “existing organizational norms” (Bryman and Bell, 2011). This poses two distinct limitations to the study. Since the author, as part of the organization, influences the discourse within the organization and is, therefore, a partial observer. Additionally, there could arguably be a conflict of interest, as the author’s employer is simultaneously the object of the study. This leads to some ethical considerations generally, that will be discussed in section 3.8.

3.6. Analysis

Before analyzing the data, the interviews were transcribed. The full-length transcripts were then coded by identifying patterns of similarity, difference, frequency, sequence, correspondence and causation were identified (Hatch, 2002, p. 153). The analysis roughly took the nine steps outlined by Hatch:

1. Reading the data and identifying frames of analysis 2. Creating domains based on relationships discovered within frames of analysis 3. Identifying salient domains, assigning them a code, and putting others aside 4. Rereading data, refining domains and keeping a record of where relationships are found in the data 5. Decide if domains are supported by the data and search data for examples that do not fit with or run counter to the relationships in your domains 7. Search for themes across domains & cross reference these with the theoretical frameworks 8. Create outline expressing relationships within and among domains 9. Selecting data excerpts to support the elements of the outline

Where the analysis differed from the purely inductive approach initially proposed by Hatch (Hatch, 2002, p. 153) differs is in the relationships drawn to the frameworks. After a first reading of the data different frames of analysis were identified. These then served to create a set of domains that were only tenuously related at first and developed stronger connections throughout the process. Then, the more than 100 themes identified this way were grouped and unified into larger domains that were refined after a re-reading of the data. This re-reading also helped to identify contradictions and counter examples in the data. The process of finding counter examples helped strengthen the domains identified to that point and pointed to interesting dynamics and relationships worth exploring further. The codes were related, in step 7., to Qumer’s Agile Adoption and Improvement model, which served as a theoretical lens through which the codes could be related to one another in a meaningful way. Utilizing the model helped to draw out distinctions, interactions and patterns that emerged from the interviews but that was unaccounted for in the theory. Having identified the domains clearly, excerpts that depict the domain or a contradiction well were identified for the text. Beginning with a short description of the events, the empirical material is presented in conjunction with the analysis.

3.7. Limitations

The research is limited, first and foremost, by its scope and whether the research questions can be satisfyingly answered in the timeframe within which the study takes place, as some of the benefits or drawbacks will only materialize on a longer timeframe. A second limitation is the type of data collected. Interviews might be a good indicator to answer RQ2, but to genuinely measure positive aspects of introducing agile methods, additional measurements might be

26 necessary. Measuring sales effectiveness, or tasks completed could be one way of measuring something analogous to ‘code shipped’. A plethora of outside factors influence sales effectiveness. Identifying what can be regarded as measures of success will be a key challenge when conducting this research.

Another limitation to be mindful of is the author’s role in the organization. The author is employed by the organization being studied and arguably has a vested interest in seeing the change initiatives and the adoption of agile practices succeed. The best way to do so, will involve critical questioning of what is happening at the said organization, yet this relationship between author and organization has to be acknowledged.

The author’s involvement in the organization means that there will be a feedback loop that affects the organization taking place. This study observed and partly affected organization.

3.7.1. Validity, Credibility, Transferability and Dependability

Case studies are often criticized for not being generalizable, as they are based on a single case. It is argued that external validity suffers as a result. The formal generalization is only one of several ways by which knowledge can be accumulated though. (Flyvbjerg, 2006) As Flyvbjerg argues, the way by which a case study can be used for generalization is through being able to falsify existing theories and provide a forceful example. This study aims to provide just such a forceful example and contribute to the scientific body of knowledge by using a narrative abductive approach to do so. The richness and irreducibility of this approach fits the constructivist epistemology and connectionist understanding of the organization as a complex system. The narrative nature of the work makes the results of the study transferable by providing the necessary context for it to be judged.

The connectionist model and reciprocal interactions render the notion of internal validity or causality mute. To apply the concepts of validity and reliability, a clear social reality would have to be assumed. This would conflict with the epistemological position taken in this study. For these reasons, the study instead tries to remain internally consistent by providing credibility through triangulating findings (Bryman and Bell, 2011) first through unstructured and then increasingly structured interviews. The study is made dependable by keeping a clear record of all interviews and transcripts and other empirical material and accessible to audit. The empirical material will, however, not be published in full alongside the study to preserve the privacy of the participants (see Ethical Considerations).

3.7.2. Bias

The main contentions to address regarding bias in this case study are the general notion of subjectivism in case studies and the role duality of the author as both a researcher and a member of the organization. Regarding the former Flyvbjerg concludes: “The case study contains no greater bias toward verification of the researcher’ s preconceived notions than other methods of inquiry. On the contrary, experience indicates that the case study contains a greater bias toward falsification of preconceived notions than toward verification.” (Flyvbjerg, 2006). With the tendency of the case towards falsification, an injection of values is nonetheless possible. The response to that dilemma is twofold. Firstly, the recognition that all research is subject to values

27 that inform the object of study, the variables measured and their interpretation. A case study is no different in this regard. Secondly, the case study can meet this objection by reflecting on these factors and acknowledging them. The most important of these in the case of this study is the authors own role in the organization. By involving themselves in the adoption process of agile methods in the commercial teams at Funnel, the author invariably tied up some of their reputation in the success of the adoption of these methods. Being a member of the organization may influence them to paint a positive picture of the organization. Similar to how a biased researcher may identify more sensational findings than evident. In both cases, a critical and unbiased study of the successes and shortcomings of the agile adoption and Funnel as an organization offer the most promise to achieve these goals. Uncovering problems and shortcomings in the adoption will yield the best chances at solving those problems and showing that Funnel is an organization that can handle a critical assessment of its success or failure paints a more positive picture than a biased depiction of the case. This is why bias in this study shall be regarded as no more prevalent than in any other research.

Arguing for a distance between the company and author, that does not reflect reality would negatively impact this study. As the section above argues, this potential source of bias is mitigated in several ways. First, by the author actively seeking out to falsify the assumptions made about agile adoption, because this holds more promise to positively impact the company and the study. Second, by clearly outlining the connection between author and company, thereby offering the reader the opportunity to view the study critically. Third, by providing a rich narrative and empirical section that explicates rather than explains and leaves some of the conclusions to be drawn by the reader.

3.8. Ethical considerations

Potential harm to participants of the study is considered. Because the author is a member of the organization being studied participants in the interviews were very open. This trust and openness during interviews must not be abused, and critical or controversial statements may be part of the data. The interviewees will therefore not be named, and their role not made explicit if doing so would make them identifiable in any way. The interviewees consented to the recording and transcription at the beginning of each interview. Any comments that were requested to be ‘off the record’ or retracted following the interview were excluded. The names of people mentioned during the interviews and other identifiers have been removed to ensure that non-participants and other organizational members would not be involved without their explicit consent. The fact that the author was working on this study was openly communicated within the organization and interview participants were informed, as far as they were not already aware, about the purpose and intention of the research and the interview. To ensure the privacy of members of the organization, no material beyond the interviews was used in the study. The empirical material from the workshops, for instance, while affecting the researcher and influencing the selection of literature, was not used for this reason. Because the author is part of the organization setting these boundaries was perceived to be particularly important.

Apart from harming participants or organizational members directly, the results of the study can potentially impact these people indirectly. By suggesting ways of organizing that have adverse effects on people’s jobs or their job satisfaction. The study could be harmful by highlighting problems or challenges in the organization where there are none and be misleading to its

28 members. These two possibilities, affecting people’s jobs or highlighting the wrong problems are regarded to be minor risks for two reasons. First, the participatory nature of the organization. Any changes suggested are discussed with the people affected and not made hierarchically. This means that even if the study were to suggest unwelcome change the people affected have the ability to impact such a decision. Second, the high autonomy of people at Funnel and their familiarity with the subject of agile ways of working means that the authority awarded to this study and that of the author are at no risk of being exaggerated. Lastly, the author of the study will remain a member of the organization and will themselves be affected by any changes. This means that the author will be able to clarify any misunderstandings that may prove harmful at a later point and that they are equally affected by any changes made to the organization.

4. Empirical Material and Analysis

In this section, the Agile Conceptual Aspect Model, consisting of Knowledge, Governance and the Method Core is used as a conceptual lens by which the empirical material is grouped and analyzed. Tensions within the implementation are highlighted within each of these domains, including challenges inherent to the adoption of agile methods at Funnel. Following that, an emphasis is placed on the interrelation and interaction between the elements. This leads to a discussion on whether enabling factors for agile ways of working can, in fact, be isolated, and whether existing frameworks do the interconnected nature of these approaches sufficient justice.

Organizations developing software increasingly employ methods of working referred to as agile software development. These methods focus on delivery speed, customer interaction and flexibility, among other things. Funnel AB, the organization that is subject of this study, is a software organization that utilizes agile methods in their software development. Instead of just using agile practices for software development alone, though, Funnel has begun a process of introducing these practices into the non-software or ‘commercial’ part of the organization. This study explores how these practices are adopted and what benefits and challenges arise from the adoption process by the commercial organization.

4.1. About Funnel.io Funnel is a Software-as-a-Service company founded in Stockholm in 2016. The company has around 145 employees, split between an office in Stockholm and Boston (Massachusetts). In December of 2019, Funnel closed a $47 million Series B funding round(O’Hear, 2020). The company offers a subscription-based software product that allows businesses to automate their marketing data collection and reporting and provide what the company calls ‘business-ready’ data (Funnel, 2020). The capabilities and scope of the software constantly develop, influenced in large part by customer feedback. Within the organization there are two broad functions: the software and product development, entirely based in Stockholm, and the commercial and supporting functions based both in Boston and Stockholm. Both play an integral part in delivering the product. Just as Conway noted, “organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.”(Conway, 1968), the structure of the product is reflected in the organizational structure of the development teams. Broadly, there are teams for the data collection, data transformation and data export respectively as well as teams supporting these different functions with internal tools and a team overseeing the product development as a whole. In total, these teams make up around 60 people.

The commercial functions include marketing, operations, sales, product specialists, customer success, data-operations teams and other supporting functions include leadership, finance, talent acquisition, legal, information security and office management. The commercial functions correspond in large part to the customer lifecycle, i.e. first contact through marketing, buying the product through the sales and being onboarded and keeping in contact with the product specialists and customer success. Most of these functions include smaller sub-teams with different specializations. Within sales, for instance, there are sales development representatives (SDRs) that have the first customer contact and account executives (AEs) with different specializations that work on closing a deal. The number of teams, their function and composition have changed over time and continue to change.

4.2. Agile at Funnel and in Non-Software teams – A Brief History The software development function at Funnel is heavily influenced by the ideas of Agile Software Development. It makes use of many different practices from the field of Extreme Programming (XP), Kanban, Lean and others. This was a strategic decision early on in the company’s history. As a leading member of the development organization notes:

“I think the best example of something that we invested quite a bit in early on when we set up Funnel on the tech side was the continuous deploy. So, we spent quite a few engineering hours making sure that code goes out into production as close to immediately as we can. Let's say five minutes after it's done. It's more common practice now. But five years ago, that was still very unusual. There were some companies like Etsy and HubSpot that were doing this. And we were definitely reading what they were doing and invested in that. Again, in order to support a Lean Startup cycle where we could actually iterate fast, but we needed to invest in technology to make that possible.” Interviewee 7 – Development Organization

These practices are beneficial to the speed with which changes can be made to the product and new features can be introduced. Agile practices have, according to the leadership team, played a role in the satisfaction of the people working at the company. Towards the end of 2019, the idea of adopting agile practices outside the software development department started taking shape. The development and execution of this effort are being explored in this study.

Funnel is divided into software and non-software development. This distinction is, however, all but absolute. Regular interactions between teams and individuals happen regularly, both physically and virtually. This means that some of the ways of working are shared across the entire organization.

September 2019, however, marked the first time that the entire organization came together for several days. The meeting took place in Paris and marked the beginning of many of the processes explored in this study. During this company retreat, the topic of agile ways of working, the agile manifesto and principles were presented. This clearly showed the way the development teams worked and illustrated the differences to other parts of the organization. Members from the sales team articulated how it made them think about their commission-based compensation and how that ran counter to the ideas on collaboration and teamwork emphasized in agile ways of working:

“I think when we were in Paris, and we had this talk about agile and agile concepts. It was not only me it was multiple people like really thinking about it [the commission-based compensation].” – Interviewee 1 – Sales Team

“After the presentation of agile I said, the sales team is not aligned with the rest of the company, really, when it comes to objectives and goals because we… I mean, since we are earning based on how much we sell.” – Interviewee 2 – Sales Team

The Paris trip led to a conversation about changing the compensation structure of the sales teams from an individual commission-based model to something else, such as team-based commissions or fixed salaries. The decision to switch to fixed salaries was made in December, and the transition to the new compensation model happened at the start of January 2020. The

31 change in compensation marked the turning point towards a different way of working and the beginning of introducing the agile wording into the commercial organization. The change in compensation structure is relevant to the agile transformation because individual commission stands in the way of the needed collaboration for agile ways of working.

“So up until the end of last year. Everyone has always been... we've been trying to work in an agile way and learning from the dev-team, applying some of their thinking and, you know, small things and we have a shared philosophy, but it wasn't clear that we were... no one called it Agile specifically or we're trying to be agile. I know it was after Paris. Then, I think, a lot more people understood: one, that it's for real, that we really think this is an important thing, we really think it's worthwhile pursuing. And the combination of people having a good time together was a bit of a "wow" this is pretty awesome team. And then they heard the keynotes and did these exercises. Then after that, people were starting to talk about it and call it agile. The commercial team, especially the sales team, I think they saw all of that and they started to feel this is real, and now I'm starting to understand what it is and why.” Interviewee 15 – Leadership

This transition for the sales teams in Boston and Stockholm coincided with another change in the commercial organization. A transition in how the customer success teams handle the relationship with the various clients of the organization. Each customer success manager (CSM) is responsible for a number of clients, who’s interests they represent within the organization, helping them integrate the product into the client’s processes, troubleshooting problems and collecting feature requests from customers. The customer success team in Stockholm decided to split into three smaller teams with different specializations based on typical clients: Agencies, E-Commerce companies and others. As one of the customer success managers explains:

“The reason we picked that account split is because in the past year or so the product and the complexity of the use cases has become too big for someone to know everything. The number of features in the product and in the connector increase exponentially. And there's a cap of how much you can know top of mind. And at any given time, we were also feeling that we were underserving clients. Because we weren't providing them with enough best in class examples of how they could work, because we were spread out across all different industries, an agency works very different from an e-commerce works very different from a travel company.” Interviewee 3 – Customer Success

This change had other knock-on effects. It went along with a new way of assigning recent clients to the customer success managers, for instance. Previously, a customer had been assigned to a customer success manager from the salesperson who signed the contract with the client, this push system was replaced by a pull system. This means a new customer will be assigned to the customer success manager who signals availability.

After introducing the new compensation structure, the sales team began a process of reorganization into smaller teams with different specializations based on client size. These teams, sometimes referred to as ‘Pods’ have around four members. The transition to agile ways of working began to move more into focus and the need for more active change was introduced. Over two months, a new responsibility within each sales team developed called ‘agile coach’ in Stockholm and ‘team lead’ in Boston. This new responsibility meant that one person on each sales team would dedicate part of their time to facilitate agile meetings like the retrospectives and prioritization meetings and spend time doing one-on-one sales coaching sessions with other team members to develop their skillset even further.

These changes, the improved collaboration and reduced friction between individuals were made possible by dropping the commission-based compensation:

“I think removing the friction was one thing, but it was not the big thing. I think, what we were saying was, we knew would have to make a ton of changes moving forward. The compensation model just stood in the way of that. Every time we wanted to make a change people were worried about how will this affect my pay, you know: "will I get worse leads?", "If I cooperate more what will that mean for my compensation?" etc. so that was just an impediment. But the long-term strategy is to work, agile that's the big point. We have really smart people we want to make sure that they are activating their brains. And we think working agile will do that.” Interviewee 9 – Leadership

Apart from these changes, the transition to agile ways of working is increasingly seen as an active project. The heads of the different commercial teams have taken time to discuss agile practices with leaders from the development organization at an offsite meeting. Since the start of the year there are weekly sessions to learn about and discuss aspects of agile practices and values held by the author of this study. In April an external agile coach has been hired to help the sales and customer success teams in their transition to agile ways of working.

To summarize, the way the development organization works inspired a shift in thinking in the sales teams leading to a new compensation structure and later on new team divisions and new responsibilities in the form of ‘agile coaches’. At the same time the customer success team in Stockholm decided to reorganize and, in the process, think about working in a more agile fashion. The teams have partially implemented a weekly prioritization meeting, daily stand-ups and regular retrospectives. This transition, its advantages and disadvantages, and ongoing challenges and the way in which agile methods were adapted will be explored in the analysis section.

4.3. Knowledge

After the change in the compensation model and the new team structure were implemented, the way in which knowledge spread throughout the organization changed too. The need for a different way of interaction to enable better knowledge sharing, however, was a result of this transition and a catalyst of it. The customer success team first grappled with too much information and too little time, for instance, in meetings with too many participants. After splitting the team, they now face the challenge of knowledge silos potentially forming. Other challenges come up throughout the change process also: Members of the leadership team have to find ways of keeping track of multiple autonomous teams.

The response to these challenges is both structured and unstructured interaction. One development that takes place in an unstructured and a structured way is more cross-functional interaction and spontaneous teaming emerging as a successful approach to sharing knowledge. A purely structured approach are monthly deep-dive sessions into a topic. In addition to the cross-functional interaction, coaching in the sales teams helps people develop skills.

4.3.1. Relevant knowledge and silos

Creating, sharing and utilizing relevant knowledge is a key activity for organizations engaged in knowledge work. Merely sharing the available information within a team does not solve the problem of disseminating tacit knowledge, though. The amount of information and the number of interactions became too great for the customer success team:

“At that point we were only five or six. It was still possible to have pretty good meetings, deep discussions about things. But when we approached 7, 8, 9 people, it became untenable. So, we've done a few things to address that. Now the product specialists and the CSMs [Customer Success Managers] have their own retro [retrospective meeting]. Before we used to be all together, but then they were 12, 13, 14 people having a retro and it dilutes the value, which nobody really gets to talk about, what their concerns are.” Interviewee 3 – Customer Success

To counteract the dilution of relevant information and provide more value to the customer, the customer success team split into smaller teams. This enabled sharing information to be relevant to the people in the team. It created another problem, however, because this new information now threatened to be siloed in one team. This meant that, while information is shared within a team, it may not be shared across teams, making it less visible to other members of the organization.

“We've definitely talked about how we can reduce a silo effect of this, so that's why we're doing the knowledge sharing recurring events where we try to find a common theme with our clients and then a few people present the clients use-case. […] I imagine this being a bigger problem when we're twice the size next year. But it's definitely something to keep in mind. But the original outset was to mimic what Dev [the development organization] had to do a couple of years ago as it became untenable for one team to look after all plugins.” Interviewee 3 – Customer Success

To avoid knowledge silos of the sort described above from forming, Funnel works transparently. For the most part, all information is made accessible to all employees. Files are stored in shared cloud storage that employees can access, with the exception of sensitive financial or personal data. Key data on organizational performance is visible in the internal business intelligence tool. Around fifty percent of the internal communication that takes place over communication platform Slack is openly accessible to others. This makes finding relevant information much easier and raises the number of serendipitous interactions. On the flipside, it has led to a large amount of information and notifications that make it difficult for people to find only what they are looking for without being overwhelmed.

4.3.2. Bridging the gap - Cross-functional interaction

One function that is then responsible for bridging the gap between potential silos is the team leadership – the one person in charge of multiple teams. The creation of multiple smaller autonomous teams raised the challenge to the leadership of these teams of having to be aware of what the different teams are working on. Avoiding redundancies or double-work and ensuring that teams find ways to collaborate in addition to the interactions that the teams organize by themselves. As one interviewee notes, the cross-departmental interaction can be particularly challenging:

“I don't have the answer for how we do this, but one thing I am missing is that cross-departmental function. We have a commercial heads meeting. Where, heads of Customer Success, Sales etc. all sit and talk to each other, but there's no Product, there's no Dev in that room.” Interviewee 9 – Leadership

Another way of bridging the gap between teams of entirely different functions has been the formation of impromptu cross-functional teams. This takes place mostly irrespective of involvement from the leadership team. The absence of commission (the individual compensation based on the sales price of a sale) for members of the commercial teams, especially sales, makes collaboration easier. With commissions in place, time spent helping others meant time not spent on your own sales opportunities. Where collaboration did happen, only a single person would be rewarded for a team effort. Without commissions, these potential sources of friction fell away. Particularly difficult challenges are now being solved by team members from across the organization more often than before. This includes sales, data operations, customer success, data engineers and developers, to name a few. Even for less unique challenges, cooperation has increased:

“The big change was when we brought everyone into smaller teams, and then we had a team goal in place as opposed to individual goals. That made a big difference, so we were that really put the ‘we’ before ‘I’. In those cases, we are trying to align the best people up for each opportunity. Having those smaller functioning teams, they sit together in a pod so they're constantly asking questions of each other. […] We were kind of doing this before, but now we are doubling down on that.” Interviewee 13 – Leadership

This process is reminiscent of what Amy Edmondson calls teaming: “teaming is teamwork on the fly-coordinating, collaborating, across boundaries without stable team structures.” (Edmondson, 2012). This is especially helpful, according to Edmondson, in a complex and unpredictable environment.

One area where cross-functional collaboration and tacit knowledge sharing are apparent is in handling customer support issues. The Boston team distributes the responsibility of handling customer support among all the members of the customer success team in Boston. By contrast, the Stockholm team assigned a single person the sole responsibility of handling support for a single day on a rotating basis. Many support issues cannot be solved completely by one person or the customer success team alone, though. Issues that require insight into the programming of the software, for instance, depend on assistance from a developer. By reaching out internally, these issues would eventually be solved. But this model proved to be unsustainable, and a new collaboration function was introduced with the so-called ‘Support-Hub’. Support in the Stockholm office is now handled by a team of people from different functions including customer success, development, product development and others. The participants in the support-hub rotate that responsibility instead of being permanently assigned. This temporary experiment has proven to help share knowledge across functions and provides an additional benefit by making customer issues more visible to the product development organization.

The interactions between the commercial organization and the (product)development organization in general (within and outside the support hub) proved to be pivotal to the direction the software product is evolving:

“Probably customer success to the greatest extent but also sales to a huge extent, play a huge role in shaping our product strategy and where we're going. I don't think they feel it, it’s not obvious to them. But if you were to turn off our interactions with customer success and sales tomorrow. We'd be like: ’What just happened? Did the world stop?’ We don't know where to go anymore.” Interviewee 16 – Development Organization

With smaller teams comes a greater reliance on regular interaction. Regular, deliberate all-hands meetings such as a weekly meeting on updates from each team and a monthly meeting on the state of the product and a separate meeting on the state of the company help to communicate big topics and shifts within the organization. Some smaller interactions happen in organized environments like the support hub. Others are entirely unstructured and take place at shared places in the office or through the internal messaging app Slack.

Along some channels, though, this interaction is easier than others. While the entire organization attends weekly and monthly meetings and has access to the messaging application, the software development organization is exclusively located in Stockholm. This makes organic, unscheduled interactions between members of the organization in Boston and the development organization in Stockholm much harder, and the difference in time-zones makes establishing a support hub in the Boston office much more difficult. The use of tools for video conferencing, shared calendars and the internal messaging app all help to bridge this gap.

4.3.3. Building new skills – Coaching in the sales teams

The transition to agile ways of working saw the introduction of the ‘coach’ responsibility, an existing member of the team taking on the additional task of facilitating agile meetings and coaching other team members on their sales skills. Coaching sessions are one-to-one interactions that involve shadowing and reviewing a call, co-selling a deal, or discussing a particular issue. This relationship requires high levels of trust and an overall environment that is open for feedback. These issues, and how agile ways of working help to establish trust will come into play both on a governance and method level.

4.4. Governance

Governance, while not explicitly labelled as such at Funnel, refers to the internal structures, processes and frameworks. Qumer frames integrated agile governance as consisting of agile perspectives, governance tools and the goals of governance and operations, see Table 1. The core idea of this governance structure is that it avoids burdening the agile environment unnecessarily and strengthens it instead while still maintaining some level of overall governance.

Agile Perspectives Governance toolkit Agile governance goals and operations Lightweight Framework Control Collaborative Processes Accountability Communication oriented Structures Maximize business value Economical Strategic alignment of Business and agile goals Evolving Performance and risk management Table 2 - Integrated agile governance elements from (Qumer and Henderson-Sellers, 2008)

4.4.1. Reasons for being Agile from a governance perspective

Creating business value is a goal of any for-profit organization. When working in an agile way, this is seen as a consequence of providing customer value, though. Delivering customer value, in turn, is perceived as a consequence of the agile ways of working discussed in the method core. The central argument within Funnel that surfaced multiple times is that utilizing agile ways of working helps to maximize the contribution people can make by letting them take an active role in making decisions:

“We're doing agile because it empowers people - connotations of that word aside. It lifts people up in terms of decision making, the ability to impact the organization and it gives them a lot more freedom to define the direction of their work and their team's work which then overall makes work much less stressful and much more fun place. But I think to make sure that can happen i.e. remove the stress and make us more efficient. I think that's where a lot of these pieces around communication, expectations, scope of the team's decision making those things become really important. […] I think it's about bringing the decision making closer to the source of the information or the challenge itself. A lot of the structure of Agile enables people to be free of reliance on some manager or figurehead to make decisions for them and gives people a lot more autonomy to make their own decisions and prioritizations - the tactics - to approach a certain problem. And then how to address each problem and the ability to form working groups or teams or across teams as needed for specific problems. So, I think it's really about bringing the decision making to the organization without needing a Manager to make the decisions.” Interviewee 17 – Leadership

Implicit in this is that teams and individuals have the ability to collaborate freely, as was seen in the knowledge dimension above. Several tensions arise from following this governance structure, though. First, managers and leaders need to give up control and be able to deal with more uncertainty. Second, there needs to be some assurance that teams work towards shared strategic objectives instead of what feels relevant to them at any given time, in other words finding the correct scope. Third, building a sense of accountability. Fourth, the setting of clear expectations for teams and individuals in an environment that is constantly changing or

37 evolving. Fifth, having people feel ownership over their work and decisions without creating conflict between teams or having things ‘fall through the cracks’. Sixth, minimizing decision fatigue and sparing people from making decisions who are not equipped to make them because they lack relevant information, time or skills.

The tensions listed are not unique to organizations implementing agile ways of working. In agile organizations, the underlying assumptions are different, though, and so is the repertoire of the available organizational responses, which is why these tensions will be discussed individually and related to the method core, underlying values and principles.

4.4.2. Giving up Control for Organizational Leaders

For self-organizing teams to form and people to take ownership of decisions requires that individuals in leadership positions cannot have all decision-making authority. In an environment that previously operated with a ‘command and control’ structure this shift can be major. At Funnel, the transition turned out to be less jarring as this proved to be the modus operandi before deliberately introducing agile ways of working into the commercial organization.

There is a deliberate trade-off, though, between making a decision quickly and limiting the organization. Both can be a result of having central decision-makers. Giving up some control is difficult to argue with outside stakeholders. As one person put it: “I think it's very scary for a lot of people and if you would just tell the board or someone else, that this is the way it works they would be nervous because then they would definitely ask: where's the control going?” The reason people nevertheless feel able to relinquish decisions to others is a high level of trust in the people working at the company.

“What I've learned is: we hired these people for a reason and there's a trust factor when you do hire somebody. So, for me, these people have my full trust that they're going to do the right thing and come to me when they have some questions or if something's not working, I can give some guidance, but they're all smart individuals.” Interviewee 15 - Leadership

The role of governance in the organization then, rather than providing direct control mechanisms, is to provide indirect control through high trust, which in turn is achieved through good hiring practices, among other things. What becomes clear at this point is to what extent trust has to be present before a transition to agile ways of working. The issue of trust is, of course, relevant in non-agile organizations too, but it becomes all the more pressing when relinquishing control is a prerequisite to making the organizational structure work in the intended way, as is the case with agile ways of working. Knowing that teams focus on strategically important tasks is one aspect that helps leaders give up control and decision-making authority.

4.4.3. Scoping & Working Towards Strategic Objectives

In the theory section, the idea of a backlog was introduced. A backlog - a list of all possible outstanding tasks to work on - implies that the number of things a team can work on is larger than what they have time for. That makes it all the more crucial to set priorities for the work with the highest impact for a given input. The prioritization techniques explained in the theory section do not necessarily solve the problem, though, because they can only be as good as the

38 clarity of the strategic objectives they prioritize against. Before a team can set clear priorities with one of the prioritization-tools, a team or department needs to know what they are striving for. In essence, the question “what does high impact mean when prioritizing?” needs to be answered before any clear priorities can be set by the team.

Given that many teams, especially in the commercial division, have close customer contact, current needs and issues can seem more pressing than strategic but less urgent priorities. Some of this urgent pressure at Funnel was alleviated by commissions being dropped for the sales teams. The commissions had added additional incentives to solving problems of customers who were in the process of negotiating a deal with a salesperson. Even without the commissions, the need for some guiding objective remains. The list of possible tasks is longer than the time available to them. The organization relies on individuals and teams to make their own decisions which entails that less general direction is given ‘from above’. A member from the product organization put it as follows:

“You need a common understanding and belief in where you want to go and what you want to be. And I think that’s a really hard part. It’s easy in a top down model because then the top can just decide where you want to go with what you want to do, and everybody just falls in line. Whereas in this kind of [agile] context where it’s much more organic, you need to arrive at that conclusion together in some shape or form. Now obviously some people will be more driving in shaping that sort of vision. But I think it’s super important because if you don’t have that [vision] you end up with anarchy easily and that that’s not a good place to be. So, I think that is another super important ingredient to make this [the adoption of agile ways of working] work.” Interviewee 16 – Development Organization

The development organization at Funnel created what they call “strategic drivers” to solve this problem. These are things “when achieved in the product will contribute greatly to the success of the product”. Initiatives in the development organization are then expected to align with at least one of these strategic drivers or be dropped. A similar set of clearly articulated strategic objectives is absent in the commercial teams, although some teams, such as the marketing, customer success and commercial-operations teams have adopted the idea of defining strategic drivers from the development organization. There exists then, a lack of tools, in the form of strategic objectives, that can help the commercial teams align on what is important. As Interviewee no. 16 notes:

“I think we’re struggling with this [common vision] and that this is an area we need to improve in. It would make things a lot easier. I’m sensing that there is a certain degree of uncertainty, I think probably in all teams, when it comes to these matters of shared vision to varying degrees between individuals and teams. But I think all teams would benefit from getting more of this context and be part of shaping it more as well.” Interviewee 16 – Development Organization

The challenge that arises for Funnel in this situation is that the need for shared strategic drivers in the commercial organization. But defining these drivers ‘top-down’ stands in tension with the increased autonomy that the agile ways of working entail. Satisfying either one of these conditions in isolation is more easily possible; it is in combination with other agile practices that maintaining the integrity of the agile ways of working becomes difficult. Difficult, because more people with a wider set of views and opinions need to be involved in the process of agreeing on strategic directions. As the interviewees argued, though, it is precisely this process of involving more people that makes agile practices powerful.

4.4.4. Creating Accountability

The issue of accountability is closely related to that of control and the setting of clear expectations. Accountability means people living up to the expectations they set themselves or that were set for them by others. Accountability mechanisms are necessary because complete trust may need to be developed first. The commercial organization at Funnel faces the difficult task of maintaining accountability while reducing the level of direct control while abandoning a compensation structure that had an inherent accountability measure for the sales teams – commission-based compensation.

“To some extent I think that is still to be figured out how that [holding ourselves accountable] works. So, we're counting on that part now also being self-organizing. I think it's more important than ever to track KPIs, so that you can see if the team is doing well on KPIs but what you can't do is hold people accountable to individual KPIs because then you're breaking the model. I think in sales that is a bit difficult because you're... I can see the problem where the team is doing great, but that individual in that team is the laggard. And then what will then happen to the team, and will they start questioning if they should have the same compensation or the same level or something like that.” Interviewee 15 – Leadership

As this statement makes clear, the simple approach of using performance tracking goes against the decentral approach in the way teams organize and therefore needs to be avoided. The hope is that team members will hold each other accountable instead of a leadership figure taking on that role. Similar to how a sports team strives towards improved performance:

“The way I want to think about it is if you're in if you're in a sports team. Then you have that dynamic you don't want to have team members that are assholes, right? But, you're gonna point out, if someone is not doing their job or, or not even that, if you want to make sure that they improve, […]. It's common in those situations that you actually do that, or the coach does it. It's nothing people take badly but everyone knows it's for the good of the team and it increases our chance to win this league and move on to the next. Regardless if you're a goalie or whatever position you have everyone cares about that. And eventually, underperforming team members are out.” Interviewee 15 – Leadership

This hinges on a couple of things, though. Firstly, the performance of other team members must be visible to the team. Secondly, it requires a culture of openly addressing shortcomings and engaging in productive conflict without damaging relationships. Thirdly, if the responsibility of holding team members accountable is now with the team instead of the team leader, that switch needs to be communicated.

As several interviewees noted, using key performance indicators (KPIs) is one way of measuring performance. These measurements are then to be made available to all the members of a team which can then establish norms around acceptable behavior. Without outside influence these systems are at risk of being self-reinforcing though, either leading to exceedingly high or low expectations leading either to excessive pressure or frustration for some team-members. The complete absence of governance, therefore, can be problematic, as can be too much outside influence and control.

To engage in conversations with an underperforming team-member on the topic of their performance is a difficult process, especially when that conversation is uninvited. Clear performance indicators lend some level of objectivity to the conversation, but disagreements on what constitutes good or poor performance can still arise. To have a conversation of that kind without producing lasting damage to a working relationship requires training and practice. It requires a culture that allows for engaging in this kind of conversation without endangering the reputation or relationships. People drawing attention to shortcomings or those being called out, need to do so while avoiding blame. What has not been clearly articulated in the commercial organization at Funnel is to what extent team members are responsible for holding one another accountable and. It follows that training around having conversations within the teams on issues such as poor performance still needs to be held. This may be felt to be unnecessary, due to general satisfaction with everyone’s contribution to the team but remains something that has been left unaccounted for.

Holding a team leader or head of a department accountable can also be difficult. Many interviewees in such positions expressed that they were open to hearing about potential shortcomings on their part from their teams. Without explicit expectations being set and an implicit hierarchy, this can prove to be a very difficult conversation. Even more so than with team-members on the same hierarchy level.

The interviews painted a general picture of satisfaction with the current approach, yet a clear picture of how accountability was to be handled did not emerge. It was evident that relatively few issues arose in the first place or that these would be handled within the teams without leadership intervention. This approach was chosen, at least in part, to safeguard the agile ways of working through traditional accountability measures.

4.4.5. Setting Clear Expectations and Defining Ownership in a Changing Environment

As was noted above, accountability requires that people know what is expected of them. The setting of clear expectations applies to both within a team as well as between teams. In a static environment, these expectations could be defined and set once and then only need to be followed. The basic premise of agile ways of working, though, is that they are a response to a dynamic environment and are as the name implies - ‘agile’. That means that new tasks and processes develop, new organizational functions arise, and new people join the organization frequently. That means expectations need to be renegotiated and clarified on an ongoing basis if trust is to be built and maintained between teams. An example from the interviews is that of the collaboration between sales development representatives who provide leads (i.e. possible sales opportunities) to the account executives who provide feedback on these leads.

“One of the things that I think is really important is getting teams talking to each other about their goals, their drivers, their challenges, not necessarily individual pieces of work that may have gone well or may not have gone well. And I think taking those things to that next level, or that higher level, helped see a lot of that intent behind the outcome, which I think can then help build a lot of the trust between the teams. I think then when it comes to the practical element of trust, making sure that we know what to expect from each team that we collaborate with is important. So, if I'm an SDR [Sales Development Representative] and I hand over a new sales qualified lead to an account executive, then that account executive should know what to expect in terms of the

information provided alongside that lead. And roughly how well qualified that lead is. And the expectations that have been set with the person on the other end of that lead. And then as an SDR I should know what kind of feedback I'm going to get from the account executive and what format that's going to be in and when I can expect it. So, I think those are the two big things for me. Understanding each other's intentions and then knowing what to expect when it comes to the practicalities of collaborating.” Interviewee 17 – Leadership

While this may be conceptually understood, in practice, there were instances of where difficulties nevertheless arose because clear expectations had not been set. One example, related to the adoption of agile ways of working, was the introduction of agile coaches into the sales teams. When this new role was introduced a loose set of responsibilities was defined that the coaches were to take on. The ‘coach’ responsibility was understood by some to be just that, a part-time responsibility, but only after a few weeks were concrete expectations regarding the tasks and the time commitment decided on.

Similar to framing this as an issue of unclear expectations, this could be understood as an issue of unclear or confused ownership. This is particularly true for ownership of decisions and authority. The distinction between the two is subtle: ownership pertains to something static, such as a process, decision, authority, or part of the product. Expectations pertain to the behavior towards or within a given process, product or decision.

What became apparent in the interviews is that the issue of expectations is a double-edged sword. On the one hand, given that the organization is subject to a lot of change expectations can be set loosely in the hope that people will take on whatever new function or task it is that arose. This has the potential disadvantage of leading to confusion of ownership as multiple people feel responsible for the same task, leading to double work or conflict, or the assumption that a task is someone else’s responsibility since it ‘must surely fall under their broad umbrella of expectations’. On the other hand, defining ownership to narrowly can stifle valuable initiatives people may want to take for new challenges that nobody had been responsible for. Leading to people saying: ‘this is not in my job-description’. Both of these outcomes are undesirable, but at Funnel, the challenge is more of the former ‘scope creep’ rather than the latter ‘averting of responsibility’.

A common tool to solve the problem of setting clear expectations and defining ownership boundaries are contracts in the form of a service level agreements (SLAs) between two parties on what they are expected to deliver to one another. But SLAs are inherently static, which is part of what makes them useful, this makes them cumbersome to adapt though. If the SLA is ignored in favor of evolving how the organization works, it ceases to be useful in the first place. Instead of an SLA or some similar tool that defines boundaries and sets expectations, an approach that helps guide the continuous exchange and re-negotiation of expectations seems necessary. This is where a shared strategic objective for the team could, on an organizational level, help provide clarity on the key things towards which a team is working.

A team vision does not immediately resolve the issue of how expectations can be set on an individual level (e.g. between team-member and head of the department), but it helps guide a conversation on how each sees themselves contributing towards the same end.

4.4.6. Decision Fatigue and Uncertainty

The benefit of autonomous decision-making is, according to the interviewees at Funnel, that better decisions get made at the point of most information and that the organization is unconstrained by a few key decision-makers. There are limits to this autonomy though and delineating where these boundaries lie, what decisions and responsibilities different teams and individuals own are important. Beyond that ownership even, people require the tools to make the decisions they own.

“A specific example: I think in sales right now there's a lot of stress that comes from trying to manage negotiations with large clients. Because there's no discounts or framework around those negotiations. And so, each seller is given a completely blank sheet of paper, when trying to define a negotiated price with a large client with very little support often because, actually, that decision lives within the team. And so, then that becomes a very stressful situation, even though we've ticked all the boxes, we've given the decision making to where the insight is. The decision-making sits within the team, the team are autonomous, not dependent on leadership to move forwards. But it becomes a very stressful and difficult situation because there isn't a framework in place to make that decision. Now, arguably, an agile team could build that framework themselves. But then this is part of the challenge of moving from a non-agile structure to an agile structure or to a flat hierarchy and to agile teams, that people aren't going to be by default thinking, hey, that's something we can solve ourselves.” Interviewee 17 – Leadership

Although a pricing model at Funnel does exist, there are a large number of variables to consider, making a clear decision difficult. This exemplifies how too little governance can be just as limiting as too much governance. In this sense, structure and governance can be autonomy enabling rather than autonomy reducing.

4.4.7. Cross-Departmental Alignment, KPIs and Strategy

Cross-departmental and cross-functional teams spontaneously forming was one of the expected approaches to sharing knowledge and solving complex problems. This comes with three challenges that were raised in the interviews. First, the assumption of people being aware of what others are working on to be able to comment and offer support. Second, knowing how different teams’ activities relate in driving business value. Third, collaboration being an assumed competency.

Within teams, the awareness of work in progress is actively solved through the use of Kanban boards and daily stand-ups. The Kanban boards are technically accessible to the entire organization, but practically do see little use beyond the teams themselves. A weekly meeting that the whole organization attends is used to disseminate information on what each team is working on. As the number of teams and the number of projects each team is working on increases, the decentral approach to decision making comes into conflict with the amount of information people need to keep track of. That approach is predicated on decision-makers having the largest amount of available information for the problem they are to decide on. Not all of that information resides within the teams and keeping track of every team’s activity is impossible. It follows, that a guide for individuals on the organizational direction is needed. Qumer et al. call this the ‘Business-Agile Alignment Bridge’. One approach proposed but executed only partially within Funnel is that of key performance indicators (KPIs) for each team

43 being unified into a KPI tree that establishes the relationships between the performance indicators for the team. The concern voiced over this is that it might be a governance method that while creating accountability and driving business value, does not evolve and is more heavy and cumbersome governance than necessary for many of the other agile practices.

Apart from KPIs serving as a tool for inter-departmental alignment, setting strategic goals and a vision for the organization is another approach being discussed. The impact of a vision on the adoption of agile and the use of agile methods will be discussed in the next section on the method core.

4.5. Methods core

The method core in the Agile Adoption and Improvement Framework (AAIM) by Qumer et al. is supposed to provide a vision guiding model using the five aspects of Agility, People, Process, Product, Tools to develop a methodology using methods engineering. This strongly deviates from the interviews and observations at Funnel. Because the adoption was taking place in a commercial and not a development organization the existing frameworks for methods engineering do not apply. Qumer et al. emphasize the abstraction mechanisms in the software, the registry and other aspects that cannot be translated to other roles in the.

The teams instead chose an approach of introducing new processes and changes that were compatible with existing ways of working, like Kanban boards and added new processes that improved collaboration like the daily stand-ups and retrospectives. Regular coaching is another change is part of the idea of helping people improve but is only partially related to an agile way of working. The biggest change then, for the commercial organization, took place outside the methods, even though new ways of working were introduced, but took place in the different governance and increased autonomy. This different governance nonetheless seems to require a guiding vision for people to work towards.

4.6. Organizational Values and Critical Enablers

This section explores the emergence of organizational culture and competing values as a key enabling factor at Funnel. Other factors are identified in the literature. Conforto et al. list more than 14 different enablers, but the difference in organizational culture in the commercial teams is the one pivotal factor that emerged from the interviews. The following section analyses organizational culture as it relates to hierarchy and how underlying assumptions are left unexplored to the detriment of the adoption process. The analysis draws heavily on Iivari’s framework explained in the section on theoretical concepts.

4.6.1. Hierarchies and Differing Competitive Values

Decentral decision making and empowerment of teams and individuals were brought up several times already. It comes into play when leadership relinquishes control, developing strategic objectives and the setting of expectations. This makes it relevant to look at implicit and explicit hierarchies at Funnel and how they, together with the organizational culture, affect the adoption of agile methods. The Agile Solution Framework (ASF) by Qumer et al. does not discuss hierarchies and organizational logic. Because of that, the competing values framework by Iivari

44 is applied to fill this gap. The interviews surfaced that different parts of the organization reflect the organizational culture types of the framework to varying degrees. Depending on the context, a single team might even apply different cultural values depending on the context. This means that the following categorizations are bounded.

At Funnel, the customer success team in Stockholm has an external focus through regular customer interaction. It leans towards what Iivari calls group culture, though, where trust and participation play a central role for the team. When asked about what enabling factors are crucial to their way of working team members responded primarily with trust as the key condition. As this excerpt exemplifies:

“I think a lot was down to the trust again. I think that's a difficult thing to obtain. The thing is this trust must exist, from top to bottom in the company. So, in my opinion, you have to buy into a few basic assumptions of people, leadership and humanity in a way. If you don't buy into those you're not going to buy into this agile way of working.” Interviewee 14 – Customer Success

By contrast, the sales and operations teams have been focused more on goal achievement, productivity and efficiency. Leaning towards what Iivari classified as rational culture. This shows, for example, in the focus on closing deals, measuring the deal value, minimizing the time spent closing a deal, improving the conversion rate from a sales opportunity to a customer or improving processes and structures.

“But as operations as a team in general, we’re trying to be very deliberate, were to take the best bits of what we’ve seen or done in my previous experience that will help us overcome these hurdles to being agile and these hurdles to being more efficient and effective. Trying to bring those into the organization. […] So, whenever operations does get involved, which we will often, we will always be trying to bring people towards that structure to enable autonomy, as opposed to unbound autonomy, which I think people default to when they think about agile.” – Interviewee 18

Both examples show how the cultural focus is a different one for the respective teams, but that these teams see this focus on trust or structure to be in service of agile ways of working, rather than opposed to it. Looking at the Boston based teams, some components of a hierarchical culture are more readily apparent. A stronger focus is placed on fast decision making aided by authority clear lines of reporting and career development that can be signaled through job titles. This may also be due to the fact, that there are less options for personal development in the Boston office compared to Stockholm. As one interviewee from the US highlights, hierarchical thinking does not dominate interactions, but certainly plays a role.

“Collaboration is very big, and I think we try to embody the Funnel culture of always ’we’ before ’I’ working with each other and coming to a consensus. But I feel like sometimes it bottlenecks us when it's too much of a democracy. And in that aspect, you're not able to accomplish as much as needed. So, I think in the American culture, we're very used to structure and standardized practices of almost being guided and led towards it.” Interviewee 5 – US Organization

The same interviewee raises the difficulty the teams in the Boston office find themselves in when adopting new methods. Other cultural examples, such as the development organization that is based in Stockholm and works with agile methods, are less visible.

“I do agree that sometimes we get in a very commercial mindset, and there's methodologies that work, obviously, and we can be influenced by those. But if we're not around it [the methodologies] and we don't see it, and none of us come from a development background there's not really many ways we can get it [an understanding of agile methods]. Obviously, it's no excuse but even when I come here, even just being able to talk to you guys [in Stockholm]. Seeing the boards up and how everyone's talking in little groups, it does ignite some level of cooperation that I tend to lack in the US sometimes when it does become too hierarchical.” Interviewee 5 – US Organization

Whether these cultural features arise from the organizational culture in the corporate US shall not be explored here. The stronger focus on hierarchy does serve a concrete need for navigating the organizations requirements in the US, though. The promise of visible career development, argue people in the organization, helps attract and retain talent by providing a new roles, responsibilities, job titles and opportunities to personally develop. All of which are important in the American corporate landscape broadly and to individuals specifically. These different hierarchical levels are further perceived to be a necessary tool for solving issues in customer interactions by providing a means to ‘escalate’ conversations to the next hierarchy level. It is important to stress at this point, that a developmental culture is neither better nor worse than a hierarchical one and that each come with inherent contradictions. It is the fact that Funnel, as an organization, strives to adopt agile ways of working in the commercial organization that makes some competing values more relevant than others. This creates pressure to move away from hierarchical approaches because of their incompatibility with the agile methods.

This brings with it several possible sources of friction that could be discerned in the interviews. These are a mismatch between hierarchies and agile methods, and structural, organizational alignment between two offices which lead to communication and collaboration barriers. Firstly, as Iivari and Iivari argue there is an inherent mismatch between a hierarchical orientation and agile methods: “The current understanding [is] that agile methods are most incompatible with the hierarchical culture orientation. […] When compared with ad hoc development, each culture orientation favors agile methods but only up to some point in the case of rational, group, and development culture orientations. Furthermore, one can conjecture that the more formalized an agile method becomes, the sooner it will be considered dysfunctional in organizations with strong developmental culture.” (Iivari and Iivari, 2011). This means that parts of the organization at Funnel with the strongest developmental culture can struggle to see the same benefits of the hierarchical culture as each argue from different basic assumptions. Secondly, as the two offices develop so do different cultural norms and organizational structures such as new roles and titles. Over time this has led to some dissatisfaction and could continue to do so. Thirdly, these different ways of working can then lead to difficulties collaborating across offices since expectations on what role authority figures, titles and seniority play, differ. This study identifies a divide, which will be explored in the next section.

Given that a developmental culture is a core enabler of agile methods, a conscious focus on developing such a culture is needed. Other value elements should remain. But the teams with a stronger rational culture will need to assess their development differently than a group culture or a hierarchical culture will. The sales teams face different questions when reviewing their cultural values than the customer success team does. While the sales teams, given a stronger rational culture, focus more on building trust and participation, the customer success teams, given their stronger group culture, focus more on efficiency and goal attainment.

4.6.2. Explicit and Implicit Organizational Culture

As the previous section has shown, in line with the literature on agile enablers, the organizational structure type and organizational culture are crucial in enabling agile methods. Using Iivari’s framework group culture, rational culture and aspects of hierarchical culture were identified in parts of the commercial organization, along with the need to use different approaches for each of these cultures when moving in the direction of a developmental organization. This section will analyze whether these differences have been identified internally and what factors help or hinder individuals in the organization from making this assessment. Here Schein’s distinction of organizational culture into three levels provides a helpful framing for distinguishing different aspects of the culture. According to Schein on the surface, cultural artifacts are visible and observable although difficult to interpret. Below that lie the espoused values and beliefs which include ideals, values, aspirations and goals. This is the level that the competing values framework focuses on. These ideologies and rationalizations are not necessarily in line with the surface level artifacts. The most basic level below the espoused beliefs and values is made up of unconscious beliefs and values that are taken for granted and influence the behavior by far the most (Schein, 2010). This three-layered categorization, similar to other cognitive models of core beliefs, underlying assumptions and automatic thoughts (de Oliveira, 2012) is used to distinguish cultural features at Funnel.

The adoption of agile methods introduced several new artifacts into the commercial organization. Examples range from new types of meetings like the stand-up or retrospective to linguistic artifacts such as phrases like “iterate and learn”. This adoption of artifacts becomes problematic when it is mistaken for the adoption of the underlying values necessary for meaningful adoption of agile ways of working. When used in this way, adopted artifacts standing in for a change in values, the process of adopting agile ways of working is perceived as transactional and communication becomes more difficult as the shared underlying assumptions vary.

“It’s more of we would love to just feel a little bit… we accept a lot of cultural things and this agile mindset, and it means something different to a lot of different people. As a company I think it's a great concept but in some cultural things we'd love for it to lean a little more center, instead of the US one accepting more and more in that structure, like the meetings we talked about.” Interviewee 10 - US Organization

The statement above shows this transactional understanding of the adoption of methods. This, in turn, means that when the change towards agile ways of working was initiated, the common espoused beliefs and values were assumed to be more unified than was actually the case. The question then arises if there is an awareness of the importance of underlying assumptions and their impact on culture. This is undoubtedly the case. Interviewee 15 makes this clear but implies that these unconscious assumptions are shared and understood throughout the rest of the organization. The competing values in different parts of the commercial organization explored in the previous section show that this is not the case.

“If you join this company as a bit more senior person, then I think it's hard to navigate and adapt because there are invisible barriers. You do something, and then all of a sudden you did

something wrong, but you had no idea you were not supposed to do that. No one told you. And, you only saw the bullet points on the culture slide deck and then heard people talk about it but that is a bit too blurry. And we have to fix that.” Interviewee 15

In implementing agile methods, organizational culture plays an important role in enabling the transition. The focus on the adoption of agile methods at Funnel is predicated on the assumption of a unified set of beliefs, values and underlying assumptions. Throughout the adoption process, a need to reengage with the espoused beliefs has been identified to be crucial. But the already adopted artifacts (structures and processes) make this conversation more difficult because it is difficult to separate them from the values. The competitive values framework provides two useful dimensions along which culture can be spread out, external and internal focus as well as change or stability. What the framework highlights in particular is how even subtle differences in culture affect the priorities of teams and how they are the source of potential friction.

4.6.3. Moving too fast – Agile Fatigue

There is a central contradiction with the implementation of agile methods that Iivari and Iivari had identified: “There may be a paradox between the hierarchical culture and the developmental culture if the goal is faithful enactment of methods. In organizations with a strong hierarchical culture, SDMs are made more mandatory than in organizations with a strong developmental culture (implying a weaker hierarchical culture). Yet, less mandatory methods may be more effectively enacted in organizations with a strong hierarchical culture than in organizations with a strong developmental culture, because the desired behavior will be followed more faithfully in the former case than in the latter case where we expect more method improvisation.” (Iivari and Iivari, 2011). Using the developmental culture approach to implement agile methods taken at Funnel appears slow and ineffective to the parts of the organization used to more hierarchical ways of working. The repeated discussion and belaboring of the values around agile necessary for the ‘slow’ developmental approach has another consequence, not acknowledged by other literature on the topic: It is fatiguing. People within the commercial organization at Funnel are repeatedly engaged in discussions on the topic of agile ways of working. For the adoption process to feel fruitful, successes must be observed as a consequence of the new ways of working. John Kotter referred to “systematically planning for and creating short-term wins”(Kotter, 2012) as a crucial success factor in an organizational transformation. Interviewees pointed to some of these ‘short-term wins’, especially in the area of improved collaboration which has led to great satisfaction.

Commercial teams need a different way of formalizing agile methods. This formalization may then be judged or perceived to be judged to be dysfunctional, by other parts of the organization. This perceived judgement can be especially detrimental between the two offices. The office in Boston faces a different corporate and cultural environment than the Stockholm office does and the commercial organization in both offices have different interactions than the development organization. As the interview excerpts above show, not accounting for these differences can be frustrating to people in the commercial teams. The commercial organization, especially in Boston, is being perceived negatively due to the slightly more hierarchical organizational values. Even though this is changing, this image can persist and make the bi-directional exchange of learnings difficult. One person from the sales organization in Boston notes:

“I think a goal of ours is we've been doing this for three months now on the sales side where the Stockholm sales team is fairly new [to agile] and so let’s take some of the stuff that Boston has been doing and we can try to implement it in the in Stockholm office and reverse that flow of that information and make it more of a cyclical thing. Let's try some of the things that we've been doing over here [in Boston]. Because a lot of it's always been like, oh ‘How does Stockholm do this?’ so that we can do it over here. It's never been ’How does Boston do this?’ so we can do it in Stockholm. When there was five or six of us, we didn't really have that much pull, but now there's 30 of us we do have some gravitational pull where it could go back a little bit.” Interviewee 19 – US Organization

4.7. Interactions - Knowledge, Governance, Culture & Enablers

Having looked at different parts of Qumer’s framework mostly independently, this section will take a holistic perspective. In the case of Funnels commercial teams, the challenges with the adoption of agile methods are much more heavily focused on sharing knowledge and the governance implications than the actual methods themselves. Agile methods are, in this sense, not the methods that need to be ‘enabled’ by a set of ‘enabling factors’. Rather, the challenges the commercial teams face should be seen as one problem. What Conforto et al. call enabling factors are at the core of the agile adoption process, not a precursor that stands separately from them.

When the customer success teams created separate and specialized teams that required new ways of transferring knowledge and more deliberate methods for collaboration, cross-functional teams were the response to the challenge of solving complex problems. This, in turn, required more visibility for task visibility and collaboration. A method, in this case, Kanban boards, created that visibility.

The sales teams, working on larger deals needed to collaborate more, this was hindered by the governance structure because of the commission-based compensation structure. Giving up that structure was followed by the formation of self-organizing sales-pods. The self-organizing nature of these new teams made it less clear where responsibilities lie and what initiatives teams should be working on. Defining the responsibilities loosely is a response to the need to adapt to changing circumstance. This way, teams will take on new responsibilities as they arise, not just what has been assigned to them. As a consequence, holding people accountable for loosely defined expectations or unclear ownership is more difficult, and the uncertainty that arises through this environment is challenging for individuals. One way this is being solved by some teams at Funnel is by collaboratively defining strategic drivers for the teams. How the strategic direction is expected to be developed, however, depends on the variation in organizational culture in different parts of the organization. At Funnel, a unity in the organizational culture was assumed at the beginning of these initiatives. The empirical material shows that this is not the case, although a great set of common underlying assumptions are shared throughout, different contexts have resulted in variation between teams and offices. The overall reaction to the new ways of working is exceptionally positive. Wherever the underlying assumptions and values differ, though, this has led to misunderstandings on both sides. This in turn, causes frustration with some of the approaches chosen. While these challenges make the adoption process sound as if it were fraught with challenges, the overall results and feedback have been very positive.

5. Discussion and Conclusion

Here the empirical material and analysis will revisit the research questions posed at the beginning of the study. How agile practices provide advantages or disadvantages to non- software teams, both direct and indirect, what factors are necessary to enable the adoption of these methods and what challenges non-commercial teams face in the process.

5.1. Enabling Agile Adoption – An Illusory Category

RQ1. How do enabling factors affect the successful adoption of agile practices in non-software functions of a software organization?

The central finding in analyzing the case of the adoption of agile methods in Funnels commercial division was the circular dependence of the enabling factors. Enablers for agile methods are defined in the literature as “internal or external factors to the organization that are directly or indirectly related with the implementation of the agile management approach that impact the performance and use of a given practice, technique or tool” (Conforto et al., 2014). This definition implies that the high performance of a given practice, technique or tool is the desired outcome of implementing agile ways of working. When, in fact, the goals of the organization are clearly business driven. Agile practices are a means to an end, not an end in themselves. The focus on agile enablers is problematic because it, like much of the research on agile practices, lays focus on the finding ways to enable the agile practice rather than solving the fundamental problem. This may sound like mere semantics, but it is of vital importance for an organization to view the organizational culture or multidisciplinary teams as being enabled by agile practices, rather than the other way around. The distinction into enabling factors and enabled practices is a false dichotomy, that is in many respects misleading. There is a risk of directing energy towards enabling practices for their own sake, rather than trying to find fitting ways to engage with the fundamental problem the organization is facing.

That said, the efforts that were found to be crucial and preceded the agile implementation revolved around governance and knowledge sharing issues. These will be discussed in RQ 2 in more detail. First, a development organization already using agile ways of working and thereby having an organizational culture open to change and experimentation was mostly beneficial. At Funnel, the culture was already impacted by agile values. By having to adapt to the constant delivery pace of the development organization, the commercial teams were aligned with many of the values much more closely than they otherwise would be. This exposure kickstarted the adoption process and had created a commercial organization that was very different from what would be regarded as a ‘traditional’ commercial organization. Second, a strong focus on hiring people who fit the existing organizational culture. As was emphasized in almost every interview, the focus on skills and cultural fit in the hiring process made it possible for team leaders to trust their team with autonomy and possible for colleagues to trust one another. Third, changing the compensation structure to encourage cooperation. The dominant way in which commercial teams are compensated makes collaboration difficult. Switching to a new model helped new practices to be explored. At the same time, this experiment with the new compensation model is enabled by the promise of agile ways of working improving the overall output of the collaborative teams. Without the increased creation of business value, driven by creating customer value, a change in compensation structure would be unsustainable. Here the

50 interdependence of the enablers and the practices shows itself again. Fourth, the strong support by members of the organizational leadership in the adoption of agile methods was important. Some of that support was not present at the start. It had to develop over time and was helped by the success of the new ways of working.

5.2. Constant Collaboration – Advantages of Agile Teams

The by far biggest advantage from adopting these practices was improved collaboration between teams and individuals. The advantages of not having a commission-based compensation for the sales teams and the formation of new teams paired with new practices led to more information being shared and a level of teamwork being introduced that did not exist previously. This came as a result of the new compensation model and team division being in line with the natural disposition of the employees to collaborate. On the flipside, the need for some contribution- based form of recognition and career development persists. New ways of rewarding excellent work will need to be developed, if talented individuals are to be retained.

Another benefit for people in the commercial teams has been higher satisfaction with the way work is being done. For the sales teams, the new structure has reduced some of the stress about potentially missing sales targets and the customer success teams are able to build deeper expertise and deliver customer value through specialization. Both of these actions (dropping commissions and re-organizing teams) do not rely on agile methods. But these actions alone do provide little benefit; it is in conjunction with agile ways of working that these benefits are reaped. The dialog about the ways of working has opened up more considerations for interaction with the development organization. The autonomy of the individual members of the organization means that people in leadership positions need not drive these initiatives.

Uncertainty still remains in some areas, and the introduction of agile methods has accelerated how acutely unclear expectations are being felt. An indirect disadvantage that arises from the agile methods is how they raised the need to invest more heavily in training, to make autonomy these methods rely on possible. In addition, the new ways of working are forcing members of the organization to engage with difficult topics, such as differences in cultural values or how to handle hierarchies. Because of the intercedence of the agile practices and what in the literature have been called enablers the organization needs to take an active approach in many of previously less consequential topics, for instance actively engaging in questions of governance and accountability in teams. The effect this has on the commercial organization is that it must expend additional effort in solving challenges. This may also be an indirect benefit for the organization, though. Training and coaching that may otherwise not have happened are being held. The more active engagement in thinking about how to collaborate and work more effectively results in an increasing awareness throughout the commercial teams in how to adapt to changing circumstances. For instance, sharing more of the same vocabulary with the development organization and the confidence of working in an agile way resulted in an increase in cross-departmental collaboration and experimentation with new ways of working – this benefit compounds over time. The distinction of advantages and disadvantages, therefore, depends on the view taken by the business. In a ‘traditional’ cost and efficiency-driven

51 organization, the increased effort the agile ways of working entail could be squarely regarded as a disadvantage. In the complex environment that agile ways of working are predicated on, or rather to which these methods are a response, these ‘disadvantages’ are beneficial, in so far as the organization actively engages with them. By doing so, Funnel builds familiarity with change and tackling difficult organizational issues that make it more resilient in the face of other external change.

5.3. Finding a North Star – Challenges of Agile Adoption

RQ3. What challenges do non-software functions face when adopting agile ways of working?

The central challenge that came up was that of developing a shared vision of what agile adoption in the commercial organization would look like and developing a strong reason for the change. In essence, this meant being able to answer the question: “Why are we adopting agile practices?”. The reason this turned out to be so crucial was that many other challenges relate to it. The first challenge related to understanding the ‘Why’ is that it makes it necessary to agree on the underlying agile values. Aligning the values across the organization makes it possible for each team to adopt the methods that suit them for their work. The second challenge related to understanding the ‘Why’ then is selecting the methods, the commercial teams want to implement. Not knowing what the teams are trying to achieve makes such a selection difficult. When these methods are then adopted to fit the purpose of the team, having articulated aligned on the values and the reason for adopting them, the methods can be adapted accordingly.

The second major challenge is the distinction between agile practices useful for development functions and those for non-software functions. The somewhat obvious insight is “We can’t adopt everything from Dev.”, as one member of the commercial team put it. Many, if not most, of the agile practices, come from a development environment and have assumptions from this background built in. The commercial teams need to agree on what their equivalent of ‘working software’ is, for example. This leaves room for interpretation that can – together with the autonomy that the agile ways of working entail – lead to teams pulling in different directions, making the need for aligned values and a shared vision all the more pressing. Besides more fuzzy definitions of success or ‘working software’, the non-software functions face different external expectations. The customer success team is responsible for helping customers and is expected to respond to requests in a timely manner. This makes the use of a tool like Kanban, that are based on a pull system difficult. Customer success and other commercial teams have to be reactive rather than proactive on a much shorter time frame than developers do, even if these value changing requirements. Agile methods can still add value to non-software teams, but rather that the differences between software development and commercial functions must be felt to be acknowledged, lest it led to frustration. The challenge for the non-software function is that their differing needs must be taken seriously. This is especially true, in conversations with people from the development organization, who are more familiar with agile methods but less familiar with the commercial context. A third and related challenge is the difference between people from development and commercial teams. These two groups seem to be to a degree self- selecting and are used to different forms of learning. Much of the more abstract and conceptual presentation of agile methods and agile ways of working resonates less well than application- based introductions of the same methods. Constant conversations on the topic of ‘Agile’ lead to fatigue in the discussion. The difference in approaches to solving problems between software and commercial teams could be reflected here, but more research is needed to make this point.

The fourth set of challenges that were most extensively explored in the analysis are those of governance. Team leaders giving up control to their teams was less of a hurdle, thanks in large part to good hiring practice and comparatively high autonomy of individuals at the start of the adoption process. Giving up control is also made possible by the role of leaders not being threatened, i.e. they will still have a job. What did become a challenge, though, is scoping the work of the more autonomous agents towards shared strategic objectives and having to find a way to align people across teams. This also relates to the difficulty of creating accountability, if traditional individual performance tracking cannot be employed anymore because work is now done collaboratively. Funnel faces the challenge of finding a way to set clear expectations and resolving questions of unclear ownership in the commercial teams without limiting people too much. As the analysis showed, the unclear ownership and lack of structure that accompanies the changing environment can make autonomy just as much a challenge as it is an opportunity.

Lastly, the adoption process raises the question to what extent the two offices (Stockholm and Boston) are required to follow the same model of organizing and if so, how to reconcile differing ambitions and values. In part, this has been the result of different external requirements and expectations, but ultimately slight differences in values and tendencies towards a more hierarchical or egalitarian way of working were brought up through the agile adoption.

5.4. COVID 19: Remote Work, Unexpected Pivots and Exaptation

With the outbreak of the COVID 19 pandemic the company decided to continue work from home at the beginning of March 2020. The pivot to working entirely remotely happened from one week to the next and had many implications for how work needed to change, affecting the newly introduced agile methods too. This is meaningful broadly because it provides a useful example of how organizational challenges broadly can lead to unexpected future benefit.

The existing two offices in different countries have, throughout this study, been discussed as a challenge in terms of communication and the slightly differing cultural values. Under ordinary circumstances, this would have led to the conclusion that having a presence in multiple locations is necessary for handling customers in those regions but also adds some friction because of the long-distance interaction. By forcing people to work from home the pandemic introduced the same challenges of remote interaction usually seen between offices to every interaction within the company. Funnel had tackled many of the challenges of remote collaboration when connecting the two offices. The infrastructure and software tools for remote collaboration and the culture to use them where, therefore, already in place. Stephen Jay Gould’s term exaptation, “features that now enhance fitness but were not built by for their current role” (Gould and Vrba, 1982) describes this process best. The company was ‘practicing’ change, for lack of a better term, by changing how people work, by forming new teams and introducing new processes. All because the company was going through the process of adopting agile processes ways of working.

Throughout this study, the implementation of agile methods has treated the issue of agile adoption, as a problem of adaptation. Organizational features, processes and tools were changed to perform specific functions. In the wake of the pandemic, it appears that some humility is on order, as the company benefits more from exaptation than adaptation.

That adaptation should continue though, and some issues remain unsolved. Many of the agile values, such as focusing on face-to-face communication have been difficult to enact. Similarly, the number of serendipitous micro-interactions at the office has dropped. Funnel continues to grapple with these issues in a productive way. As the sudden change in the environment has shown, it allowed the organization to adapt quickly. Given that new challenges and changes in the environment are bound to arise the adaptation of agile methods is a continuous process.

The implication this has for organizations and research in the field of industrial engineering is that present day challenges have the potential to provide unexpected future benefit. This in turn means that an organizations capability may be systematically undervalued because their ‘exaptive potential’ is not taken into account. The example of how Funnel reacted to remote work is just one such example.

5.5. Connecting the Dots – Conclusions from the Research

Beginning to adopt agile ways of working has resulted in many positive changes for the non- software functions at Funnel. Chief among them better collaboration across the entire organization and a more deliberate approach to improving the way work is being taken. People have been very positive about the changes made to the organization so far and continue to adapt new ways of working.

The distinction between agile practices and agile enablers (RQ1), this study argues, is a misleading one because of their reciprocal dependence. Agile methods enable different forms of organizational governance just as much as governance enables those same agile methods. Identifying ‘success factors’ of one sort or another has, therefore been shown to be misleading. Funnel is looking to organize in a more effective way, and to respond to the organizational environment. Some agile methods enable these new forms of organizing and are ultimately a tool to create more customer and business value and create a more resilient organization.

The introduction of agile methods had direct benefits for Funnel through the direct use of the practices. On a higher level, the change-process due to agile adoption acts as a catalyst for Funnel to engage with challenges that would remain dormant otherwise. This makes the organization more prepared for change generally and increases the exaptive potential, similar to how the remote collaboration between two offices coincidentally prepared Funnel for working remotely during the COVID-19 pandemic.

Funnel has made progress since the first ideas implementing agile methods more widely in September 2019. Particularly in changing the way of working with many agile practices being used successfully by commercial teams. This new approach has also created or exposed new problems that are actively being engaged with. The most important of these is developing and communicating a clear vision and reason for adopting agile practices and agreeing on what values are shared throughout the commercial and development organization.

5.6. Implications for Future Research

The findings of this study have several implications for research on agile adoption. Research on the topic of agile adoption is heavily focused on software development teams alone. The first implication this overemphasis has is that software development functions in isolation and is independent from non-software or commercial activity. As the example of Funnel shows, the delivery of value to customers relies on all parts of the commercial organization. In the same vein, since the commercial teams have most of the customer interaction, it is this part of the organization that collects and passes on customer feedback to the development function. Two of the central tenants of the agile manifesto – customer collaboration and continuous delivery of value to the customer – are therefore only made possible by non-software teams. The literature on the topic does not reflect this reality and may point to a fundamental misunderstanding of the nature of software organizations. In so far as non-software teams are discussed, it is as blockers to the agile adoption process in the software teams (Dikert et al., 2016). Or agile adoption is with respect to project management entirely outside of software organizations. That often means assuming a complete unfamiliarity with agile ways of working and a ‘traditionally’ structured organization that is fundamentally at odds with adoption agile practices. This oversight of agile research, either focusing solely on software teams or on completely different industries other than software is particularly striking because it is non- software teams in software companies that promise to derive the biggest benefit while simultaneously likely being more able to adopt these practices. The non-software teams are promising to derive benefit from it because of their necessary interaction with the software teams. Being able to match their ways of working and collaborate more effectively, as is the case at Funnel, is beneficial to both parts of the organization. And they are likely more able to adopt agile practices because they are part of the same organizational culture that has allowed the software teams to adopt agile methods in the first place, implying at the very least some fundamental compatibility. Additionally, being exposed to how the development function works and the methods employed gives non-software teams a very basic understanding of what these methods look like in practice. This study contributes to the field of agile research by highlighting this oversight and providing a case example for how the adoption of agile methods by non- software teams benefits both development and non-software teams.

The second implication this study has for the field of research is in regard to the distinction of enabling factors as being separate from methods. The studies by Conforto et al., Dikert et al. and O’Connor reference in the theory section all point to the success factors and agile enablers as a distinct category of their own. As RQ1 has shown this distinction is illusory and misleading. Taking a more holistic and connectionist view, as suggested by Cilliers, can provide a richer understanding of how the collection of values and methods labelled ‘agile’ contribute to the success of organizations. That may be by the value they are stated to provide or by themselves enabling new forms of organizing better fit for organizations operating in a complex environment.

The third issue this research raises is much connected to the second and the holistic understanding of agile ways of working. This study has shown how the effort involved in adopting new methods and engaging in the challenges that these methods expose may itself be beneficial. By having to engage in this challenge organizations adopting agile methods become more used to a changing environment can develop resilience as a consequence. Nassim Taleb’s

55 concept of antifragility comes to mind: “Some things benefit from shocks; they thrive and grow when exposed to volatility, randomness, disorder, and stressors and love adventure, risk, and uncertainty.” (Taleb, 2012). By creating an organization with a bigger exaptive potential adopting agile methods could be a step in the direction to create an antifragile organization. The question this raises for future research is whether it is the agile methods themselves that create this resilience or the process of self-examination and change they force upon an organization. At first sight, this distinction appears to be inconsequential, but only as long as the method adoption and the corresponding change the adoption requires remain unified. The implication is that attempts by research to separate the adoption of agile methods from the need for an organization to go through one or more periods of major change will bear little or no success.

5.7. Ethical and societal implications

The values and principles that stand at the heart of agile methods and practices are acknowledged human shortcomings and the difficulty that comes with traditional ways of organizing. Agile practices, therefore, emphasize the need to provide individuals with adequate tools and an environment in which they feel safe to fail and learn. Traditional ways of organizing can, by comparison, seem like a procrustean bed. Based on these considerations, more widespread adoption of agile ways of working is desirable and would have a beneficial societal impact. Further, as this study has argued, the adoption of agile practices makes an organization more resilient. By doing so, it creates more stability and success for these organizations and the systems of which they are a part. Insofar as this study has contributed to the understanding, that agile ways of working do not need to be confined to software development, it has had a positive impact.

The implementation of agile methods is frequently understood as an easy way of increasing delivery or operational speed within an organization, without having to renegotiate how authority, decision-making and accountability shall be addressed. In essence, the underlying idea is to squeeze out ever-greater returns from the same pool of ‘human resources’. This study hopes to have shown that agile practices and their benefits do not lie only with the methods themselves but with the engagement that comes from going through the process of adoption. It has, moreover, shown that agile methods are arguably indistinguishable from their enabling factors. This implies that a misuse of agile methods that disregards the humanist component mentioned above is futile and destined to be unsuccessful.

This study started out with laying out the complexity paradigm and the realization that new and different approaches are needed to solve complex problems. The approach that agile methods provide is a very positive one for tackling these kinds of challenges. Given the rise in complexity, interconnectedness and non-linear behavior of the environment this new approach is needed more than ever. Agile methods provide a variety of practices that help put into practice the probe-sense-respond approach for dealing with complex problems. This approach is what will help solve the most difficult problem our society faces today and move in the right direction one small iteration at a time.

In 2019 Uppsala University hung up a poster for Upptech that read: “Grand challenges need grand solutions”. Maybe that is the wrong way to see these challenges, maybe that sign should have read “Grand challenges need to be tackled one small step at a time.”

References

Abrahamsson, P., Warsta, J., Siponen, M.T., Ronkainen, J., 2003. New directions on agile methods: a comparative analysis, in: 25th International Conference on Software Engineering, 2003. Proceedings. Ieee, pp. 244–254. Appelo, J., 2012. How to change the world: Change management 3.0. Jojo Ventures BV. Appelo, J., 2011. Management 3.0: leading Agile developers, developing Agile leaders, The Addison-Wesley signature series. Addison-Wesley, Upper Saddle River, NJ. Ashby, W.R., 1961. An Introduction to Cybernetics. Chapman & Hall Ltd. Bakalova, Z., Daneva, M., Herrmann, A., Wieringa, R., 2011. Agile Requirements Prioritization: What Happens in Practice and What Is Described in Literature, in: Berry, D., Franch, X. (Eds.), Requirements Engineering: Foundation for Software Quality, Lecture Notes in Computer Science. Springer Berlin Heidelberg, Berlin, Heidelberg, pp. 181–195. https://doi.org/10.1007/978-3-642-19858-8_18 Beck, K., 2000. extreme programming eXplained: embrace change. Addison-Wesley, Reading, MA. Beck, K., Beedle, M., van Bennekum, A., Cockburn, A., Cunningham, W., Fowler, M., Grenning, J., Highsmith, J., Hunt, A., Jeffries, R., Kern, J., Marick, B., Martin, R.C., Mellor, S., Schwaber, K., Sutherland, J., Thomas, D., 2001. Manifesto for Agile Software Development. Blank, S., 2013. Why the lean start-up changes everything. Harv. Bus. Rev. Booch, G., 1991. Object oriented design with applications, Benjamin/Cummings series in Ada and software engineering. Benjamin/Cummings Pub. Co, Redwood City, Calif. Bryman, A., Bell, E., 2011. Business research methods, 3rd ed. ed. Oxford University Press, Cambridge ; New York, NY. Carbonell, P., Rodríguez-Escudero, A.I., Pujari, D., 2009. Customer Involvement in New Service Development: An Examination of Antecedents and Outcomes. J. Prod. Innov. Manag. 26, 536–550. https://doi.org/10.1111/j.1540-5885.2009.00679.x Cilliers, P., 2002. Complexity and postmodernism understanding complex systems. Routledge, London; New York. Cockburn, A., 2008. Using both incremental and iterative development. STSC CrossTalk USAF Softw. Technol. Support Cent. 21, 27–30. Cohn, M., 2004. User stories applied: for agile software development, Addison-Wesley signature series. Addison-Wesley, Boston.

Conboy, K., Fitzgerald, B., 2010. Method and developer characteristics for effective agile method tailoring: A study of XP expert opinion. ACM Trans. Softw. Eng. Methodol. 20, 1–30. https://doi.org/10.1145/1767751.1767753 Conforto, E.C., Salum, F., Amaral, D.C., da Silva, S.L., de Almeida, L.F.M., 2014. Can Agile Project Management be Adopted by Industries Other than Software Development? Proj. Manag. J. 45, 21–34. https://doi.org/10.1002/pmj.21410 Conway, M.E., 1968. How do committees invent. Datamation 14, 28–31. de Oliveira, I.R., 2012. Assessing and Restructuring Dysfunctional Cognitions, in: De Oliveira, I.R. (Ed.), Standard and Innovative Strategies in Cognitive Behavior Therapy. InTech. https://doi.org/10.5772/38995 Derby, E., Larsen, D., 2006. Agile retrospectives: making good teams great. Pragmatic Bookshelf, Raleigh, NC. Dikert, K., Paasivaara, M., Lassenius, C., 2016. Challenges and success factors for large-scale agile transformations: A systematic literature review. J. Syst. Softw. 119, 87–108. https://doi.org/10.1016/j.jss.2016.06.013 Dougherty, D., Tolboom, J.N., 2008. Creative organizing to enable organizational creativity. Handb. Organ. Creat. 1st Edn Taylor Francis Group N. Y. 237–261. Dubois, A., Gadde, L.-E., 2002. Systematic combining: an abductive approach to case research. J. Bus. Res. 55, 553–560. https://doi.org/10.1016/S0148-2963(00)00195-8 Dybå, T., Dingsøyr, T., 2008. Empirical studies of agile software development: A systematic review. Inf. Softw. Technol. 50, 833–859. https://doi.org/10.1016/j.infsof.2008.01.006 Edmondson, A.C., 2012. Teaming: How organizations learn, innovate, and compete in the knowledge economy. John Wiley & Sons. Esfahani, H.C., Yu, E.S.K., Annosi, M.C., 2011. Towards the Strategic Analysis of Agile Practices, in: CAiSE Forum. Evans, E., 2004. Domain-driven design: tackling complexity in the heart of software. Addison- Wesley, Boston. Fitzgerald, B., Russo, N., O’Kane, T., 2000. An Empirical Study of System Development Method Tailoring. pp. 187–194. Flyvbjerg, B., 2006. Five Misunderstandings About Case-Study Research. Qual. Inq. 12, 219–245. https://doi.org/10.1177/1077800405284363 Funnel, 2020. Funnel [WWW Document]. Your Mark. Advert. Data You Want It. URL funnel.io (accessed 3.17.20). Gould, S.J., Vrba, E.S., 1982. Exaptation—a Missing Term in the Science of Form. Paleobiology 8, 4–15. https://doi.org/10.1017/S0094837300004310 Griffin, D., Shaw, P., Stacey, R., 1998. Speaking of Complexity in Management Theory and Practice. Organization 5, 315–339. https://doi.org/10.1177/135050849853002

Hannay, J.E., Dybå, T., Arisholm, E., Sjøberg, D.I.K., 2009. The effectiveness of pair programming: A meta-analysis. Inf. Softw. Technol. 51, 1110–1122. https://doi.org/10.1016/j.infsof.2009.02.001 Hatch, J.A., 2002. Doing qualitative research in education settings. State University of New York Press, Albany. Hiatt, J., 2006. ADKAR: a model for change in business, government, and our community, 1st ed. ed. Prosci Learning Center Publications, Loveland, Colorado. Highsmith, J.A., 2000. Adaptive software development: a collaborative approach to managing complex systems. Dorset House Pub, New York. Iivari, J., Iivari, N., 2011. The relationship between organizational culture and the deployment of agile methods. Inf. Softw. Technol. 53, 509–520. https://doi.org/10.1016/j.infsof.2010.10.008 Inayat, I., Salim, S.S., Marczak, S., Daneva, M., Shamshirband, S., 2015. A systematic literature review on agile requirements engineering practices and challenges. Comput. Hum. Behav. 51, 915–929. https://doi.org/10.1016/j.chb.2014.10.046 Jalote, P., Palit, A., Kurien, P., Peethamber, V.T., 2004. Timeboxing: a process model for iterative software development. J. Syst. Softw. 70, 117–127. https://doi.org/10.1016/S0164- 1212(03)00010-4 Kauffman, S., 2003. Molecular autonomous agents. Philos. Trans. R. Soc. Lond. Ser. Math. Phys. Eng. Sci. 361, 1089–1099. https://doi.org/10.1098/rsta.2003.1186 Koiesar, P.J., 1994. What Deming told the Japanese in 1950. Qual. Manag. J. 2, 9–24. Kotter, J.P., 2012. Leading change. Harvard business press. Kurapati, N., Manyam, V.S.C., Petersen, K., 2012. Agile Software Development Practice Adoption Survey, in: Wohlin, C. (Ed.), Agile Processes in Software Engineering and Extreme Programming. Springer Berlin Heidelberg, Berlin, Heidelberg, pp. 16–30. https://doi.org/10.1007/978-3-642-30350-0_2 Ladas, C., 2008. Scrumban: and other essays on Kanban System for Lean Software develoment. Modus Cooperandi Press, Saetle, WA. Leffingwell, D., 2007. Scaling software agility: best practices for large enterprises, The Agile software development series. Addison-Wesley, Upper Saddle River, NJ. Liu Jun, Wang Qiuzhen, Gao Lin, 2010. Application of Agile Requirement Engineering in Modest-Sized Information Systems Development, in: 2010 Second World Congress on Software Engineering. Presented at the 2010 Second World Congress on Software Engineering (WCSE 2010), IEEE, Wuhan, pp. 207–210. https://doi.org/10.1109/WCSE.2010.105

Maddox, W.T., Ing, A.D., 2005. Delayed Feedback Disrupts the Procedural-Learning System but Not the Hypothesis-Testing System in Perceptual Category Learning. J. Exp. Psychol. Learn. Mem. Cogn. 31, 100–107. https://doi.org/10.1037/0278-7393.31.1.100 Majchrzak, A., More, P.H.B., Faraj, S., 2012. Transcending Knowledge Differences in Cross- Functional Teams. Organ. Sci. 23, 951–970. https://doi.org/10.1287/orsc.1110.0677 Martin, J., 1991. Rapid application development. Macmillan Pub. Co. ; Collier Macmillan Canada ; Maxwell Macmillan International, New York : Toronto : New York. Martin, R.C., 2002. Agile software development: principles, patterns, and practices. Prentice Hall. Matthing, J., Sandén, B., Edvardsson, B., 2004. New service development: learning from and with customers. Int. J. Serv. Ind. Manag. 15, 479–498. https://doi.org/10.1108/09564230410564948 Moen, R., Norman, C., 2006. Evolution of the PDCA cycle. Citeseer. Monsell, S., 2003. Task switching. Trends Cogn. Sci. 7, 134–140. https://doi.org/10.1016/S1364- 6613(03)00028-7 O’Connor, R.V., Duchonova, N., 2014. Assessing the Value of an Agile Coach in Agile Method Adoption, in: Barafort, B., O’Connor, R.V., Poth, A., Messnarz, R. (Eds.), Systems, Software and Services Process Improvement, Communications in Computer and Information Science. Springer Berlin Heidelberg, Berlin, Heidelberg, pp. 135–146. https://doi.org/10.1007/978-3-662-43896-1_12 O’Hear, S., 2020. https://techcrunch.com/2020/01/16/funnel-series-b/. Tech Crunch. Oke, A., Idiagbon-Oke, M., 2010. Communication channels, innovation tasks and NPD project outcomes in innovation-driven horizontal networks. J. Oper. Manag. 28, 442–453. https://doi.org/10.1016/j.jom.2010.01.004 Osterwalder, A., Pigneur, Y., Bernarda, G., Smith, A., 2014. Value proposition design: How to create products and services customers want. John Wiley & Sons. Osterwalder, A., Pigneur, Y., Clark, T., 2010. Business model generation: a handbook for visionaries, game changers, and challengers. Wiley, Hoboken, NJ. Owen, R., Koskela, L., Henrich, G., Codinhoto, R., 2006. Is Agile Project Management Applicable to Construction? Proc. IGLC•14 51–66. Palmer, S.R., Felsing, J.M., 2002. A practical guide to feature-driven development, The Coad series. Prentice Hall PTR, Upper Saddle River, NJ. Petersen, K., Wohlin, C., 2009. A comparison of issues and advantages in agile and incremental development between state of the art and an industrial case. J. Syst. Softw. 82, 1479– 1490. https://doi.org/10.1016/j.jss.2009.03.036 Poppendieck, M., Poppendieck, T., 2010. Lean software development: an agile toolkit, Nachdr. ed, The agile software development series. Addison-Wesley, Boston.

Pugh, K., 2011. Lean-agile acceptance test-driven development: better software through collaboration, Net objectives lean-agile series. Addison-Wesley, Upper Saddle River, NJ. Qumer, A., 2007. Defining an Integrated Agile Governance for Large Agile Software Development Environments, in: Concas, G., Damiani, E., Scotto, M., Succi, G. (Eds.), Agile Processes in Software Engineering and Extreme Programming, Lecture Notes in Computer Science. Springer Berlin Heidelberg, Berlin, Heidelberg, pp. 157–160. https://doi.org/10.1007/978-3-540-73101-6_23 Qumer, A., Henderson-Sellers, B., 2008. A framework to support the evaluation, adoption and improvement of agile methods in practice. J. Syst. Softw. 81, 1899–1919. https://doi.org/10.1016/j.jss.2007.12.806 Rehkopf, M., 2020. Kanban Boards [WWW Document]. Atlassian. URL https://www.atlassian.com/agile/kanban/boards Rice, R.E., 1992. Task Analyzability, Use of New Media, and Effectiveness: A Multi-Site Exploration of Media Richness. Organ. Sci. 3, 475–500. https://doi.org/10.1287/orsc.3.4.475 Ries, E., 2011. The lean startup: how today’s entrepreneurs use continuous innovation to create radically successful businesses, 1st ed. ed. Crown Business, New York. Rogers, E.M., 1995. Diffusion of Innovations, 4th Edition. Free Press, New York. Schein, E.H., 2010. Organizational culture and leadership, 4th ed. ed, The Jossey-Bass business & management series. Jossey-Bass, San Francisco. Schindler, M., Eppler, M.J., 2003. Harvesting project knowledge: a review of project learning methods and success factors. Int. J. Proj. Manag. 21, 219–228. https://doi.org/10.1016/S0263-7863(02)00096-0 Schwaber, K., 2004. Agile project management with Scrum. Microsoft Press, Redmond, Wash. Schwaber, K., Sutherland, J., 2017. Scrum Guide [WWW Document]. Scrum Guide. URL https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-US.pd Sidky, A., Arthur, J., Bohner, S., 2007. A disciplined approach to adopting agile practices: the agile adoption framework. Innov. Syst. Softw. Eng. 3, 203–216. https://doi.org/10.1007/s11334-007-0026-z Smart, J.F., 2015. BDD in action: Behavior-Driven Development for the whole software lifecycle. Manning Publications, Shelter Island, NY. Snowden, D., 2016. The Adjacent Possible [WWW Document]. Cogn. Edge. URL https://cognitive-edge.com/blog/the-adjacent-possible/ (accessed 4.20.20). Snowden, D., 2015. The Evolutionary Potential of the Present [WWW Document]. Cogn. Edge. URL http://cognitive-edge.com/blog/the-evolutionary-potential-of-the-present/ (accessed 4.20.20).

Snowden, D.J., Boone, M.E., 2007. A leader’s framework for decision making. Harv. Bus. Rev. 85, 68. Stephens, M., Rosenberg, D., 2003. Extreme programming refactored: the case against XP, The expert’s voice. Apress, Berkeley, Calif. Taleb, N.N., 2012. Antifragile: things that gain from disorder, 1st ed. ed. Random House, New York. Trevino, L.K., Lengel, R.H., Daft, R.L., 1987. Media Symbolism, Media Richness, and Media Choice in Organizations: A Symbolic Interactionist Perspective. Commun. Res. 14, 553– 574. https://doi.org/10.1177/009365087014005006 Tripp, J., Rienemschneider, C., Thatcher, J., 2016. Job Satisfaction in Agile Development Teams: Agile Development as Work Redesign. J. Assoc. Inf. Syst. 17, 267–307. https://doi.org/10.17705/1jais.00426 Yip, J., 2016. It’s Not Just Standing Up: Patterns for daily Standup Meeting [WWW Document]. URL https://martinfowler.com/articles/itsNotJustStandingUp.html (accessed 4.20.20).

Appendix

Interview Questions – Semi Structured Interviews:

What is your definition of working agile?

Why do you think it is important to be agile as an organization?

What agile practices have you and your team been adopting?

What enabling factors do you think need to be in place for agile practices to be successful in the commercial organization?

What are the direct advantages you expect coming out of being agile?

What second-order effects (positive or negative) do you expect to arise from becoming more agile?

What are the possible drawbacks of implementing agile?

How could the adoption of agile practices in the commercial organization go wrong, what are the risks?

How can these risks be mitigated, and what is being done to mitigate that risk?

How do you perceive your own role in making this transformation happen?

What things, that we have not discussed, would you like to mention in relation to the topic agile and agile adoption?