Agile Methods in the Design and Development of Modular Vehicle Systems

(1)

IN

DEGREE PROJECT INDUSTRIAL ENGINEERING AND MANAGEMENT,

SECOND CYCLE, 30 CREDITS STOCKHOLM SWEDEN 2020,

Agile Methods in the Design and Development of Modular Vehicle Systems

- A case study on a global transport solutions provider

MARTIN ROSENVINGE LUDVIG TEMPELMAN

KTH ROYAL INSTITUTE OF TECHNOLOGY

SCHOOL OF INDUSTRIAL ENGINEERING AND MANAGEMENT

(2)

1

(3)

Agile Methods in the Design and

Development of Modular Vehicle Systems

- A case study on a global transport solutions provider

by

Martin Rosenvinge Ludvig Templeman

Master of Science Thesis TRITA-ITM-EX 2020:147 KTH Industrial Engineering and Management

Industrial Management SE-100 44 STOCKHOLM

(4)

Agile Methods in the Design and

Development of Modular Vehicle Systems

- A case study on a global transport solutions provider

av

Martin Rosenvinge Ludvig Tempelman

Examensarbete TRITA-ITM-EX 2020:147 KTH Industriell teknik och management

Industriell ekonomi och organisation SE-100 44 STOCKHOLM

(5)

Master of Science Thesis TRITA-ITM-EX 2020:147

Agile Methods in the Design and Development of Modular Vehicle Systems

- A case study on a global transport solutions

provider

Martin Rosenvinge Ludvig Tempelman

Approved

2020-06-11

Examiner

Lars Uppvall

Supervisor

Jannis Angelis

Commissioner Contact person

Abstract

In today’s globally competitive business environment, efficient product development processes are critical for companies to meet rapidly changing customer demands and preferences.

Therefore, companies have looked beyond traditional linear product development processes leading to the development of new iterative processes. The new iterative and agile supporting processes have had strong success for software companies. However, how to leverage these new processes in modular hardware solutions remains unclear.

This thesis analyzes the challenges of utilizing and leveraging Agile Development (AD) while maintaining a modular product strategy. This study aims to increase the understanding of how to achieve a successful coexistence between AD and modularization and thereby allowing to work increasingly agile in modular settings to decrease costs and lead times. To study this, a case study on a has been performed on a large Swedish manufacturer of modular vehicle systems. To accompany this, an abductive research approach with qualitative methods has been used, where the results are based on interviews and internal documents. The results together with the literature enable a discussion on how AD and modularization can coexist.

The results can be summarized accordingly:

• AD and modularization can coexist given that AD is a philosophy and mindset and modularization is product strategy;

• the agile mindset and freedom have to be limited to the existing boundaries and principles set by the overall firm modular strategy; and

• the ability to work agile in modular settings is disrupted when the agile team requires external involvement of additional individuals.

The thesis concludes that the ability to effectively leverage AD in a modular setting depends on two aspects. First, the size and complexity of the project. Second, the product architectural knowledge within the agile team.

Keywords:

Product Development, Agile Development, Modularization.

(6)

Examensarbete TRITA-ITM-EX 2020:147

Agile Methods in the Design and Development of Modular Vehicle Systems

- A case study on a global transport solutions

provider

Martin Rosenvinge Ludvig Tempelman

Godkänt

2020-06-11

Examinator

Lars Uppvall

Handledare

Jannis Angelis

Uppdragsgivare Kontaktperson

Sammanfattning

I dagens globala och konkurrenskraftiga företagsvärld blir produktutveckling en alltmera kritisk process för att kunna möta snabbt ändrande kundbehov. Således, eftersöker företag att utnyttja mer okonventionella och iterativa produktutvecklingsmetoder. Dessa nya agila metoder har påvisats väldigt effektiva för mjukvarubolag. Det är dock oklart hur dessa metoder kan nyttjas fördelaktigt för modulära hårdvarubolag.

Denna studie analyserar utmaningarna i att använda och uttnyttja Agile Development (AD) samtidigt som man lyckas upprätthålla en modulär produktstrategi. Studien syftar till att öka förståelsen kring AD och modulariseringens samexistens, och därmed förklara hur man kan kombinera dessa för att minimera kostnader och ledtider. En fallstudie har gjort på ett svenskt tillverkande företag av modulära transportsystem. Med ett abduktivt förhållningssätt med kvalitativa metoder där data är från intervjuer och interna dokument. Resultaten tillsammans med teori möjliggör för en diskussion kring hur AD och modularisering kan samexistera.

Resultaten kan sammanfattas enligt följande:

• AD och modularisering kan samexistera för att AD ä ren filosofi medan modulariserig är en produktstrategi,

• den agila friheten måste begränsas till de redan befintliga villkoren bestämda av företagets modulära strategi och

• förmågan att arbeta agilt i en modulär kontext hämmas av när de agila teamen kräver involvering av externa individer.

Studien drar slutsatsen att förmågan att effektivt nyttja AD i en modulär kontext beror på två aspekter. Först, storleken och komplexiteten av projektet. Sedan, kunskapen om produktarkitekturen i de agila teamen.

Nyckelord:

Product Development, Agile Development, Modularization.

(7)

List of Figures

FIGURE 1-GENERIC PRODUCT DEVELOPMENT PROCESS (BOOZ ET AL.,1982) ... 6

FIGURE 2-AGILE DEVELOPMENT CYCLE (STELZMANN,2012 ... 9

FIGURE 3–SCRUM (SUTHERLAND,2010) ... 10

FIGURE 5-SPECTRUM OF PRODUCT ARCHITECTURES (WILLIAMSSON,2018) ... 15

FIGURE 6-PRODUCT ARCHITECTURES BASED ON FUNCTIONAL AND PHYSICAL DOMAIN (GÖPFERT,1998) ... 15

FIGURE 7-SYSTEM OF MODULARIZATION (ZHANG ET AL.,2015) ... 16

FIGURE 8-THE ABDUCTIVE RESEARCH PROCESS (SPENS AND KOVACS,2005) ... 22

FIGURE 9-CODIFICATION TREE ... 26

FIGURE 10-AGILE PROCESS SUGGESTED BY CASE COMPANY FUNCTION ... 33

FIGURE 11-PROGRAMME XSTRUCTURE ... 35

FIGURE 12-ABILITY TO WORK AGILE IN MODULAR SETTINGS ... 62

List of Tables

TABLE 1-INTERVIEW DATA ... 28

TABLE 2-TOOLS USED TO CONDUCT AND ORGANIZE THE THESIS WORK ... 29

TABLE 3-QUOTES AGILITY AT THE CASE COMPANY ... 34

TABLE 4-QUOTES AGILITY IN PROGRAMME X ... 36

TABLE 5-QUOTES MODULARIZATION AT THE CASE COMPANY ... 38

TABLE 6-QUOTES MODULARIZATION IN PROGRAMME X ... 40

TABLE 7-QUOTES PLANNING ... 41

TABLE 8-QUOTES PLANNING:PROCESS ... 44

TABLE 9-QUOTES PLANNING:PRODUCT ... 46

TABLE 10-QUOTES INTEGRATION ... 47

TABLE 11-QUOTES INTEGRATION:PROCESS... 50

TABLE 12-QUOTES INTEGRATION:PRODUCT ... 51

(10)

Foreword

This academic report was produced as a Master of Science thesis in Industrial Management at the Royal Institute of Technology (KTH) in Stockholm, Sweden. This project was conducted between February to June 2020, and this thesis is equivalent to 30 credits.

Acknowledgements

First, we would like to thank Associate Professor Lars Uppvall, for creating this opportunity for us to conduct this thesis project at the case company, for your interest in our work, and for supporting us throughout the course. Also, from an academic side, we would very much like to thank our supervisor at KTH, Associate Professor Dr. Jannis Angelis for supporting us in creating a thesis project of high research and academic quality. Lastly, we are very grateful for the support and commitment given to us from the case company, the interview participants, but especially our supervisor.

June 8th 2020, Stockholm

Ludvig Tempelman and Martin Rosenvinge

(11)

Acronyms

AD – Agile Development

ADC – Agile Development Cycle ART – Agile Release Train ASE – Agile Systems Engineering MFD – Modular Function Deployment MMT – Main Module Team

PD – Product Development

PMT – Programme Management Team IMT – Industrial Management Team RO – Regional Office

SAFe – Scaled Agile Framework

(12)

1

1. Introduction

This introductory chapter will provide an overview of the theoretical fields this research has its foundation in, as well as the problem that will be investigated. Furthermore, the aim, the objective, and the research question are presented. Finally, the delimitations of this study and the outline of the thesis are described.

This report investigates the meaning of agility and the usage of agile methods within modular vehicle systems. This project was conducted as a case study to analyze the current processes of the case company in relation to existing literature, to identify opportunities and shortcomings in the current way of working. Also, this report explores the opportunities to more successfully combine agile workflows and modularization.

Increasing competition, globalization, technological development, and maturing markets are pushing businesses to focus more on new products and growth while upholding their competitive advantage (Cooper, 1990). Hence, Product Development (PD) is a cornerstone to grow an economy, as well as a necessity for businesses to evolve (Oosterwal, 2010). According to Oosterwal (2010), the top-performing companies are seeing most of their revenue and profits from newer products. Furthermore, innovation is becoming a more significant factor in business success, and the rate of innovation required for a company to be successful is rapidly increasing (ibid). Also, frequently changing customer needs and preferences have shifted the power of traditional firms towards the customers, who demand increasing quality in services and products in combination with lower prices (Labrecque et al., 2013). Therefore, all of the change drivers mentioned above pressure firms to be adaptable (Cooper, 2014). Moreover, studies show that there are linkages between PD and the firm’s ability to diversify, adapt, meeting new market demands and technical development, which is vital for the firm’s capability to sustain its competitive advantage, making PD a complex process (Brown and Eisenhardt, 1995;

Cooper, 1990). Thus, businesses have been forced to transform their internal PD processes to satisfy these new demands, which also implies for the case company.

The new market environment has proven the traditional linear PD approach insufficient, ultimately shifting the focus to more iterative and customized PD processes (Maylor, 2010;

Takeuchi and Nonaka, 1986). Linear PD was suitable when the outcome from the project was clear from the start (Turner and Cochrane, 1993). However, today this is rarely the case (Cooper, 2014). Unpredictable project outcomes have given birth to iterative PD processes that incorporate steps to cope with change and increased uncertainty (Sommer et al., 2015; Thomke and Reinertsen, 1998). Today, firms have transitioned to so-called Agile Development (AD) methods, which strives to enhance flexibility to both internal and external changes (Maylor, 2010). Although, agile processes have their roots in software development and are currently applied there predominantly (Fowler and Highsmith, 2001; Winter, 2015). Thus, existing agile methods may not necessarily apply successfully to modular hardware solutions (Gustavsson and Rönnlund, 2013). Modular hardware solutions are defined in accordance with the case company, and refers to a modular vehicle systems with a combination of different internal systems, mainly driven by hardware components, but also include embedded software. This referral was used to generalize the thesis topic.

Applied to the case company, which is a large Swedish manufacturing company, there is an ongoing trend to provide more solution offerings compared to traditional product offerings.

Traditionally, the case company has successfully utilized modularization to offer a large variety

(13)

2

of products to low costs, which has developed into a competitive advantage. However, the earlier mentioned change drivers also apply in the case company’s industry, which has led to large organizational transformations, with the aim to boost performance in more complex environments. Therefore, the case company has initiated a program, named Programme X in this thesis, to ramp up speed in processes, reduce costs while not tampering with customer value, and explore new mechanisms to operate more effectively. Programme X includes small cross-functional teams, that focus on more cost-effective incremental innovations and optimizations to their overall products. However, there is a knowledge gap in the case company on how to leverage their current agile methods while maintaining hardware modularization.

Existing literature illustrates the abundance of research of AD within software development, but also the current lack of research when it comes to AD within hardware modularization (Fowler and Highsmith, 2001; Sommer et al., 2015). Hence, it can be argued that firms utilizing hardware modularity are not fully benefitting from the existing agile methods, not making them well-positioned in an uncertain global market. Therefore, it is essential for a large number of firms to better understand the two concepts, and where they differ at most, to realize a successful coexistence of AD and hardware modularization. AD can be viewed as a way of working, focusing on incorporating flexibility and manage uncertainty, whereas modularization is a product strategy that strives towards cost-reductions and high variety outputs through standardized mass production (Sommer et al., 2015; Ulrich, 1995; Ye et al., 2018). The two concepts are similar in many ways, especially given the fact that they both strive towards customized outputs and effectivity (Ye et al., 2018). However, they fundamentally differ in their approaches to achieve effectiveness, high output variety, and customer flexibility (Sutherland, 2010; Ulrich, 1995). Two aspects illustrating this dissimilarity are the level of planning, and the degree of integrated work (Eskildsen, 2011; Sutherland, 2010). Because modularization, as a product strategy, aims for large product scalability, will require extensive planning, and often results in cost-optimization in silos (Eskildsen, 2011). Whereas, in AD focus is more working effectively in close collaborative teams with almost no time dedicated towards planning (Boehm and Turner, 2005).

Therefore, this thesis will analyze modularization and AD in terms of these two opposite aspects in the current context of the case company, to better understand how AD and modularization can be combined.

1.1. Aim and objective

The aim of this report is twofold. First, it aims to contribute to the existing body of knowledge regarding the coexistence of AD and modularization. Second, this study also aims to analyze the current workflows in the case company’s Programme X in terms of current agile theoretical methods and principles, and to suggest possible process improvements to enable the coexistence of AD and hardware modularization.

1.2. Research Questions

Given the stated objectives, a main research question could be formulated as:

How can agile methods and modularization coexist in the development of modular hardware solutions?

In order to address this research question, two sub-research questions are derived for further analysis. They highlight the main differences between AD and modularization, planning stages,

(14)

3

and integrated workstreams. The first question investigates how the initial planning for a product development project is conducted for agile projects and modular projects.

RQ1: How do the planning stages for agile development and modular product development differ?

Furthermore, the second sub-research question addresses to what extent agile and modularization are different when it comes to integrated work between teams and functions.

RQ2: To what extent do agile methods and modularization differ in terms of integrated workstreams?

Analysis and discussion of how agile methods and modularization can coexist in the development of modular hardware solutions will be accomplished by answering the two sub- research questions. This will subsequently enable answering the main research question.

1.3. Delimitations

As Product Development is a very broad field, this study researches, in alignment with the case company, the concepts of Agile Development (AD) and modularization. As AD and modularization strive towards similar goals, there are aspects where they are aligned. However, main differences between the two concepts can be identified in the planning stages and the integration of work. This study will, therefore, focus on these two aspects. Also, the scope of this study is limited to a single case study of one company, primarily in one entity named Programme X. As the research only will deep-dive into this specific project and affected functions, this study will have difficulties in generating generalized results. Furthermore, this study only investigates the stages of the development of the concept, not the actual implementation, production, and manufacturing of a realized product or component.

1.4. Thesis outline

The structure of this thesis is presented below.

Literature Review

This section will provide a thorough understanding of the previous research in those areas relevant to addressing the research questions. The chapter will begin by introducing the literature of Product Development (PD) from a general viewpoint. This subsection will be followed by an in-depth research of Agile Development (AD) and modularization, which are fundamental to the objective of this thesis.

Methodology

This section will present the chosen methodological approach used in this thesis. Each aspect of the chosen research design will be explained and discussed systematically in subsections.

Lastly, this chapter will discuss the research limitations in terms of reliability, validity, and ethical aspects.

Results & Analysis

This section will present the results from the data collected in this case study. The results will be presented accordingly to the codification illustrated in the previous chapter, which is dividing planning and integration into either process- or product findings. The results will be supported by quotes from interview participants.

(15)

4 Discussion

With an emphasis on the chosen research design, this section will be based on the previous chapters and include a discussion of the generated empirical results from this case study in relation to existing literature. This section will answer the addressed sub research questions.

Conclusion

This section will conclude the thesis by summarizing the key findings, and answer the main research question. In addition, this chapter includes a presentation of the practical and theoretical contributions of this study, in combination with limitations, and suggested future research.

(16)

5

2. Literature review

In this chapter, a literature review will be presenting the topics relevant for this study, and provide an understanding of the theoretical framework this thesis has its foundation in. The topics are presented in a logical order starting from a generic description of Product Development and its importance for today’s firms. Followed by a deep-dive into Agile Development, the difference between agility in software development and hardware development, and its methods. Thereon, modularization as a product architecture, and as a process will thoroughly presented in accordance with the case company’s product strategy.

Lastly, a chapter summary is provided, highlighting the similarities and differences between AD and modularization.

2.1. Product Development

Product Development (PD) is a cornerstone to grow an economy, as well as a necessity for businesses to evolve (Oosterwal, 2010). Increasing competition, globalization, technological development, and maturing markets are pushing businesses to focus more on new products and growth while upholding their competitive advantage (Cooper, 1990). According to Oosterwal (2010), the best quarter of top-performing companies are seeing almost 50% of their revenue and profits from newer products, that have been in the market for a maximum of 5 years.

Furthermore, innovation is becoming a more significant factor in business success, and the rate of innovation required for a company to be successful is rapidly increasing (Oosterwal, 2010).

New internal PD is one of the most important aspects of a firm, since it is related to the firm’s ability to diversify, adapt, and evolve to meet new market demands and technical aspects (Brown and Eisenhardt, 1995; Cooper, 1990). Cooper (1990) highlights that earlier periods of high-frequency mergers can be seen as a result of dysfunctional internal PD, where resources are not leveraged effectively and do not result in organic growth. Therefore, it can be derived that a company's PD is highly related to their financial performance and is a necessity to survive in today’s highly competitive business environment.

PD can be viewed in a microlevel perspective, focusing on how structures and processes within an organization allows individuals to create new products (Brown and Eisenhardt, 1995). Many researchers have tried to develop a model that captures the essence of a generic PD process (Bhuiyan, 2011). One of the best-known models is the one developed by Booz, Allen, and Hamilton (1982), illustrated in Figure 1. The process of PD usually starts with identifying customer needs, and linking these to the overall strategy and objective to the firm (Booz et al., 1982). Subsequently, ideas to meet these demands are generated, evaluated, and selected, followed by a design-phase essentially focusing on turning an idea into a demonstrable and producible product (ibid). Lastly, the product is tested before being commercialized.

(17)

6

Figure 1 - Generic Product Development Process (Booz et al., 1982)

Current PD methods can be divided into either linear processes or iterative processes (Maylor, 2010). Over time, the competitiveness surrounding PD has increased, which has pushed companies to look beyond the traditional linear approach (Takeuchi and Nonaka, 1986). The linear approach is more suitable when customer demands are more defined. However, globalization is moving markets closer to the customer, technical developments have allowed costumers to scan all markets, and fast-changing customer preferences have pressured companies to cope with these changes and increase process flexibility (Cooper, 2014).

Flexibility in this report, is viewed as Thomke and Reinertsen (1998) define it. To clarify, flexibility is viewed as a relation to the incremental cost of adapting a product, when responding to internal or external factors (Thomke and Reinertsen, 1998). Where external factors can represent changes in customer needs or preferences, and internal factors can represent new and better technical solutions. The incremental cost includes PD expenses, unit cost, performance outcome, and the proposed schedule (ibid). Therefore, a firm’s response to a change will impact these factors and accumulate costs, leading to, the higher the cost for the firm to adapt to a change, the lower the flexibility (ibid). High flexibility is sought after in today’s firms since PD is increasingly more complex, thereby demanding the ability to handle late-stage changes that might be highly influential on outcome success (Sommer et al., 2015). Therefore, the traditional linear methods are less optimal in these new market conditions. Leading to the development of more iterative methods, in order to limit the costs for increased variety and enable the firm’s ability to act on sudden changes in the PD process, as well as increase new revenue and profits from new products (Takeuchi and Nonaka, 1986; Thomke and Reinertsen, 1998). The iterative methods are developed as a tool that incorporates iterations at different stages in the PD process, where in contrast to linear methods, iterations are managed, not eliminated (Sommer et al., 2015). Iterative PD processes build on a lightweight approach to increase speed and flexibility, and are derived from an agile approach of PD (Cooper, 2014; Sommer et al., 2015). Therefore, a large number of firms are striving towards achieving agility in their processes to increase PD performance (Winter, 2015). As product complexity increases, process models and methods become even more important for PD managers and functions (Sommer et al., 2015).

(18)

7

2.2. Agile Development

Agile Development (AD) has, since its introduction, been widely adopted throughout industries by some of the most successful companies (Shore and Warden, 2007). It has strong ties to software development after the release of The Agile Manifesto, signed by 17 software professionals (Fowler and Highsmith, 2001). The purpose of the manifesto was to explore new ways of working when developing software with values such as; individuals and interactions are put before processes and tools, working software is more important than detailed documentation, and responding to change over following a plan (ibid). Therefore, companies and project teams are now setting up agile processes within their organizations to follow these principles to achieve better results (Cooper, 2014). However, one could argue that as soon as an agile process, or any process, is set, the company is actually becoming “un-agile” (Varma, 2015). Agile methods enable firms to develop software faster and better, as well as making it scalable in large projects. Meaning that productivity of an individual is unchanged when adding resources, leading to possible R&D savings which could impact profitability positively (Sutherland and Schwaber, 2011). However, there is limited support for agile methods in large complex projects and little generalization is made to understand the projects work processes (Barlow et al., 2011; Misra et al., 2012). On the other hand, setting up processes that allow for flexibility and how to react to changes might be a must for organizations.

2.2.1. Definition

The term Agile was first introduced in several publications in the 1990s. As mentioned above, The Agile Manifesto defined a set of values to find new and better ways to develop software and concluded in the following four purposes (Fowler and Highsmith, 2001).

“We 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.”

The main focus of AD is to achieve organizational, personal, and technical success, through the adoption of methods that follow the philosophy of AD (Shore and Warden, 2007). Therefore, AD definitions vary between different sources. Kennaley (2010) defines AD as, “An iterative and incremental (evolutionary) approach to software development which is performed in a highly collaborative manner by self-organizing teams within an effective governance framework with “just enough” ceremony that produces high quality software in a cost effective and timely manner which meets the changing needs of its stakeholders”. Therefore, AD is based on iterative processes, with shorter deadlines, continuous evaluations (Austin and Devin, 2009), and, self-organizing cross-functional teams, with decision power over the team's agenda and focus (Varma, 2015). The self-organizing teams are frequently meeting and derive decisions and feedback from informal communication (Barlow et al., 2011). AD teams must also be emergent which indicates that new requirements emerge throughout the process and coding starts almost immediately, with almost no planning (Boehm and Turner, 2005).

(19)

8 2.2.2. Benefits of Agile Development

Sutherland and Schwaber (2011) highlights that AD can (1) increase speed of development, (2) align individual and corporate objectives, (3) create a performance-driven culture, (4) support value creation to shareholders, (5) achieve stable and consistent communication of performance at all levels, and (6) enhance individual development and quality of life. From an organizational perspective, all these attributes are interlinked and related. Therefore, for a firm to achieve these attributes, external considerations, outside of the AD method, must be taken into account. Even though AD can increase the speed of development and reach users faster, there must be mechanisms in the firm on how to collect customer feedback and needs, turn it into knowledge, and thereafter develop a functional solution that meets customer requirements (Vijay Anand and Dinakaran, 2015). Products desired by the customers will also be a driver towards shareholder value creation. It could be argued, mechanisms that allow firms to ensure that self- organizing teams can process customer information and from there, develop the right types of products is crucial for PD success and thereby, firm success. Furthermore, this ties together with the alignment of individual and organizational objectives, as self-organizing teams will need strong governance to ensure that closely working teams, do not work in silos (Misra et al., 2012). To continue, establishing a performance-driven culture in an organization will require strong knowledge in setting up and organizing teams (Nahavandi, 2015). Moreover, team leaders and top management will need to work closely in order to set a firm culture that is upheld in all self-organizing teams (ibid). In addition, setting up teams will require great knowledge about the employees, since all individuals do not prefer to work in teams or can fulfill their potential in teamwork environments (Vijay Anand and Dinakaran, 2015). On the other hand, teams achieve better results, and most people develop and enjoy working in teams, which gives an incentive to focus on this type of employee (Sutherland and Schwaber, 2011;

Vijay Anand and Dinakaran, 2015).

2.2.3. Agile Development in Hardware Solutions

The application and benefits of agile processes have, as mentioned earlier, mostly been direct towards software development (Cooper, 2014; Fowler and Highsmith, 2001; Misra et al., 2012).

Successful agile methods have saved companies large costs, improved outcome, and products has reached users faster for software companies (Sutherland and Schwaber, 2011). However, this trend has been lagging for manufacturing companies (Gustavsson and Rönnlund, 2013).

Therefore, it could be argued that manufacturing companies might not live up to their full potential, and research within agile processes within hardware PD should be emphasized.

Furthermore, there is no clear understanding of what AD means in the context of hardware products and how short sprints with continuous delivery, a main characteristic of AD, should be applied. One of the main issues within hardware AD is the product characteristics. Once a product is released and in production, a component needs to be physically changed for a hardware product upgrade to occur, while software systems can be upgraded through releases of new patches. However, there is a lot of work happening before a product goes into production. In fact, Gustavsson and Rönnlund (2013) points out the similarities between software and hardware development and their iterative work process with testing and simulation in production-like environments to further understand the behavior of the product. There is a general belief that agile principles could benefit hardware firms (Huang et al., 2012; Lee et al., 2016). However, to what extent is still uncertain (Gustavsson and Rönnlund, 2013). It could be argued that the complexity and variety of hardware manufacturing firms are much more substantial, compared to the similarities between software firms. Therefore, current research has difficulties to generalize AD within hardware and specific contexts are highlighted.

(20)

9

However, alignment seems to exist on that the software principles of the agile approach need to be somewhat altered to fit both hardware PD and the organizational context. To find ways to apply the AD philosophy into hardware PD, Lee et al. (2016) proposes an Agile Hardware Manifesto with the following principles:

• “Incomplete, fabricatable prototypes over fully featured models.

• Collaborative, flexible teams over rigid silos.

• Improvement of tools and generators over improvement of the instance.

• Response to change over following a plan.”

Different from the original Agile Manifesto, these is more customized for the development of hardware solutions. They are highlighting the fast development of prototypes where features can be added iteratively (Lee et al., 2016). The Hardware Manifesto also focuses on the importance of more specialized teams with engineers for different functions (ibid). This model however, neglects the original Agile Manifesto and highlights that documentation in hardware is important, as no engineer controls the whole flow of development and will reduce the complexity of validation and testing (ibid). Finally, the Agile Hardware Manifesto depends on better and easier hardware description languages that will enable the reuse of components through a more effective design process (ibid). Therefore, this definition is more in alignment with the case company and is chosen as this thesis view on AD.

Other research studying the use of the AD philosophy within hardware solutions has defined it as Agile Systems Engineering (ASE) (Haberfellner and Weck, 2005; Stelzmann, 2012; Turner, 2007). ASE is, in contrast to software development, relating to the development of systems that consists of hardware solutions, while software can be included to some extent, such as cars and machines (Stelzmann, 2012). However, there is still a research gap on methods for ASE.

Stelzmann (2012) proposes the Agile Development Cycle (ADC), illustrated in Figure 2.

Figure 2 - Agile Development Cycle (Stelzmann, 2012

The ADC represents an agile process for developing in small steps. Thereafter, it is aimed to produce something of value in all steps that can be presented to the customer. Moreover, the process includes the adoption of customer feedback in the coming development step. However, this is only suitable if prototyping, modeling, testing, demonstrating, and implementing can be done with low-cost and high speed (Stelzmann, 2012; Turner, 2007). Furthermore, it is

(21)

10

important to separate Agile Systems Engineering and the engineering of Agile Systems. In ASE, flexibility is incorporated within the process itself, while Agile Systems has the ability to be changed easily and rapidly (Haberfellner and Weck, 2005). Haberfellner and Weck (2005) highlights that ASE can adopt uncertainty before product release and that Agile Systems are beneficial in systems with a long lifecycle and significant switching costs.

2.2.4. Frameworks for Agile Development

Several different methods support the agile philosophy, such as Scrum, Scaled Agile Framework (SAFe), Lean Software Development, Extreme Programing, and Crystal (Stelzmann, 2012). However, in accordance with the methods used by the case company, this report will focus on the methods of Scrum and SAFe, even though they all have their roots within software development.

Scrum

Scrum is a well-known agile method. It was first mentioned by Takeuchi and Nonaka (1986).

The Scrum is a reference to rugby, where the team moves as a unit up the field and the ball is passed around within the team (Takeuchi and Nonaka, 1986). It was developed with the fundamentals from established iterative and incremental approaches, however, with an inclusion of human reality to achieve greater results by adopting the PD reality of learning, innovation, and change (Sutherland, 2010). As a testimony for the success of Scrum, the roll- out and the adoption of the method was rapid through some of the world’s biggest and most successful companies (Sutherland and Schwaber, 2011). The Scrum Teams are often composed of 4-7 members (ibid) The iterative and incremental Scrum process is illustrated in Figure 3.

There are three different roles in the self-organized cross-functional team; the Scrum Team who develops the product, the Scrum Master who ensures that the team has the necessary abilities to do their job, and the Product Owner who envisions the final product (Sutherland, 2010).

Figure 3 – Scrum (Sutherland, 2010)

As the figure illustrates, there are several different steps in the process that includes all team members. However, each step does not add speed and flexibility, but put together it can produce excellent results (Takeuchi and Nonaka, 1986). The vision of the product is expressed through the Product Backlog. It is a list where all activities are prioritized and ranked in order of customer and business value (Sutherland, 2010). The Product Owner is responsible to continuously add and remove items as well as reprioritize the list. The PD iterations within

(22)

11

Scrum are work cycles that are called sprints and are often between 1-4 weeks (ibid). However, these sprints have a fixed end date and are never extended, even though the work is complete or not (Schwaber and Beedle, 2001). Before each sprint, the Product Owner and the Scrum Team hold a sprint planning meeting, where the Product Backlog is reviewed. During this meeting, the items on the Product Backlog list are discussed and the Scrum Team decides which items should be completed before the end of the sprint (Sutherland, 2010). Moreover, the selected items are further broken down into individual tasks that are recorded in the sprint backlog (Schwaber and Beedle, 2001). Once a sprint is set and started, the Scrum Team meets every day in what is called a Daily Scrum Meeting. In this meeting, all the necessary information regarding the tasks are discussed to track progress. This information is then taken into consideration and might change the current plan (Sutherland, 2010). When a sprint is completed and something is delivered to the customers, there is a sprint review, where the Scrum Team, Product Owner, Scrum Master, customers, and stakeholders are present. The purpose of the sprint review is to analyze and present what has been done in the sprint (ibid).

Finally, the team gathers for a sprint retrospect, in which the team has open discussions on the things that are working well and those things that do not work, and agree on how to change (ibid). However, to ensure that different agile teams are managed and work in alignment with the company’s overall goals, other methods need to be applied.

Scaled Agile Framework

Another famous and widely adopted method is the Scaled Agile Framework (SAFe). The SAFe is developed to enable organizations to deliver important systems, in the shortest possible lead time together with the highest quality and value, through scalability and configurability (Knaster, 2018). It is designed in a way that allows businesses to tweak the method so it can best serve the businesses capabilities, achieve higher results, and more engaged employees (Leffingwell, 2016). SAFe relies on the foundation of the agile and lean philosophies and systems thinking (Knaster, 2018; Leffingwell, 2016), and serve as a catalyst to align, ensure collaboration, and delivery for a large number of agile teams (Leffingwell, 2016).

As SAFe can be scalable, it serves as a great tool for projects with 50-125 practitioners, as well as with projects of large complex systems with thousands of different practitioners (Knaster, 2018). It also provides four different organizational levels, Team Level, Program Level, Value Stream Level, and Portfolio Level, as well as a Foundation Layer (Leffingwell, 2016). The Team Level is based on several separate agile teams that use the Scrum method in the development process (ibid), and all teams belong to the Program Level, which is a virtual organized program structured called the Agile Release Train (ART) (Knaster, 2018). Every ART is self-organized consisted of 5-12 agile teams and stakeholders, responsible to deliver sustainable solutions (Leffingwell, 2016). The Value Stream Level is optional and more suited for large and complex development projects, and focuses on synchronizing different ART’s, solution intent, and context with the involvement of different types of stakeholders (ibid).

Furthermore, the Portfolio Levels manage and fund many different value streams (ibid). This level is using Lean-Agile budgeting to enable great coordination of the value streams, as well as sufficient governance.

The SAFe’s Foundation Layer is a set of critical and necessary aspects that supports the continuous delivery of value (Knaster, 2018). However, these are not specific practices. The aspects are Lean Agile Leaders, Communities of Practice, Lean Agile Mindset, Lean Agile Principles, and Core Values. The Lean Agile Leaders are the ones that are responsible for the success of the projects (Leffingwell, 2016). These leaders must, therefore, be trained to think and operate in these lean and agile ways and spread it throughout their teams. Communities of

(23)

12

Practice shifts organizations from functional to more flexible and adaptive approaches (ibid).

These communities serve as informal groups of team members and experts with possibilities to share knowledge and experiences (ibid). SAFe leaders must also have a Lean Agile Mindset that is a combination of beliefs, assumptions, and actions in alignment with the Agile Manifesto (Knaster, 2018). SAFe practices rely on nine fundamental principles. Knaster (2018) defines them as follows;

1. “Take an economic view 2. Apply systems thinking

3. Assume variability; preserve options

4. Build incrementally with fast, integrated learning cycles 5. Base milestones on objective evaluation of working systems

6. Visualize and limit WIP, reduce batch sizes, and manage queue lengths 7. Apply cadence, synchronize with cross-domain planning

8. Unlock the intrinsic motivation of knowledge workers 9. Decentralize decision-making"

These principles are derived from Agile principles and methods, lean PD approaches, systems thinking approaches, and case studies (ibid). To continue, the aspect of Core Values should define the beliefs and ideal state, to increase focus on correct tasks to achieve the business goals, as well as making SAFe effective (Knaster, 2018; Leffingwell, 2016). The first core value is Alignment, this refers to the alignment between management and teams to deliver customer value, and is achieved when everyone understands the strategy and how one can contribute (Knaster, 2018). The second is Built-in-Quality, which establish practices that enable predictable value delivery provided faster to increase customer satisfaction without loss of quality standards (ibid). Third, the value of Transparency is key for SAFe, as “You can’t manage a secret” (ibid). It sets the foundation of trust within the organization and is essential for performance, improvement, innovation, and risk-taking. Facts should be seen as friendly and enables that decisions can be made decentralized and thereby, increase the empowerment and engagement of employees (Nahavandi, 2015). The fourth and last Core Value is Program Execution. The ART serves as an enabler for businesses to deliver value in the shortest sustainable lead time, through teams of agile teams (Team Level in Program Level) (Knaster, 2018). This allows for eliminating silos, passing of tasks, steps, and increase the rate of value delivery to customers. Value can be enabled to flow more quickly when leveraging self- organized, cross-functional, and self-managing ART’s (ibid).

2.3. Modularization within Product Development

The increasingly complex nature of PD demands firms to be more flexible than ever before, while integrating a larger number of external and internal stakeholders in PD projects (Staudenmayer et al., 2005). In addition, to be successful in new product development firms must simultaneously improve PD lead time, reduce costs, enhance product quality, improve customer satisfaction, and promote market performance (Ye et al., 2018). To manage complexity and address these types of challenges, a large number of firms, including the case company, are utilizing modular product designs (Staudenmayer et al., 2005; Ye et al., 2018).

2.3.1. Definition

Tu et al. (2004) define modularization as “the practice of using standardized modules so that they can be easily reassembled or rearranged into different functional forms, or shared across

(24)

13

different product lines”. Where a module is a functional building block, chosen for company- specific reasons, to perform one or several functions, and has specified and standardized interfaces (Williamsson, 2018). In which an interface is the surface or volume creating the boundary between two modules, allowing the exchange of material, energy, and signals (ibid).

Thus, interfaces can be of many types, e.g. physical, electrical, etc. Hence, modularization can be used with great potential within PD, with means to achieving mass production cost- reductions while minimizing product complexity, which allows for swift adaption to new configurations and high output variety (Eskildsen, 2011; Tu et al., 2004; Ye et al., 2018).

Reductions of complexity in product designs and component interdependencies also enables concurrent module development, which in turn reduces the need for detailed designing, manufacturing, and testing of products due to design interdependency. In other words, modularization has the potential to reap the benefits of cost-efficiency through standardization while living up to diverse customer demands. Further, the emphasis on mixing and matching components and designs can be very helpful when adapting to external changes quickly (Eskildsen, 2011). Thus, the existing literature is highlighting modularization as an effective strategy for launching a wide set of new products quickly, frequently, and more efficiently (Lindblad, 2016; Ulrich, 1995; Ye et al., 2018).

In terms of the case company, product modularization is a very commonly used strategy, and is believed to be one of the main causes for their current competitive advantage. Their modular system is represented by a hierarchic generic product structure, enabling complete product customization using different modules. The most appealing benefits of modularization are that it increases structural flexibility, enhances product variety, increases product quality, shortens lead times, and achieves economies of scale (Ericsson and Erixon, 1999; Ye et al., 2018).

However, today’s fast-changing business environment has revealed the limitations of the currently used modular approach, ultimately increasing costs due to less possibility to conduct mass-production of modules (Meier et al., 2013). Because of their close connection to modularization, it is important that the researchers coherently view this concept compared to the case company. Therefore, modularization is in this thesis is viewed as combining a fixed number of components to create variety and customized products using as few components as possible, ultimately driven by reusage of both technical and non-technical assets (Björk and Hällfors, 2015). To clarify, it should be highlighted that modularization, according to this view, is applicable to not only hardware, but also software, processes, services, etc. (ibid).

2.3.2. Modularization as a Product Architecture

To achieve modularization, it is essential to both take product and process into account. In terms of product, Ulrich (1995) defines product architecture as the arrangement of functional elements, the mapping from functional elements to physical components, and the specification of the interfaces among interacting physical components. Where a functional element is one of the functions that the product is ought to do, e.g. cool air (Ulrich, 1995). Therefore, modularity can be viewed as a product architecture, based on the components that are part of the overall product system and what functions these components have (Langlois, 2002; Ulrich, 1995).

Different product architectures may be of varying complexity, depending on the arrangement and alignment of functional requirements to physical components, as well as the specification of interfaces between physical components (ibid). However, modularization strives towards minimizing the degree of coupling among different functional modules, since an uncoupled design is easier to manage, control, and design (Williamsson, 2018). Uncoupled design refers to whether there is a direct dependency between the functional elements and the physical components, i.e. that only one component is performing each function (ibid). Williamsson

(25)

14

(2018) describes the difference between uncoupled and coupled designs by using the example of water taps. A modern tap has one single module controlling both flow and temperature thereby making it uncoupled, due to the direct relationship between one physical component and functional elements. On the other hand, an old tap with one hot control valve and one cold control valve makes it impossible to change the temperature without adjusting the flow. This makes the design coupled, and therefore more complex. Thus, a modular architecture should have an uncoupled design, i.e. one-to-one relationships between physical components and functional elements. However, for an architecture to be completely modular, all interfaces must be decoupled as well, which would result in changes in one module are totally uncoupled to other modules, thereby not causing any changes in interactive modules, as long as they fit the interface requirements and specification (Eskildsen, 2011; Lindblad, 2016). Therefore, standardized interface specification both amplifies decoupling and enables an effective selection of product architecture (Eskildsen, 2011; Ulrich, 1995). As a result, end-product variation can be largely increased efficiently to meet different market demands. Furthermore, uncoupled designs allow for independency between subsystems within the architecture, thereby minimizing the impact and diffusion of sub-system malfunctions to the entire system (Tu et al., 2004; Ye et al., 2018).

Modular product architectures can in turn be divided into different sub-categories, one way of doing this is by interfaces, leading to three types of modular architectures (Ulrich, 1995). The first type is called slot architecture, which means that all interfaces are different between various module components (ibid). Where the interfacing connections are fitting for the modules attributed to a specific interface, e.g. like in an automotive dashboard. The second type is called sectional architecture, meaning that all module components are connected through identical interfaces, and there is no common base module, e.g. a couch (ibid). The third type of modular product architectures is called bus, where the same interface connections are used to connect various module components to a platform, or bus. Aircrafts tend to be designed in this way to more swiftly changing cabin layouts for different flights (Williamsson, 2018).

Product architectures may also involve integrated systems. They differ from modular product architectures since they have a far more complex relation between technical solutions and functional elements, besides having more coupled interfaces between modules (Mikkola and Gassmann, 2003; Ulrich, 1995). This makes them more complex to manufacture, assemble, and develop, since an adjustment in one component ultimately requires adjustment in interacting components to maintain product functionality, causing a domino effect (Williamsson, 2018).

Furthermore, the magnitude of this domino effect is determined by the specific product architecture, which makes it difficult to draw a concrete line that specifies the overall scope of one module adjustment (Mikkola and Gassmann, 2003). Williamsson (2018) exemplifies the difference between an uncoupled modular product architecture and a coupled integrated product architecture by comparing a standard vehicle to an F1 car. This example illustrates the increased need for extreme performance in the F1 car compared to the standard vehicle, which drives the need for an integrated and coupled design. Although, modular products can still be of high performance, however, integrated designs are particularly useful when there is a need for extreme performance combined with dimensional requirements, e.g. minimizing product weight or size (Williamsson, 2018). Thus, in a spectrum of different product architectures, one- to-one modular designs can be viewed as one extreme, whereas integrated designs are the other, as illustrated in Figure 4.

(26)

15

Figure 4 - Spectrum of Product Architectures (Williamsson, 2018)

The aim of modular architectures is to map as few functions as possible to each module, avoid function-sharing between modules, and have a one-to-one relationship between functional requirements and physical components (Lindblad, 2016). However, this stage is rarely reached, since the desire for high performance is high and different modules often are related in some sort (Williamsson, 2018). For example, vibrations from one module will ultimately affect nearby modules (ibid). Therefore, in reality, it is often the case that product architectures are largely modular but involve some integrated or non-modular characteristics. Figure 5 illustrates different product architectures based on physical and functional domains (ibid).

Figure 5 - Product Architectures based on Functional and Physical domain (Göpfert, 1998)

Functional-modular refers to architectures consisting of functionally independent physical components, i.e. uncoupled designs, but contains physical interfaces difficult to separate, i.e.

coupled interfaces (Göpfert, 1998; Ulrich, 1995). One example of such a product is the smartphone. Each module has a specific function, e.g. camera or battery, but since the including modules are assembled tightly, interfaces are coupled (Williamsson, 2018). Therefore, if adjusting one module in the smartphone system, interacting modules may require changes as well. Physical-modular refers to architectures consisting of physical components connected to decoupled interfaces, but the including product functions are highly dependent due to a coupled design (Göpfert, 1998; Ulrich, 1995). Thus, such a product can easily be taken apart, although, the overall product only functions when all modules are attached. Most types of automotive are designed in this way, making it possible to work on different modules simultaneously to decrease lead times, since changes in one module may not affect the others (Williamsson, 2018). However, a vehicle only functions when completely assembled. Hence, it can be argued

(27)

16

that product architectures ultimately determine what elements that will require adjustment due to a change, and what elements must be updated to achieve a desired output (Ulrich, 1995).

Given that, Figure 5 also illustrates that modularization strives towards increasing flexibility rather than extreme performance under certain conditions (Göpfert, 1998; Williamsson, 2018).

Where this is achieved by both incorporating an uncoupled product architecture and decoupled interfaces, which is complex.

2.3.3. Modularization as a Process

Modularization can also be viewed as a process, and it is vital to include the correct methods.

The modular product must be developed in such a way that it aligns with overall company needs and strategies, since adopting a modular approach ultimately will affect the entire firm (Williamsson, 2018). Therefore, modularization approaches or processes may look very different depending on the specific organizational context. However, Zhang et al. (2015) has generalized this process, leading to a system of modularization, which involves five parts in continuous interaction, illustrated in Figure 6.

Figure 6 - System of Modularization (Zhang et al., 2015)

The first part, product portfolio, refers to facing the needs of different market segments, and determining the type of product portfolio to satisfy consumer needs (Zhang et al., 2015). This part is also concerned with the product strategy chosen, and how the firm manages different product lifecycles (ibid). Ericsson and Erixon (1995) also highlight that modularization of a product often starts with defining customer demands and requirements. Since these are the foundation for which the physical components are built upon. This can be done using various methods for both collecting and structuring consumer data into technical solutions. This part continuously interacts with the product architecture and the function strategy (Zhang et al., 2015). Where product architecture is about as earlier mentioned, product structure; interfaces;

mounting points; and the merge of modules (Björk and Hällfors, 2015; Ulrich, 1995).

Therefore, setting a sufficient architecture is vital since the chosen design ultimately will define the borderlines for future PD innovations, and an effective product architecture will easier adapt to module changes and new configurations. Function strategy is about how to apply product function strategies into a system strategy, and to achieve the needs of the module functions (Zhang et al., 2015). To simplify the understanding of a product’s different functions and dependencies, a function-means tree can be used. This method is usually used in the design stage, and strives towards generating and model the relationship between functions and physical components (Williamsson, 2018). These two parts interact with the module strategy, which is concerned with how to establish module shelves, the planning of module lifecycles, and the

Agile Methods in the Design and Development of Modular Vehicle Systems

Agile Methods in the Design and Development of Modular Vehicle Systems

- A case study on a global transport solutions provider

MARTIN ROSENVINGE LUDVIG TEMPELMAN

Agile Methods in the Design and

Development of Modular Vehicle Systems

- A case study on a global transport solutions provider

by

Martin Rosenvinge Ludvig Templeman

Agile Methods in the Design and

Development of Modular Vehicle Systems

- A case study on a global transport solutions provider

av

Martin Rosenvinge Ludvig Tempelman

Table of Contents

List of Figures

List of Tables

Foreword

Acknowledgements

Acronyms

1. Introduction

1.1. Aim and objective

1.2. Research Questions

1.3. Delimitations

1.4. Thesis outline

2. Literature review

2.1. Product Development

2.2. Agile Development

2.3. Modularization within Product Development