# Scrum as Method for Agile Project Management
Outside of the Product Development Area

Ronny Weinreich, Norbert Neumann, Ralph Riedel, Egon Müller

► To cite this version:

Ronny Weinreich, Norbert Neumann, Ralph Riedel, Egon Müller. Scrum as Method for Agile Project Management Outside of the Product Development Area. IFIP International Conference on Advances in Production Management Systems (APMS), Sep 2015, Tokyo, Japan. pp.565-572, 10.1007/978-3-319-22756-6_69. hal-01417614

HAL Id: hal-01417614

https://hal.science/hal-01417614

Submitted on 15 Dec 2016

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
# Scrum as method for agile project management outside of the product development area

Ronny Weinreich*, Norbert Neumann*, Ralph Riedel**, Egon Müller**

*Robert Bosch GmbH, CP/AB5, Im Birkenwald 32-46, 70435 Stuttgart, Germany

**Technische Universität Chemnitz, Department of Factory Planning and Factory Management, Erfenschlager Straße 73, 09125 Chemnitz, Germany

`{ronny.weinreich;norbert.neumann}@de.bosch.com`

`{ralph.riedel;egon.mueller}@mb.tu-chemnitz.de`

**Abstract.** In recent years Agile Project Management (APM) and especially the Scrum framework have grown in popularity in order to deal with "vuca" business environments. Scrum has become more and more common practice in software development and has already been tested in a few hardware domains. But is it also applicable outside the development area? The paper aims to show potentials and limitations in the use of Scrum in a purchasing environment and describes implemented customizations.

**Keywords:** agile project management, Scrum, case-study, non-development, purchasing

# 1 Introduction

Present business environment became "vuca", which means companies have to face an increasing volatility, uncertainty, complexity and ambiguity [1]. To deal effectively with these challenges they need to develop certain capabilities. In recent literature agility is frequently mentioned, while the concept itself is defined very heterogeneously and comprises many sub-disciplines [2]. Agile Project Management (APM) as one of them seems to provide successful approaches [3].

Relevant experience issues mainly from software development and rarely from hardware development [3]. Outside the product development there are only scattered papers which address the potential of agile approaches, e.g. in the field of factory planning [4] or sales [5]. For this reason the paper tries to figure out potentials and limitations for APM outside of the product development area based on a case-study in a purchasing environment.

Therefore the article presents some theoretical basics on Agile Project Management and Scrum followed by a comparison of differences between the fields of product development and non-development. Thereafter the research methodology is described as well as the analyzed case. Finally the paper concludes with the evaluation and discussion of the results and an outlook on future research intentions.
# 2 Theoretical Background and Research Methodology

## 2.1 Agile Project Management

The need for APM as well as its ideas, concepts and methods originated from the field of software development [3]. Its success story began after the articulation of the agile manifesto [6], which brought high attention to the field [7]. APM is based on the principles of agile manufacturing and lean management.

The most common method in APM is Scrum (see chapter 2.2), followed by Kanban and several methods, which are mainly focused on software development. A broad field of hybrid or customized solutions exists besides these stand-alone methods. The field where APM is most common is software development. Other domains where APM has already been adopted are (hardware) product development and process optimization [8, 9].

## 2.2 Scrum

In the field of project management the term “Scrum”, which is originally a formation in rugby sports, was at first mentioned in 1986 in an article of Takeuchi and Nonaka. They describe self-organized and “multilearning” project teams which work cross-functional and subtly controlled in overlapping development phases [10]. Sutherland and Schwaber took these findings and the term “Scrum” and developed in the early 1990s the today known framework, which was first presented in 1995 [11].

<figure><img src="image_2.png" /><figcaption>Fig. 1. Events during a sprint within the Scrum framework</figcaption></figure>

Scrum is defined as “a framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value” [12, p. 3]. The underlying principles are transparency, inspection and adaptation, which are followed by using a special iterative process (see fig. 1), a special role model (see table 1) and a number of artifacts [12]. Most of these artifacts are not defined by the framework itself but are good practices in the field of APM. Examples are the use of (kanban-) taskboards, pair working or the use of estimation techniques like planning poker [13, p. 24].
<table><caption>**Table 1.** Roles and their responsibilities within the Scrum framework</caption><thead><tr><td>Role within Scrum</td><td>Responsibilities</td></tr></thead><tbody><tr><td>Scrum Master</td><td>facilitator of team and Product Owner; maintains motivation and self-organization of the team; moderator of the daily stand-up and the sprint retrospective</td></tr><tr><td>Product Owner</td><td>interface to all customer and stakeholder; prioritizes the back log items in order to maximize the value of team results; moderator of sprint planning and sprint review</td></tr><tr><td>Development Team</td><td>self-organization and continuous improvement of productivity; works on back log items to deliver value to the customer; responsible to fulfill Product Owner's requirements</td></tr></tbody></table>

Moreover, Scrum requires an agile culture, which focuses on collaboration and creation while hierarchy and competition step back. The structural elements of Scrum support this. It could be noticed that these values are partially contrary to those of hierarchical organizations. As a consequence the implementation of Scrum requires many changes in the field of management [11].

## 2.3 Development of Social Systems

In order to show commonalities and differences between possible areas for the application of APM it seems to be worthwhile to analyze the systems they work with. Therefore table 2 shows a number of attributes, adopted from systems theory [14].

As purchasing builds up the interface to other companies (suppliers) the authors interpret it as an area for social systems development.

<table><caption>**Table 2.** Comparison of development areas</caption><thead><tr><td>Attributes</td><td>Software Development</td><td>Hardware Development</td><td>Social Systems Development</td></tr></thead><tbody><tr><td>elements</td><td>data</td><td>data; physical objects</td><td>people</td></tr><tr><td>relations</td><td>technical interplay</td><td>technical interplay</td><td>communication</td></tr><tr><td>dynamics</td><td>non-emergent</td><td>non-emergent</td><td>emergent</td></tr><tr><td>behavior</td><td>complicated; deterministic or stochastic;</td><td>complicated; deterministic or stochastic;</td><td>complex; contingently</td></tr><tr><td>testing and results</td><td>directly testable; direct result</td><td>simulated or prototyped; direct result</td><td>simulated or direct; delayed results</td></tr><tr><td>memory</td><td>amnesic or resettable</td><td>resettable or replaceable</td><td>reminding; existing path dependence</td></tr></tbody></table>

Especially the differences in terms of system behavior and testing possibilities lead to the question, how these special circumstances affect the application of Scrum and which necessities for customizations can be derived from that.
## 2.4 Research methodology

Due to the explorative and primarily qualitative character of the research question a case study approach was first chosen as suitable research methodology. A case study can be described as the “detailed examination of a single example of a class of phenomena” [15, p. 34]. In the current stage of research this approach is useful to first provide hypotheses, which can be tested systematically later on with a broader empirical basis [16].

A case study research design has the following components shown in table 3 [17, 18] with its equivalents in our particular case.

<table><caption>Table 3. Research design</caption><thead><tr><td>Component</td><td>Equivalents</td></tr></thead><tbody><tr><td>The study's questions</td><td>Is it possible to apply SCRUM successfully in non-development domains and in living systems as organizations? What phenomena result from the particular domain of application?</td></tr><tr><td>The study's propositions</td><td>SCRUM as an agile project management method is applicable in non-development domains and it leads to better, faster, more goal-oriented, more focused, more flexible and more creative problem solving processes. The non-development domain leads to some particularities.</td></tr><tr><td>The study's units of analysis</td><td>One concrete case in the purchasing department of a big automotive supplier with several events (on-site-training, CSM-workshop, daily stand-ups, sprint plannings and review, retrospectives) and project team members, the team coach, the product owner. Information was gathered from interviews, document analysis and participatory observation.</td></tr><tr><td>The logic of linking the data to the propositions</td><td>Conclusions build on a qualitative analysis of documents, interviews and observations, including a classification scheme and qualitative variables.</td></tr><tr><td>The criteria for interpreting findings</td><td>History of events; time effects, accumulations of particular conditions; correlations with specific roles, environmental impacts etc.; outcomes of the project; opinions, emotions, satisfaction of the participants.</td></tr></tbody></table>

The case study itself can be seen as embedded in a superordinated cycle of action research because the research itself is participative, i.e. the researcher is more or less part of the team, as well as problem-identification, planning, action and evaluation are interlinked [19]. The knowledge created in the research process is to be fed back in the system to improve the system's resp. the agile project's processes and outcomes [20].
# 3 Case Study Analysis

## 3.1 Case Description

The analyzed case was a single project in a loss-making business division of a global automotive supplier. The project goal was to secure break even by reduction of expenses. Because the biggest expenditure item was material cost the focus was mainly on purchasing but also on logistics and production. Therefore the participants of the project came from different departments and different countries in order to build up a cross-functional (or functional dissolved) and multinational team. Each team member was more or less specialist of his domain which is required by the high specificity of the automotive branch.

The project environment contained many stakeholders and a high management attention, which implied many internal politics and a high dynamic. So a "vuca" environment was given. For that reasons the chosen operating system was Scrum, in order to be able to cope with the named circumstances:

* iterative process to adapt on changes due to the existing dynamics

* cross-functional and self-organized team, scraped together at one location and supported by a Scrum Master to create required creativity

* Product Owner to handle needs of stakeholder and management

The team has been grown during the project from twelve to 15 members (inclusive Scrum Master and Product Owner). Five people were transposed during the observed project time due to several reasons, e.g. job change or limited secondment.

Nobody in the team had experience with APM. Therefore the Product Owner and Scrum Master got a CSM-certification first while the whole team got a 2-day-training to introduce in Scrum. Besides this the first four sprints (8 weeks) were supported by a consultancy.

Less than 50% of the team staff had practical experience within the problem field.

The team was co-located for only three days per week (Tuesday to Thursday) because the employees came from all over Europe. The used task-board was not digitalized in order to have all participants most of the time at the same location to secure direct communication and full participation. Other used artifacts were an impediment log, an overall roadmap to show the strategy (comparable to a release plan), an availability plan of all team members and a central server in order to have full access to all documents and information.

The chosen sprint length was two weeks, while every sprint contained the planning meeting, four stand-ups (twice a week), the sprint review and the sprint retrospective.

The vision was formulated as the amount of cost the team had to reduce. The backlog items to reach this vision consisted of ideas from the whole team but were prioritized by the Product Owner.

The observer (first author), which is CSM as well, had the function of a scientific attendant. Mostly he participated in the Scrum events, e.g. planning, review and retrospective, to gather data and to act like a promoter, consultant or questioner.
## 4 Evaluation Results and Discussion

Due to the limited extent of this article the evaluation focuses mainly on insights which are linked to the special environment of social systems development and the automotive business. Already known issues like team development, cultural change or the influence of disturbances from different sources could be also recognized but are not addressed in this paper.

The most difficult challenge while implementing Scrum in the non-development area is the fact that there is only a limited possibility to test ideas and solutions (see table 2). Trying e.g. a new negotiation concept like it is usual in purchasing all tests would be real-time within the living system. This means to use a trial-and-error approach is only possible at a high risk. As a consequence the team decided to implement quality gates due to the criticality of a task fail. Low criticality allowed that team members could decide for themselves or by four-eye-principle; high criticality needed the involvement of the Product Owner or sometimes the stakeholders. A problem which the authors observed is that these offered a possibility for micro-management by the Product Owner or the stakeholders. Thereby, self-organization of the team and an autonomous idea creation, concept development and testing were more or less blocked. Another issue regarding the involvement of different parties is about speed. The more people are involved, the more time for decision making was needed (see e.g. [21]). To overcome endless discussions in some places it was chosen to introduce the sociocratic consent moderation approach [22, p. 9], which promises faster decisions with a higher quality by minimizing rejection and veto instead of maximizing agreement.

Critical is also the granularity of items. If they are too restricted, often the solution is intended by the formulation of the task. So the team could not determine the way of solving the problem and as a consequence creativity is limited.

Micromanagement and a restricted granularity of the tasks showed a negative impact on team motivation and the trust in the method Scrum, especially because the team members, who are all experts in their field, expected from an agile approach a more open way to work.

Another issue resulted from the social systems scope and from the specificity of different domains in automotive business. The one Product Owner did not have the competence for all domains and sometimes the translation from the stakeholders into the team failed. So it was inevitable that even team members had to talk directly to stakeholders, which is originally not intended within the Scrum framework. Later it was chosen to install a Chief Product Owner and three Product Owners each for specific areas in order to deal with the high complexity. Scrum Planning was split in two parts – one hour for the whole team moderated by the Chief Product Owner, one hour for planning within the specialized area. Thereby, the team was divided in smaller sub-teams (3-7 people) even though they constantly tried to act and optimize as a whole.
After three month of work a strategic change could be recognized. While at the beginning the overall project roadmap was structured by qualitatively described problem fields (purchasing material fields) without any relation to saving potentials, later on it changed to a prioritized action plan oriented at the relation between saving potential, estimated lead time and inherent risk. This implies that especially in case that the problem field is very complicated and the team is not familiar with it a set up time is needed. So in early sprints analysis and idea creation outweigh while later execution is more focused. This means not that there is a cut between a kind of planning sprints and executing sprints. Planning and execution are always done in parallel in order to adjust over the whole project time.

# 5 Conclusion and Future Research

It can be concluded that most of the elements of Scrum can be used also within a project in the purchasing area while some of them need some customization. In addition, there are other critical aspects, e.g. the difficulty to manage the variety of specialists in order to create a common team or to find the right granularity of tasks and targets.

Therefore especially in environments like automotive with a less agile culture as well as in social systems development further qualitative research is required. On a long-term perspective broader quantitative research should aim at clarifying the most effective tools and principles of APM and how those contribute to project success.

Also the used sociocratic consent moderation approach needs much more scientific investigation as it is relatively new, less used and differing from traditionally known decision methods like the autocratic decision by a powerful superior or the decision by election as it is used in a democracy.

# References

1. Bennett, N. & Lemoine, J. G.: What a difference a word makes: Understanding threats to performance in a VUCA world. Business Horizons 57, p. 311-317 (2014)

2. Jentsch, D.: Wandlungsfähigkeit im Management produzierender Unternehmen. Chemnitz, IBF (2015)

3. Riedel, R.: Systemische Fabrikbetriebsplanung auf Basis eines kybernetischen- soziotechnischen Modells. Chemnitz, IBF (2012)

4. Reinema, C. et al.: Agiles Projektmanagement – Einsatzpotentiale und Handlungsbedarfe im Rahmen von Fabrikplanungsprojekten. ZWF 108, p. 113-117 (2013)

5. van Solingen, Rini et al.: Scrum in Sales. How to improve account management and sales processes. In: AGILE 2011. IEEE Computer Society, p. 284-288, Salt Lake City (2011)

6. Beck, K. et al.: Manifesto for Agile Software Development, URL: www.agilemanifesto.org (2001)
7. Dingsøyr, T.: A decade of agile methodologies: Towards explaining agile software development. The Journal of Systems and Software 85, p. 1213-1221 (2012)

8. Komus, A.: Status Quo Agile 2014. 2nd international study on application of agile methods. Koblenz. www.status-quo-agile.com (2014)

9. Conforto, E. C. et al.: Project Management Agility Global Survey. Cambridge, CEPE (2014)

10. Takeuchi, H. & Nonaka, I.: The new product development game. Harvard Business Review, January-February 1986, p. 137-146 (1986)

11. Maximini, D.: The Scrum Culture. Introducing Agile Methods in Organizations. Berlin, Springer (2015)

12. Schwaber, K. & Sutherland, J.: The Scrum Guide. The Definitive Guide to Scrum: The Rules of the Game. URL: http://www.scrumguides.org/docs/scrumguide/v1/scrum-guide-us.pdf (2013)

13. Conforto, E.C. et al.: Can Agile Project Management be adopted by industries other than software development? Project Management Journal 45 (3). p. 21-34 (2014)

14. Ropohl, G.: Allgemeine Systemtheorie. Einführung in transdisziplinäres Denken. Berlin, Edition Sigma (2012)

15. Abercrombie, N., Hill, S., Turner, B. S.: Dictionary of sociology. Penguin, Harmondsworth, UK (1984)

16. Flyvbjerg, B.: Five Misunderstandings About Case-Study Research. In: Qualitative Inquiry 12 (2), 219-245 (2006)

17. Rowley, J.: Using Case Studies in Research. Management Research News 25 (1), p. 16-27 (2002)

18. Yin, R. K.: Case study research; design and methods. Sage, Thousand Oaks (2003)

19. Waterman, H., Tillen, D., Dickson, R., de Koning, K.: Action research: a systematic review and assessment for guidance. Health Technology Assessment 23 (5) (2001)

20. Susman, G. I.: Action Research: A Sociotechnical Systems Perspective. In: G. Morgan (Ed.) Beyond Method: Strategies for Social Science Research. Sage Publications, London (1983)

21. Godwin, W. F. & Restle, F.: The road to agreement: Subgroup pressures in small group consensus processes. Journal of Personality and Social Psychology (30) p. 500-509 (1974)

22. Buck, J. A. & Endenburg, G.: The creative forces of self-organization. Sociocentric Center Rotterdam (2012)