From Slow and Heavy to Agile and Lean: An empirically based theory of how managers ease the transition from traditional to lean-agile approaches to product development

Master of Science in Industrial Economics October 2020

From Slow and Heavy to Agile and Lean

An empirically based theory of how managers ease the transition from traditional to lean-agile approaches to product development

Bengt Haraldsson

This thesis is submitted to the Department of Industrial Economics at Blekinge Institute of Technology in partial fulfilment of the requirements for the degree of Master of Science in Industrial Economics.

The thesis is equivalent to 10 weeks of full time studies.

The authors declare that they are the sole authors of this thesis and that they have not used any sources other than those listed in the bibliography and identified as references. They further declare that they have not submitted this thesis at any other institution to obtain a degree.

Contact Information:

Author(s):

Bengt Haraldsson

E-mail: beha17@student.bth.se

University advisor:

Viroj Jienwatcharamongkhol TIEK

Department of Industrial Economics Blekinge Institute of Technology

Internet : www.bth.se

Phone : +46 455 38 50 00

A BSTRACT

Background

Lean and agile approaches to product development impose a paradigm shift in the way organizations are structured, lead, affect the core culture of the firms that use them.

As more and more organizations attempt the move from traditional to lean-agile ways of working a large number of challenges and success factors from these transitions are reported in the scientific literature. Many of these challenges can be mitigated, and the success factors boosted, by the traditional line-manager.

Objectives

The objective of this study is to provide an empirically grounded theory of what managers can and should do in order to ease the transition to lean-agile ways of developing products and services.

Methods

This study uses constructivist grounded theory in order to obtain an empirically based theory for how managers ease the transition. This is achieved by combining the results from an online survey, a series of interviews, and field observations. The collected data is then analyzed, categorized and

continuously tested against new data, resulting in an emergent theory that can be put into the context of the available scientific literature.

Results

This thesis presents the results from a yearlong study of a Swedish organization in the middle of transitioning from a traditional plan-driven to a scaled lean-agile approach to product development.

The resulting theory states that managers can greatly ease the transition by being the manager teachers for their organizations and committedly leading the way in adopting the lean-agile values, principles and methods, in a value-based manner – making sure the new ways are adapted to fit the context of the company and its goals as an organization.

Conclusions

The conclusion of the study is that not only are managers needed in organizations adopting lean-agile values, principles and methods, they are central to a successful adoption. However, when not being knowledgeable of lean-agile, not staying committed, and not engaging with the teams and practitioners the managers may on the contrary end up costing the company the opportunities offered by the new approach to product development. The resulting theory is grounded both in empirical data and the scientific literature.

Keywords: scaling agile, managers, SAFe, LeSS, success factors, challenges, Lean

C ONTENTS

ABSTRACT ... II

CONTENTS ... III

LIST OF FIGURES ... IV

1

2

2.1

2.2

2.2.1

2.2.2

2.2.3

2.3

2.4

2.5

2.5.1

2.5.2

2.6

3

3.1

3.1.1

3.1.2

3.2

3.2.1

3.3

4

4.1

4.1.1

4.2

4.2.1

4.2.2

4.2.3

4.2.4

4.2.5

4.2.6

4.2.7

4.2.8

4.2.9

4.2.10

4.2.11

4.2.12

4.3

4.4

5

6

6.1

6.2

ACKNOWLEDGEMENTS ... 42

REFERENCES ... 43

APPENDIX ... 46

A.1CHALLENGES AND SUCCESS FACTORS SUMMARY TABLE ... 46

A.2 QUESTIONNAIRE SURVEY ... 48

L IST OF F IGURES

Figure 1 - The lean thinking house ... 8

Figure 2 - SAFe backlog structure ... 10

Figure 3 - Sprint structure in LeSS ... 11

Figure 4 - Iterative framework (Gandomani & Nafchi, 2015) ... 14

Figure 5 - Theory of how managers enable agile transition (green arrows indicate possible reinforcing feedback loops) ... 37

1 I NTRODUCTION

One of the main currencies of successful firms is the ability to correctly judge spending on

development projects in order to secure future profitability. The standard approach for many industrial firms is to choose which projects to run based on net present value (NPV) (Tonnquist, 2016).

Calculating NPV requires the assumption that cost of the project, time to delivery, what should be delivered and how the market will react to the new product (i.e. forecasting) is known (at least to some extent) at the beginning of the project. In order to follow-up and control that the results from the project align with the intended outcome, a plan for the project is created and deviations from the plan are monitored.

However, when undertaking a major shift in technology – introducing a whole new product, using unknown technologies and aiming for a market that does not exist until the first firm in the race introduces the new product – the standard approach of locking a project scope to a certain time to a certain cost is sub-optimal (resulting in constant scope creep as well as re-planning) (Waardenburg &

Vliet, 2013).

With rising complexity, rapid development of technology, and uncertain customer requirements, product development becomes increasingly risky. For this reason, many organizations turn to agile development practices to mitigate these effects (Schuh, et al., 2018). In the 12^th State of Agile Survey 97% of the respondents answered that their organizations practice agile development practices, but only 12% answered that their organization had a high level of competence in using the methods (VerisonOne, 2018).

How can this be? So many organizations looking to solve problems using tools they really don’t understand. One might argue that they are new to the tools, and this might be correct, but what if there are other forces at work preventing the transitions to new ways of working in product development?

Agile practices seem to provide a solution to the problem of the unknown circumbstances by

providing a methodology for change driven development. This is achieved by a series of steps, that on the surface seem almost trivial, but that has far-reaching implications for the entire firm and the way it does business. The main difference between a traditional approach and an agile one is the fact that in order to achieve actual agility, product authority needs to be shifted from higher management to the teams developing the product, meaning managers need to delegate or completely move the product responsibility to the teams. Furthermore, to achieve speed in development the team needs to be able to improve on and customize their ways of working, meaning standard processes for product

development need to be adopted for team centric development. Also, development teams need access to actual customers in order to foster a fast paced feedback loop to further increase agility, something that is normally handled by entirely different roles in classical industry firms. The customer benefit is always central for the prioritization of work, and as customer preferences change during the course of the project, the goals and plans can quickly be adjusted. (Beck, et al., 2001; Bottani, 2007; Gandomani

& Nafchi, 2015; LeSS Company B.V., 2018; Schwaber & Ken, 2018)

Because of this, agile methods provide the means to rapidly respond to market changes, increase speed of delivery, and to effectively manage company resources via effective prioritization of strategic initiatives. So why then is transitioning to the new paradigm so hard? It turns out there are a number of challenges, chief amoung them is the commitment of management, as will be discussed in detail in the background section – where challenges and success factors to agile scaling is presented.

The agile methods are becoming increasingly common in both small and large organizations, but were originally intended for small projects with co-located teams (Paasivara, 2017; Waardenburg & Vliet, 2013). The problem then becomes to make it possible to scale the agile practices to larger structures (projects or organizations) satisfying the need to ailgn and synchronize multiple teams’ efforts, while not sacrificing the core agile promises to allow for fast adaption to changing technical and business

commercially available – e.g. SAFe and LeSS – as well as ones proposed by researchers – e.g.

Gandomani & Nafchi (2015) – that aim to guide organizations in achieving the lean and agile benefits of small scale development in the larger context. The process for achieving this will in the context of this thesis be called scaling. This does not simply imply adding personnel, although this might also be the case, but to scale the lean and agile ways of working as well as thinking to larger contexts than one team or a small project.

Transitioning to agile ways of working requires profond changes to be made to behaviors, culture, and processes. Employees and management, need to embark on a journey involving not only technical asspects, but also involves social behaviors (Gandomani & Nafchi, 2015). As mentioned above, there are a number of factors that influence the success of the scaling (described in section 2). Many of these factors are linked to how the managers in the organizations react to the changes imposed by the act of scaling, and therefore this is the subject of this thesis.

In this study the term manager is defined as the line manager, since they are the ones ultimately responsible for fostering the environment in the firm that can lead to the adoption of a scaled lean and agile product development methodology (Dikert, et al., 2016). It is true that there are other types of managers, for example a project manager, but the project manager has manager as well that does not manage projects, but manages project managers. In these types of organizations, all power and thus possible commitment to changing both culture and structures stems from the line managers (Serrador

& Pinto, 2015).

The reasoning behind focusing on the managerial influences on agile scaling is that, although the teams’ responsabilities change and they might not accept the increased scope of work, the managers need to first commit to actually delegating or handing over some of their responsabilities to the teams, meaning that if this does not happen first, none of the other implication of adopting agile methods can follow.

In this thesis the research question linked to manager participation is formulated as follows:

How do managers ease the transition from traditional to agile product development methods?

In order to answer this question a series of interviews were conducted in an organization undergoing a transformation to a scaled lean-agile approach to product development. The data from the interviews was augmented with observations (field studies) sampled over one year of frequent visits to the company; observing interactions, adoption status as well as results. The material was analyzed in order to create a theory of how managers may ease the transition by providing the prerequisites needed as well as guiding the organization towards implementing the changes required by the new ways of working.

This thesis takes a Grounded Theory approach, and the research was conducted in a Swedish firm during a one year period investigating the attitudes of managers during a transition to agile ways of working.

The research was conducted based on data from six interviews, approximately one hour long, as well as observations of the behavior and communication patterns of the managers during the observatory visits.

Section 2 of the thesis provides the background of lean and agile methods, scaling frameworks, and challenges and success factors when attempting lean and agile scaling reported in the literature. The following section (Section 3) describes the method employed in the study – i.e. describes the grounded theory approach. Section 4 provides a summary of the various results of the study, including excerpts from the interviews with the managers. The final two sections (Section 5 and 6) provide an analysis of the resulting theory of how managers support an agile transition, and conclusion as further work respectively.

2 B ACKGROUND

In this chapter, the background for the study is given along with an introduction to agile and lean principles, frameworks for scaling agile development and what factors influence successful agile scaling in development organizations.

2.1 A comparison of traditional and agile approaches to product development

The traditional project lifecycle includes the phases Idea, Pre-study, Planning, Execution and Impact (Tonnquist, 2016). In the early stages requirements are broken down and activities defined in order to perform a planning exercise which will determine when the project will be concluded. The metrics of traditional projects are Time, Cost, and Performance. A successful project is concluded on time, within budget and reaches the desired project targets (Serrador & Pinto, 2015).

In this context, it is fully possible to execute a highly successful project, that introduces a result that fails to deliver actual value (Serrador & Pinto, 2015). This might be a result of change in customer preference or new technologies being made available during the project duration without proper changes in the project scope as a result of the changes. The aim in traditional project management is to define a clear outcome of the project activities in early stages, but it has been reported that “50% of design activities occurred in phases other than design” (Serrador & Pinto, 2015, p. 1041). This is usually a result of deviations from the project plan, i.e. the organizations inability to meet the project goals, but seldome as a result from changes in the actual goals.

Serrador and Pinto (2015) proposes to add the measure stakeholder success to the traditional measures (time, cost, and performance). Hindering implementation of agile practices in product development has negative effects in the organization since evidence suggests that “the level of Agile used in a project does have a statistically significant impact on all three dimensions of project success, as judged by efficiency, stakeholder success, and perception of overall project performance” (Serrador & Pinto, 2015, p. 1049). Besides these overall results Serrador and Pinot also concludes that there is no

correlation between using senior staff and the overall improvements introduced by moving to agile ways of working, stating regarding the agile ways of working “… that they allow for superios success regardless of the use of ‘seasoned’ staff” (Serrador & Pinto, 2015, p. 1049).

Plan-driven approaches to product development, in the more traditional sense, are based on the assumption that problems are fully specifiable and that optimal and predictable solutions exist for every problem (Waardenburg & Vliet, 2013). These methods entail detailed planning, step-by-step processes, and reuse of design as well as assuming a development cycle consisting of a pre-

development phase detailing the work to be done, a development phase where the implementation is done – based on the pre-defined requirements – and a post-development phase with validation and documentation. In this sense it is appropriate to use traditional and plan-driven as congruent terms, and this will be the practice in this text. At the enterprice level, some cultural commonalities in companies that practice plan-driven methods include a hierarchical organization, centralized decision making, and scarce resources spread thin over multiple projects. Companies practicing agile methods on the other hand are more focused on adapting to change, collaboration with customers, decentralicing decision making in a more flat hierarchy, and provide incrementally developed solutions that are continously releaseable. Here lies an important distinction that needs emphasis. Instead of running a large project that introduce a fully developed product, the product is released early, and then functionality is continuously added to it.

Serrador and Pinto (2015) lists three draw-backs of defining very detailed product requirements early in the development process. First, they argue that early prototyping could give a better description of the goal product, instead of waiting for a full specification, build what is know and add to that moving forward. However, this is seldome done in traditional ways of working. Secondly, early specification

smallest amount of work to satisfy the customer. Finally, if the requirements are defined and decided early, changes in customer preferences are hard to accommondate during the development.

Agile methods try to avoid up-front planning and focus on adopting to change. Often working closely to a customer in order to try to deliver what the customer actually desires (Dikert, et al., 2016).

Traditional project methodologies have the benefit that they allow for traditional portfolio management, where effective use of a firm’s scarse resources are achieved via detailed up-front planning of spending and resource use. Because of the different approach in agile methods it is often the case that even though agile approaches are used in the development, traditional portfolio

management processes are still used to govern and finace the development – focusing on central decision making and detailed annual budgeting plans. This often negates the positive effects of the agile approach to product development since the agile focus is to have less detailed product planning and de-centralized decision making regarding the product, making the implementation of agile

approaches harder (Ahmad, et al., 2017). Ahmad et al. concludes that moving to an agile approach for project management “served to lower the level of investment risks for the companies” (Ahmad, et al., 2017, p. 13). Compared to traditional project management, agile methods assume variability and allow for continuous incremental deliveries of project results (Stettina & Hörz, 2015).

In traditional project portfolio management the aim is to find suitable project initiatives, prioritize between them, allocate resources, balance the portfolio and to review the projects in the portfolio (Serrador & Pinto, 2015). The alternative proposed by most agile scaling frameworks (Larman &

Vodde, 2009; Scaled Agile, 2019; Stettina & Hörz, 2015) is to keep the teams stable and finance work in value flows. This enables teams to pull work from backlogs at different levels instead of individual employees being allocated to, often multiple, projects and jumping from different contexts. At the enterprize level, the value flows can be financed based on the overall strategy of the company and on the portfolio level different initiatives can be prioritized with the help of lower level product managers and product owners (Stettina & Hörz, 2015). The work is broken down to smaller batch sizes and prioritized, then it is planned continuously in short increments by the teams that will deliver the finnished tasks.

Reinertsen (2009) defines twelve shortcomings with the traditional approach of product development:

failure to correctly quantify economics (not accounting for cost of delay), blindness to queues (queues are invisible in product development if not visualized properly), worship of efficiency (loading workers to maximum capacity), hostility to variability (thinking all lessons from lean manufacturing should be applied to product development), worship of conformance (strive to keep the project in line with the original plan even when learning that the project targets should be changed), institutionalization of large batches (collecting deliveries in large projects with the same deadline), underutlilization of cadence (not requiring the organization to work in the same pace), manage timelines instead of queues, absence of work in progress (WIP) constraints, inflexibility in the resources (fostering experts and over-loading them with work), noneconomic flow control (not basing decisions on return of investment weighted with cost of delay), and centralized control.

The alternative to the traditional approach to product development is to use a scaled lean and agile approach to product development. In this text scaled is used to indicate not only that the product development is carried out by a fairly large number of teams, but also that the methodology is used from the development team to the project governance. During the transition to agile methods the traditional plan-driven methodology will for some time co-exist with the new ways and “coping with the complexity that results from having both plan-driven and agile development emerge as one of the most daunting tasks for agile practitioners” (Waardenburg & Vliet, 2013, p. 2155).

2.2 Agile Basics

The agile mindset is best described in the Agile Manifesto (Beck, et al., 2001) where four values are defined:

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

Firstly, it must be noted that applying agile development practices by no means implies that, for example, documentation should not be produced at all. The weight is put on the left part of each statement, but the other parts are not rendered obsolete. Secondly, the statements have far-reaching implications in regards to traditional business practices. Processes and tools are usually regarded as something that aligns an organization and promotes flow of value, but here it is deemed as inferior to individuals interacting. The implied change in culture here can’t be over-stated. It promotes trust in individuals and their ability to deliver value via delegated responsibility for the product development.

Traditionally, requirement specifications for the products are created in advance and broken down for the teams to implement (Tonnquist, 2016). The agile approach is to let the documentation evolve together with the product. Also, as the customer is involved and the scope of the project is not finalized before development starts, it is possible to minimize the risk that the final delivery is not what the customer actually wanted or needed (Deming, 1988).

Planning in traditional projects is used to create budget as well as NPV calculations that are used by the firm’s management to determine what projects to run or not (Tonnquist, 2016). Because of this, changing the plan is viewed as a deviation. Agile mindset promotes planning, but at the same time encourages evolving the plan as needed. Thus, making it possible to respond to change.

Twelve principles are also stated in the Agile Manifesto together with the agile values (Beck, et al., 2001), which help emphasize customer satisfaction as the highest goal, welcoming changes, delivering frequently and incrementally, having developers interact with business people, point out that motivated people performs best – and the managers role is to support this, working with minimal viable products, de-centralizing control, continuous attention quality, and to reflect and improve continuously.

Traditional projects often aim to have a project release at the end (Tonnquist, 2016), when the complete scope of the project is met. The first principle in the agile manifesto changes this approach and argues that project should focus on continuous delivery of value to the customer as the product evolves. If value is delivered continuously this also makes it easier to accommodate changing requirements since it might not require a major re-development of the entire product. As business people and developers work together it can be assured that business value is created as well as making it possible to respond to market changes. If trust is put on the individuals that are developing the product and communication is handled face-to-face it is possible to take fast and well-grounded decisions in regards to the product and its evolvement. As the development moves on, the team can reflect on the progress and make improvements to their ways of working. Note also that it is imperative to continuously work with quality and design since it is a prerequisite for agility. Stettina and Hörz (2015) summarizes available information in the literature regarding this in the following manner:

Agile software development is fast and flexible due to frequent feedback loops, iterative reviews and close customer contact. Without this direct interaction agile methods loose much of their effectiveness (Stettina & Hörz, 2015, p. 140).

In traditional large-scale projects, there is always a risk that the scope will include non-essential work, scope creep (Tonnquist, 2016), a reason for this can be that it is hard to keep track of what every resource-hour (amongst thousands of hours) is used for. This is one of the implications of the de- humanization of reducing people to resource-hours in a spread-sheet. A manager might use the project to finance work that is judged as beneficial to a certain part of the organization, possibly leading to local optimization to the cost of the organization as a whole. Agile focus on simplification and satisfying some customer needs early – sometimes called a minimum viable product (MVP) – and using this as a

and clearly visualized work. It is also evident that the amount of trust that management needs to put on their developers should, from an agile point of view, be enough for them to self-organize and take responsibility for not only their work but also the interfaces to other teams by creating architectures and requirements, as well as designs.

Finally, taken to its full logical conclusion the eighth principle in the manifesto leads to the move from project-based development and towards a sustainable delivery of value with a pace given by the team’s velocity. Meaning it is possible to continuously release (deliver) value to customers. In contrast, it has been reported that using non-agile methods often lead to challenges with coordinating releases, especially when features are developed by multiple teams (Paasivara, 2017).

2.2.1 Scrum

One example of an agile method that embodies the agile principles is Scrum (Schwaber & Ken, 2018).

The main artifact in scrum is the product backlog. In the backlog, all the work that the team needs to do in order to further the product development is listed in a prioritized order. Scrum breaks down the development process into sprints, where the teams plan and execute product development. The work is incremental (planned continuously) and iterative (learnings documented in sprint retrospectives). The sprint is considered a time-boxed project with a duration of no more than one month. The items in the backlog should be broken down into small enough work packages that the team can complete one or more of them during one sprint. Scrum introduces the role of the product owner to continuously prioritizes the work in the backlog so that the team can pick from the top prioritized work in the backlog each sprint and be sure that they are working on the right things at the right time. At the end of each sprint the team gets together and evaluates the sprint in order to improve collaboration and ways of working, ideally including the customer at the reviews, but keeping their own retrospective within the team so they can openly discuss their efficiency and progress as a team.

It is the team’s responsibility to make sure that quality, architectural, and other enabling work gets prioritized in the backlog. This is to ensure the longevity of the value creation (i.e. to balance between the release of new features and to make sure that the ability of future feature development is possible).

The scrum master helps the team follow scrum practices such as daily stand-up, sprint planning, and retrospectives (Schwaber & Ken, 2018). In scrum, much of the project management tasks is handled by the team (Serrador & Pinto, 2015).

2.2.2 Extreme Programming

Another agile method is Extreme Programming (XP). It provides rules for the development grouped in five areas (Planning, Managing, Designing, Coding and Testing).

Instead of following the standard flow of all the work needed for a project (analysis, design, code, test, demo) the work is broken down into user stories – describing the value created for the customer – and architectural spikes – enabling work needed that the customer does not see directly – and the steps are then taken for individual work packages in order to get a more continuous flow of value. The user stories are grouped based on the most important features and these are developed first. It is also recognized that the requirements need to be able to evolve along with the software in order to enable an iterative workflow. Each iteration is planned towards a small release, and requirements and test scenarios are defined per user story. The architectural work is planned using a system metaphor, envisioning what the system should be after the iteration. The learnings from an acceptance test is fed back into the next iteration in order to foster continuous learning practices. (Wells, 2013)

As can be seen the XP project is iterative and focuses on customer interaction. XP fosters code quality via the practices of defining stories with requirements and test scenarios. (Wells, 2013)

2.2.3 Kanban

Kanban can be viewed as a tool for visualizing workflow. The main artifact in Kanban is the Kanban board which is used to visualize coming work (backlog) as well as ongoing and done work items.

Kanban is highly customizable and only really mandates three things in order for the work board to become a Kanban board. That all work is visualized (for completeness), that all different stages in the workflow has a work in progress (WIP) limit (for focus) and that all work has a measured lead time (the average time to complete one item, cycle time, for optimizing the process). (Ortiz, 2016)

The agile Kanban practice does not completely encompass the lean ideal Kanban since it is closely linked to the end-to-end value creation flow in lean thinking. More on this in the next section.

2.3 Lean basics

The two pillars of Lean product development are Continuous Improvement (kaizen) and Respect for People. The main aim of lean thinking is to have a sustainable work pace, but at the same time have as short a lead time as possible while delivering products with the highest possible quality, lowest price and high customer satisfaction (while keeping employees happy and safe).

The aim for the continuous improvement is to welcome change and to constantly become better.

Continuous improvements include go see, a practice where management goes to the actual place of work to see for themselves what issues the teams are facing, and kaizen. Kaizen is a Japanese term that involves spreading knowledge, taking small and relentless steps towards improving, employing lessons learned focusing on finding the root cause of a problem (by asking why at least five times), having an eye for waste, aiming towards perfection, and working towards flow. (Larman & Vodde, 2009)

Respect for people includes not troubling one’s customers, to develop the people in the company and after this develop products, not to make people do wasteful work, to let teams and individuals develop their own methods for doing their work and evolve these methods, to establish trust with partners with stable relationships, and to develop the teams to solve their work issues. (Larman & Vodde, 2009) In lean thinking the term waste is used for all work that does not benefit the customer. The aim should always be to minimize the amount of waste in the total ecosystem of the company. Some sources of waste according to lean is overburdened employees, bottlenecks, waiting for others to complete work, handoffs, wishful thinking, and information scattering. Some ways to minimize waste is to make sure that workers’ capacity is not overloaded, to set proper work in progress limits, to know the capacity of the organization and thus not end up in wishful thinking, to manage queues, to make sure team members have a broader knowledge and can do much of the work the team needs to accomplish, and employing pull in a kanban system where the team signals when more work needs to be added (contrasted to a push situation where teams get work pushed on them). (Larman & Vodde, 2009; Reinertsen, 2009)

Within lean thinking managers are viewed as leader teachers that embody the lean principles and teach these to the rest of the organization. This is partly accomplished by making sure that the fourteen principles of lean are followed. Among these principles are to base decisions on long-term philosophy, reducing batch sizes, use pull instead of push, reduce variability (noting that zero variability is not always appropriate for product development), stop and fix, setting practices and norms, visualization, grow leaders that develop exceptional people, decide slowly with concensus and implement decision fast, and becoming a sustainalble learning organization. (Larman & Vodde, 2009)

In lean, the pull-system is named Kanban and one of its primary effects is to conserve the amount of work in progress (WIP) between two processes. Reinertsen describes this effect in the following manner:

If a simple Kanban system was trying to limit the WIP between two processes to 30 items, it might use six pallets that could each hold five parts as physical kanbans. The

the upstream process to make more parts. The upstream process is not allowed to make parts unless it has an empty pallet to put them on. This sets an upper limit to the amount of WIP between the two processes. (Reinertsen, 2009, p. 148)

Lean thinking is summarized in the lean thinking house below:

Figure 1 - The lean thinking house

In the anthology Modern Software Engineering Concepts and Practices (Dogru & Bicer, 2011, pp. 19- 46) Petersen compares the agile and lean approaches to product development in order to explore their commonalities and differences. He finds that lean and agile agree on the end goals, lean is agile in a way, since the principles of lean include the agile principles. However, Petersen argues, the systems view of lean, focusing on the value flow in the entire organization “end-to-end” (Dogru & Bicer, 2011, p. 44) is not included in agile thinking. Overall lean and agile practices match well, for example how improvements are based on experience based retrospection, and how managers should act.

As we shall see, many of the commercial frameworks for scaling agile methods have adopted the lean thinking in order to foster a systems’ thinking approach and flow oriented Kanban way of moving work to backlogs in order to include the end-to-end approach. This is to enable the agile methods, originally developed for small team situations, to function in the complex ecosystem of an entire enterprise. In this sense, it is appropriate to include lean thinking when scaling agile practices.

2.4 Management Style

Agile adoption promotes a change in management style, moving from driving development work to empowering teams to self-organize, take technical and product decisions, and handle dependencies to other teams. The manager in this context is viewed as a manager-teacher (Larman & Vodde, 2009, p.

49) or servant-leader (Scaled Agile Inc, 2019) providing the prerequisites for the teams to operate in an optimal way, but not managing their activities directly.

The idea of manager-teacher is derived from lean and such managers “are expected to be hands-on masters of their domain of work […], to understand lean thinking, and are expected to spend time teaching and coaching others” (Larman & Vodde, 2009, p. 49).

In much the same manner, a servant leader is expected to; coach teams to coordinate themselves, not coordinate them; setting objectives, not deadlines; being invested in the overall performance, not driving towards specific outcomes; asking the teams for answers, not providing them; letting teams self-

Respect for people Continuous improvement

Leader-teacher Product development

14 principles

Shortest lead time to highest customer satisfaction at lowest cost

organize, not directing their work; and helping others fix problems, not fixing the problems for them (Scaled Agile Inc, 2019).

The definition of an agile manager, or a manager in an agile context, differs in the literature. Some argue that agile managers are most often not profoundly knowledgeable in the area they are managing, but rely on transferable management skills (McPherson, 2016), while others state that managers should be masters of their craft (Larman & Vodde, 2009). However, they do agree on the approach to leadership being of the servant leader-type, coaching, not directing.

2.5 Scaling Lean and Agile

Since the agile methods described so far were created for smaller projects, including only a small number of teams, they are harder to implement in larger projects that require many teams (Dikert, et al., 2016).

There are many definitions of large scale, but in this study the measure proposed by Dickert et al. is used - a large scale agile endeavor is “50 or more people or at least six teams” (Dikert, et al., 2016, p.

88).

This section introduces work related to agile transition in terms of frameworks for the transition process.

A brief introduction into two experience based commercial approaches to agile scaling is also given.

The approaches are the Scaled Agile Framework (SAFe) and Large-Scale Scrum (LeSS).

2.5.1 Commercially available frameworks

This section introduces examples of commercially available frameworks. Focus is put on two of the most popular (VerisonOne, 2018) frameworks, SAFe and LeSS.

2.5.1.1 SAFe

In the 12^th State of Agile Survey it was reported that the most common approach to scaling agile was SAFe (29%) (VerisonOne, 2018). SAFe is a commercial and experience based framework for scaling lean and agile ways of working. Although studies have been conducted where implementation of a scaled lean and agile approach has been done, there is no evidence that suggests that the SAFe approach can be considered a best practice. The claim of SAFe is that implementing the framework will reduce time to market with 30-75%, increase quality with 25-75%, increase productivity with 20-50%, and raise employee engagement with 20-50% (Scaled Agile, 2019). No academic work is available that validate these results. The evidence presented by SAFe is 59 case studies from known companies including Intel, Telia, Cisco and Philips (Scaled Agile, 2020).

In SAFe the basic unit is the agile team, and the basic unit of scaling is the Agile Release Train (ART).

This unit is comprised of a number of agile teams adopting Scrum and XP practices all working towards a shared program backlog. The work packages in the program backlog are broken down to team sized items and stored in the team backlogs. In this sense, there is a hierarchy between backlogs.

The teams work in sprints, and to ensure large scale cadence (coordinating efforts in time) a planning horizon (often 10-12 weeks) is used – called a product increment (PI). At the end of each PI all teams meet up for a planning session where the next PI is planned.

SAFe makes use of system thinking in order to avoid local optimization in team organization and design principles. The ART is managed by a team including product management (handles ART backlog), system architects (ensures architectural runway is followed), and a Release Train Engineer (ART scrum master and servant leader). The ART usually is limited to 50-125 people. If an even larger number of people is needed in order to deliver a solution to the customer need, a number of ARTs can be grouped in a solution train and then a solution backlog is added, housing even larger work packages. In a similar fashion as for the ART, the solution train has its own solution management team (Scaled Agile, 2019).

The backlog structure in SAFe is visualized in Figure 2.

Figure 2 - SAFe backlog structure

SAFe uses lean portfolio management with Kanban flows at enterprise level. This means that it emphasizes the move away from a traditional project based development and instead instructs the organization of the firm in a way that enables continuous value flow to the customers. Each ART or solution should be as close to a complete value flow as possible to minimize dependencies. (Scaled Agile, 2019)

Adoption of SAFe emphasizes that the agile leaders on the ART and Solution levels must take a servant leader approach to their role (the same goes for the line manager role in SAFe), assisting the teams to coordinate their efforts, leaving time for the teams to develop and deliver actual value, and not waste time on coordination (Scaled Agile, 2019). In this sense, there is a hierarchy in abstraction level of the backlogs, but these abstraction levels are achieved in collaboration between teams and thus does not imply a hierarchy between people.

SAFe’s focus on coordinated efforts and cadence makes it suitable in developing technologies where many teams with a high number of dependencies are needed in order to provide value to a customer.

The aim in SAFe is to have feature teams comprised of people with the different skill sets needed to design, build and test a backlog item, but if this is not possible, the framework provides methods for managing dependencies. (Scaled Agile, 2019)

The work packages in the different levels of backlogs in SAFe are clearly defined. On an enterprise level there are epics, large work packages that often needs work from the entire firm to be

accomplished. The epics are broken down into capabilities, the backlog items used to direct the flow of value through a solution train (solution level). The capabilities are then broken down into features that are developed in the appropriate release trains (program level). For the teams in the release trains the backlog items are user stories and these are planned at ever PI-planning event based on the priority in the feature backlog on the program level. (Scaled Agile, 2019)

SAFe makes use of Scrum, XP and Kanban practices and combine these into a coherent scaling framework. The main issue is to adhere to the principles of servant leadership and the agile principles and not to build new hierarchies as the different levels of backlogs are created, but instead to leverage the power of self-organizing agile teams as described in the agile manifesto.

2.5.1.2 LeSS

LeSS emphasizes simplicity when applying Scrum principles to multiple team environments. The framework focuses on the cross-functional team that is self-managing, co-located, and long lived. The scrum masters are responsible for the implementation of LeSS in the organization and they do not only focus on one team (although they are responsible for 1-3 teams), but on the whole organizational system.

Managers in LeSS are no longer responsible for organizing the work with the product, instead they make sure that the people responsible for building the product are functioning optimally. (LeSS, 2018)

Solution backlog ART backlog Team backlog

In LeSS all product development is included in one backlog. If there is work needed to be done for the product it needs to be included in the backlog. Of course, there might be a large number of products, having different backlogs. The teams work together on backlog items, handling dependencies and self- organizing, in a shared sprint. (LeSS, 2018)

One point that Larman and Vodde want to make is that “Large-scale Scrum is Scrum” (Larman &

Vodde, 2009, p. 289), meaning that the aim of scrum is not to propose solutions to every problem, it provides a set of (thinking) tools that can be applied in order to understand what problems the organization is facing so that effort can be put into solving those issues. Some differences between LeSS and Scrum are however present. One extra sprint planning session is added, where the scrum teams self- organize to see which team should implement which feature in the backlog. Also, the sprint review is held together with members from all the teams working with the product, along with the product owner and customer representatives. To ensure team cooperation is continuously improving, an extra cross- team retrospective is also added to LeSS. The LeSS sprint is visualized in Figure 3.

Figure 3 - Sprint structure in LeSS

If even larger structures are needed, LeSS Huge can be employed. This structure still uses one product backlog, but the product owner is assisted by requirement area product owners since the backlog in this case usually becomes too much for one person to manage. (LeSS, 2019)

2.5.1.3 SAFe and LeSS Comparison and Justification

When comparing the frameworks, it can be seen that SAFe introduces roles and scales up the development creating a value flow for the entire firm. LeSS on the other hand aims to scale down and manage with a smaller number of developers by optimizing team participation and self-organization, thus optimizing the organization for value flow (Kettunen & Laanti, 2017).

Compared to SAFe, there are no additional coordinating or longer-cadence structures added to LeSS.

Here the focus is on creating the culture in the teams to manage their dependencies, work together when needed, and to self-organize to achieve as much customer value as possible each sprint. There are no program or solution management teams to coordinate and manage dependencies.

Where LeSS argues that managers are optional in the framework (LeSS, 2018), SAFe stresses the manager participation as critical, although with a different focus, and teaches servant leadership as the managers’ primary role (Scaled Agile, 2019).

Sprint planning 1 Sprint planning 2Sprint planning 2 RetrospectiveRetrospective Overall retrospective

Backlog refinement

Teams coordinate

Sprint review

LeSS Sprint Team 1

Team 2

2.5.2 Research based frameworks

There have been a number of attempts made by researchers to provide guiding frameworks for agile transition (Boehm & Turner, 2003; Cao, et al., 2009; Esfahani, 2012; Gandomani & Nafchi, 2015; Hoda

& Noble, 2017; Qumer & Henderson-Sellers, 2008; Sidky, et al., 2007; Sureshchandra &

Shrinivasavadhani, 2008; Vijayasarathy & Turk, 2012; Waardenburg & Vliet, 2013).

Boehem and Turner (2003) lists five critical decisions – size, criticality, culture, personnel, and dynamism – in their framework. They advocate a step-by-step implementation approach where the critical factors act as a guide to where the company should focus their attempts at moving to agile methods. This assures that the transition is based on risk assessments, where the risk is too high and a transition would impede critical development work, the transition is not to be pursued. The framework mostly focuses on the pre-analysis of the transition, and does not go in to detail of how the transition should then be conducted.

Van der Linden et al. (2004) propose a way of thinking about transformations that deviates somewhat from the general discourse in the literature on agile scaling. Instead of taking agile practices and implementing them, perhaps via a series of adaption steps as will be seen below, they postulate that first the business aspects must be considered, then a technical starting point for the architecture. Following this, appropriate processes for way of working can be chosen, and finally the organization that will do the work can be set up. This provides a logical way to navigate the transition, not having to do all the steps at the same time. They call the approach BAPO (Business, Architecture, Process, and Organization) and warn that many organizations get this backwards and end up in an OPAB situation.

First setting up an organization, then talking about ways of working, and only after this making an architectural starting point for the system and finally trying to map this to some business value.

The framework proposed by Sidkey et al. (2007) has multiple stages and an index for the maximum possible level of agile adoption reachable by the company. They introduce discontinuing factors that, during the first step of the framework, indicates if the company is mature enough to start the transition process. After this step, the second step entails evaluating the organization and projects to see how capable these entities are to perform the transition process. In the third and final step, based on the capability of the projects and the organization a set of optimally suitable agile methods and practices are chosen to be implemented. The index proposed for assessing the agile capability, however, has 300 points of measure, leading to impracticalities in applying the framework in practice or at least a vast amount of overhead needed to perform the, highly complex, tasks prescribed by the framework. This proposed practice seems also to miss-align with the core agile values of team autonomy.

Qumer and Henderson-Sellers (2008) propose a framework that is also based on a measure, called the Agile Adoption and Improvement Model (AAIM). Six stages are included in the framework, agile infancy, initial, realization, value smart, and progress. The framework does not, compared to (Sidky, et al., 2007), propose specific methods for the stages, but focuses on agile values and at which stage it is appropriate to work with these. A 4-DAT agility measurement technique is used to continuously assess the level of agility. This framework is criticized as not being practically applicable as well as adding overhead and reducing flexibility in the agile adoption (Gandomani & Nafchi, 2015).

Sureshchandra and Shrinivasavadhani (2008) focused on distributed development in their framework, based on the work by Boehem and Turner (2003). This framework has four stages, evaluation, inception, transition and steady-state. During the evaluation stage the degree of distribution in the project is assessed. In the stage that follows, inception, the teams are formed and it is checked how the agile practices can be incorporated in the already present/required ones. During the transition stage the agile practices are started to be performed during development. The steady-state stage is when additional teams are added and start to use the practices. This framework is not method-agnostic, but bases the framework on implementing scrum practices in an orderly fashion.

Cao et al. (2009) introduced a framework based on Adaptive Structuration Theory (AST) as well as on four case studies. The framework takes into account project and organizational factors. The criticism of

this framework is that it is not clear if AST can be extended in this sense, validation is needed, and that the level of agile in use in the organizations that were studied was quite low, only using some XP practices and having done so only for a short period of time (Gandomani & Nafchi, 2015).

In the doctoral thesis Transitioning to Agile: A Framework for Pre-Adoption Analysis using Empirical Knowledge and Strategic Modeling, Esfahani (2012) presents a method designed to evaluate the alignment to organizational objectives and strategies, before introducing agile practices. The method uses the strategical model of the company and a repository of agile practices, that allows for taking advantage of the empirical knowledge of the agile methods. The proposed framework, Strategic pre- Adoption analysis Framework (SAAF), includes the strategy for modeling the organizational objectives, an evidence based repository of agile practices to be chosen from, and the SAAF process that connects all the activities and artefacts in the framework. The overall process is divided into three stages:

initialization where a transition team is set up and the strategic model is created; strategical agile practices analysis during which impact of some chosen practice is analyzed after enacting the method in the development environment and the organization; and strategic actor analysis which is intended to identify problems in the current practices, before introducing agile ones, and see which set of agile practices could be used to alleviate the problems.

Vijayasarathy and Turk (2012) present a framework grounded in practice and empirical study of actual teams, making it possible to understand why one team may exhibit a high level of agile maturity, while another – practicing the same methods – may not. They found that agile adoption is a highly complex process that is not started and completed, but rather a continuous endeavor. The adoption, as seen from the theory presented by (Vijayasarathy & Turk, 2012), involves a networked set of changes along five dimensions: software development practices changing from traditional to agile – e.g. XP practices with an intermediate hybrid stage; team practices evolving from manager-driven to team-driven development work via a manager-assisted stage; management approach changing from driving the development to empowering the team to do so, also via an intermediate step, adapting; reflective practices going from nearly non-existing to highly embedded in the teams’ activities, via the focused step where specific reflections on critical topics are performed – e.g. lessons learned activities after deviations and critical events; and culture transitioning from strictly hierarchical to an open and transparent, via the evolving stage. The inter-relationships between the dimensions are highlighted in the framework.

Waardenburg and Vliet (2013) present an empirically grounded approach to managing co-existence of plan-driven (traditional) and agile practices. The main findings were centered around the challenges of an increased IT landscape complexity and a lack of business involvement. Concerning the increased IT landscape complexity, the mitigation strategies presented were: establishing a shared sense of purpose, making sure there was alignment in views on the program level, and to re-shape the project manager role to a more facilitating one. Regarding the lack of business involvement, the main mitigation strategies found were: to change the mindset of stakeholders on the business side, to make sure the product owner had business knowledge and continuously had access to changing information, and finally that the knowledge and requirements were aligned at the business level.

Gandomani and Nafchi (2015) propose an empirically grounded framework, using Grounded Theory methods, that is value based and iterative. In the framework, the steps; practice selection, adapting, assessment, retrospective, and adjustment is taken in a cycle as depicted in Figure 4. During the practice selection an appropriate agile practice, or set of appropriate practices, that should be adopted is chosen, based on expected business value – the value based approach is key in the framework. In the next stage, adoption is performed, this is defined as a continuous process of assimilating the practices, values and mindsets of agile and can’t be considered as something that can be time-boxed. “Agile adoption and adaptation are nothing more than changing people’s mindsets, behaviors, and cultures that is not easy and requires adequate period of time” (Gandomani & Nafchi, 2015, p. 212). In the next stage the success of the adopted practice is assessed and during the retrospective, improvement suggestions are gathered.

During the adjustment stage, the assessment and retrospective results are considered and the practices are adjusted and the cycle continues until the practice can be considered adopted.

Figure 4 - Iterative framework (Gandomani & Nafchi, 2015)

Hoda and Noble (2017) join (Gandomani & Nafchi, 2015) in criticizing earlier attempts at creating adoption frameworks. Their criticism in particular is directed at the impracticality of applying the frameworks in practice and lack of linking to industry. A transition in software development practices cascades to the other transitions, while team practices and management approach was seen to “reflect and adapt to each other, moving towards self-organization” (Hoda & Noble, 2017, p. 150). These transitions were “necessary, but not sufficient for transition in the reflective practices” (Hoda & Noble, 2017, p. 150). Culture – individual, team and organizational – was seen as a major influence on all transitions.

2.6 Success factors and challenges for agile scaling

In previous sections, it has been described that agile practices like Scrum, XP and Kanban mostly are applicable for a single team or a few teams working together to develop a product. However, in large firms providing complex services or products, for example in the automotive industry, there is need for a much larger number of teams to collaborate in order to provide customer value. Continuing this logic, it is clear that scaling agile practices to multi-team environments will entail challenges. When examining the literature available for scaled agile development it is clear that there exists no clear best practice in the academic literature. However, there are a number of reports from attempts at scaling agile development practices providing input for the classification of success factors as well as challenges.

This section summarizes the available literature on the subject in order to end up in a collection of categories that encompass the available data regarding challenges and success factors when scaling agile practices.

Dikert et al. identified challenges and success factors by performing a literature review (Dikert, et al., 2016). They found a great deal of reports regarding change resistance, both a general resistance to change - where a mediating factor was to present good reasons for the change, as well as skepticism towards the new way of working. They saw that top-down ordered change was met with resistance and that old organizational roles were hard to change. It was not only the employees that found top-down mandated change hard, also management were hesitant to change. One challenge was lack of investment when attempting the transition. There was lack of coaching, lack of training, no adjustment in workload during the transition, old commitments and deadlines were kept, and no adjustments were made to physical workspaces in order to allow for co-location of teams.

In general, Dikert et al. (2016) found that agile was hard to implement where misunderstanding of concepts, lack of guidance from literature, poor or no local customization (adaption), and excessive enthusiasm from some members that were almost religiously invested in doing agile the “right” way were all reported challenges. Also, coordination of multiple teams was found to be challenging since agile methods expect teams to coordinate amongst themselves – most being unused to this – interfacing

between teams was difficult, teams became focused on their part and did not respect the larger context resulting in issues with technical consistency and quality. These effects were seen to be aggregated when the teams were globally distributed. Since the different teams did not have the same interpretation of agile, the teams created diverging processes which increased the difficulty of transitioning, especially when the new methods were being used in parallel with old ones – i.e. in a hybrid setting.

Hierarchical management and organizational boundaries were concluded as being especially challenging in the study by Dikert et al. (2016). The middle managers role became unclear – resulting in resistance, management remained in the old waterfall mode when taking decisions, the old bureaucracy was kept and this affected what the agile teams – e.g. creating presentations for manager decision meetings instead of coding, and internal silos were kept making it hard for cross-functional collaboration. Requirement handling was also considered challenging as well as quality assurance – e.g.

functional testing. Finally, one challenge was to include non-development functions that were unwilling to change – e.g. sales.

Dikert et al. also reported success factors for implementing the scaled agile approach (Dikert, et al., 2016). Management support was viewed as an absolute necessity for making a lasting change and to remove obstacles during the transition. The change needed top management support and managers to be educated in agile practices. Another crucial factor for a successful transition was commitment to the change, from managers as well as staff, and to have good arguments why it is the right thing to do.

Recognizing the importance of change-leaders, often from outside the organization, was also seen as a success factor. The customization of agile practices to the local circumstances (adaption) was also seen as a success factor – i.e. not taking a framework as is – and it was seen to be even more positive when the teams themselves had been involved in the customization, when old ways were mapped and compared to new, and when scaling was kept simple and focused on engaging the people. Also, starting with a pilot was one reported success factor, as was appropriate training and coaching. Another success factor was transparency and communication so that it was known to all what was going on with the transition to agile ways of working. Other factors that were identified were alignment in mindset and agile values, making sure to work towards team autonomy, and finding a way to handle requirement tracking that worked in the new agile setting – realizing the importance and need for training of product owners.

Kalenda et al. reports the result of a literature study that aims to collect success factors and challenges when scaling agile practices (Kalenda, et al., 2018). They identified a number of challenges, including resistance to change among middle and higher management, teams not being co-located, quality assurance, interaction with non-agile parts of the organization, lack of commitment and teamwork, to high workload, lack of training and coaching, managing requirement hierarchies, and how to measure transition progress.

The following success factors were identified (Kalenda, et al., 2018); proper amount of training, united view on values and practices, having access to proper tooling, solid engineering practices and technical debt management, careful and long-term change of the organization, supporting teamwork, and executive sponsorship.

Pries-Heje and Krohn (2017) describes a case study of an agile scaling. The reasons for scaling agile practices were lack of systematic improvement, lack of visibility, too early commitment to concepts, late functional delivery, too late identified deviations, dependencies under-estimated, complexity growth, distributed teams, traditional phases in projects not applicable to software (e.g. completely defined design at project start), and poor morale. The following challenges were reported; challenge when new roles replaced traditional management roles, changing to an agile mindset, and interfacing with other parts of the organization.

The following advice (used here as success factors) was provided (Pries-Heje & Krohn, 2017);

management support is crucial, start doing agile to become agile, and hire or rent a change management