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

. 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


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.

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 Sect. 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].

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 crossfunctional 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].
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 adaption, which are be 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].
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].

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. Facilitator of team and product owner; maintains motivation and self-organization of the team; moderator of the daily stand-up and the sprint retrospective Product owner Interface to all customers and stakeholders; prioritizes the back log items in order to maximize the value of team results; moderator of sprint planning and sprint review Development team 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 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.

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.
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].

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.

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-errorapproach 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, selforganization 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 partsone 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.

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.