Abstract
Since software became a major part of the car, we were interested in identifying which agile practices are used and adapted at Bosch automotive. Therefore, we conducted a multi-case study with nine interviews from five Bosch projects. Our results showed a strong focus on Scrum. Most of the Scrum practices are adapted due to the specific project context. Practices from other agile methods, e.g. XP, are used and adapted as well. We further collected the benefits of the practices, most often resulting in improved transparency and planning. The results are used to support automotive projects in selecting and applying agile practices according to their specific process improvement goals.
You have full access to this open access chapter, Download conference paper PDF
1 Introduction
Within software engineering, agile development has shown to be a commonly used approach [8, 9, 12]. Since embedded domains struggle with the integration of different disciplines, e.g. hardware and electronics, there is a lot more communication necessary [11]. These domains are currently using agile only to some extent in order to profit from the benefits of agile development, e.g. shorter time-to-market. This was one of the major reasons for Bosch Chassis Systems Control (CC) to become more agile. Thus, the state of agile in projects is interesting. Knowledge about usage, adaptations of Agile Methods and Practices, and their benefits should help spreading of agile.
2 Chassis Systems Control of the Bosch Group
The division CC is part of the business sector Mobility Solutions of the Bosch Group. The business sector Mobility Solution generated sales of 41.7 billion euros in 2015 (Bosch Group in total: 70.6 billion euros) which makes the Bosch Group to one of the world’s largest automotive suppliers. The division CC develops and manufactures innovative components, functions and systems that are designed to make driving a safe and comfortable experience. The projects of this study are developing systems for (highly) automated driving, e.g. a highway pilot.
3 Study Design
Research Questions.
Our objective is to better understand the usage, reasons and adaptions as well as benefits of agile methods and practices within Bosch CC. Thus, we ended up with the following research questions: RQ1 - Which agile elements (incl. agile methods and agile practices [3]) are used? RQ2 - How is the usage of the agile practice deviating from the textbooks? RQ3 - What are the benefits of the agile practices?
Case and Subject Selection.
Possible cases (Bosch CC projects) and subjects (interviewees) were identified by Bosch based on the organizational scope and their usage of agility. The latter was mandatory for participation. We identified 15 candidates representing five projects. Nine of the 15 candidates participated, covering all five projects.
Data Collection Procedure.
We conducted structured interviews with the participants, seven face-to-face and two via phone. The questions were categorized into (1) introduction, (2) usage and (3) benefits of agile elements (first methods, then practices), and (4) project context. The principal author conducted all interviews as follows: He explained the idea and reason behind this study, the data collection, and the guaranteed anonymity. He asked for used agile methods and agile practices. He discussed about the experienced impacts, mainly benefits of the different elements. During the gathering of the benefits, we were open to any mentioned benefits. If they had no idea, we named potential benefits as triggers. For not biasing them, the interviewees had to give examples for these benefit triggers. We ended up in a coded list of the benefits (cf. Table 2).
Analysis Procedure.
We analyzed the notes of the interviews qualitatively. First, we extracted the data from each interview (usage of agile elements, where and how, and their benefits). Second, we compared and aggregated information from interviews related to the same project. Third, we compared the project-aggregated results among each other and with our experience and literature.
4 Results
We covered different team sizes and developed functions and considered different roles of the interviewees: group leaders, department leaders, project leaders/managers (cf. Table 1). Two participants performed the Scrum Master role.
4.1 RQ1: Usage of Agile Methods and Practices
Four Agile Methods were used by the projects: Scrum (n = 4 projects), Flow (n = 2), iPeP (n = 1), and SAFe (n = 1). The practices that were used in all five projects belong to Scrum, namely Sprint, Backlog, Sprint Planning, and Daily Stand-Ups, although one project reported that it is not using Scrum. The practices that were used in most projects were Sprint Review, Sprint Retrospective, Burndown-charts, Definition of Done, Scrum Master, and Product Owner (PO) (all Scrum), and User Stories and Epics (both XP). Continuous Integration, Release Planning and Scrum-of-Scrums completed the set. The practices that were used in few projects were: Planning Poker and Pair Programming (both XP), 80%-rule and Pull-system (both Lean/Flow), and Backlog Grooming (Scrum). In Table 2, we show the use of agile practices.
4.2 RQ2: Deviations of Agile Practices
The used practices are now discussed regarding their deviations from existing guidelines, e.g. the Scrum Guide:
The major issue of the Scrum Master was the manifestation as “caretaker”, e.g. in one team the Scrum Master was only inviting for the different Scrum meetings. Further, often the Scrum Master was not the only role. Being a project leader or a PO in combination might result in a conflict of interests. The PO also deals with the aspect of several roles by one person without problems. But some teams defined an additional “feature responsible”, which covered POs tasks, e.g. breaking down the features into Stories. Finally, within one project, they struggled with the issue of having a Chief-PO communicating with the customer high-level, but not knowing the requirements in detail.
The most deviating aspect of sprints was their length. For one project (needing four weeks) more than two weeks were necessary for the integration of hardware aspects. Another one worked with varying lengths over time.
The Scrum-of-Scrums meetings conducted weekly by the larger teams or projects was in one case a team-meeting in which all project members participated. In another case, it was conducted by the project lead to keep the offshore team on track.
The Daily Stand-Ups deviated in three different aspects: (1) Usage only for status-tracking purpose, (2) Meetings lasting up to one hour, (3) Frequency of the meeting: Instead of every day, teams conducted it every other day, every three days, once a week, or unregularly. An extended duration of the meeting (one hour) was the consequence.
Sprint Planning: Within the sprint shift (Review, Retrospective, and upcoming Planning), most of the teams performed all three meetings en-block in about three days. In one of the larger teams, they found a solution to break down the Backlog to the teams by the PO. The planning itself was conducted within the single teams without the PO.
Sprint Review: The composition of meeting participants ranged from meetings without the customer and only with the team leaders and functional owners up to an “open event”. Some meetings were unstructured without agenda or open topic list. Others were not conducted as an “acceptance meeting” with stakeholders or PO.
Sprint Retrospective: This meeting varied within the timing: One team performed it every other sprint, because two weeks were too short to resolve impediments. Another team directly resolved smaller impediments during the meetings. One interviewee mentioned that the retrospective was only weakly defined and valued within their team.
Within the Backlog, two major variations existed: Some included prioritization, whereas other did not. Different backlogs were used, from team-, project- or overall backlogs up to release backlogs. These kinds also contained various backlog items, e.g. User Stories vs. Epics. Two teams did not use User Stories as prescribed by the given templates, since they were not used to it and needed more information.
Planning Poker: One team used this practice for estimating the granularity-level to refine the story or not. Furthermore, not all teams used “story points” as values, but e.g. person hours or days. Finally, one deviation was that in one team just the “key player” (a senior developer or feature responsible) decided on the estimation value.
Within the 80%-Rule, one interviewee mentioned that they are not considering it for the workload, but on their throughput. In the only case using the pull-principle, the responsibility regarding the different functions was clear such that it was “obvious who is going to pull what”. Thus, sometimes one team member just “assigned” the tasks.
4.3 RQ3: Benefits of Agile Practices
Most of the considered agile practices are beneficial for planning (10 practices) and transparency (8), followed by structuredness (4), communication, risk management, satisfaction, and team empowerment (each 3). Checking the overall number of addressed benefits per practice (cf. Table 2), e.g. the highest with five is the sprint, three yield four benefits, and five yield three benefits.
Except for the Definition of Done and the Backlog Grooming, we could gather at least one impact for each of the Scrum practices. Considering the Scrum meetings, except the retrospective, all impact planning. Sprint Review as well as the Stand-Ups also influence communication and transparency. The Sprint Retrospective was the only practice dealing with feedback and knowledge transfer. The Burndown-Chart is a quite good mechanism for transparency. Both Scrum roles impact the team empowerment. The improved satisfaction resulting from the Scrum Master correspond with that. The PO provides transparency as well as planning aspects. Considering the Non-Scrum practices, there is information about the impact of six practices: Risk management, planning and structuredness were impacted by the 80%-Rule. Planning Poker increases planning and team empowerment. User Stories and Epics influence planning (Epics) or focusing (User Stories). Continuous Integration improves transparency and time-to-market. Finally, Scrum-of-Scrums was quite good for communication and it affects transparency, structuredness, and planning.
5 Related Works and Discussion
Distribution/Frequency of Agile Practices.
Within VersionOne [12], the most used agile practices were Daily Stand-Ups, prioritized Backlogs, short Iterations (=Sprints), Retrospective, Iteration Planning, and Release Planning. All of them were used by at least one project, except for the Release Planning. For the other practices mentioned by [12], there are some differences: The Sprint Reviews are used less often than in our study, whereas, Continuous Integration is more common. Focusing on agile practices, Kumos [9] reports that almost all of the top six used agile practices are Scrum practices, all used by the Bosch projects. Scrum is also the prevalent agile method in automotive [8]. Similar to our results, the Planning, Daily Stand-Ups, Review, and Retrospective are used. We cannot confirm that the Sprint Review is used less often. In our study it was the Retrospective.
Deviations of Agile Practices.
A prior study on Scrum variations [1] showed similar patterns, with the Scrum Master and PO given to people already owing a role, e.g. developer or team lead. However, within our cases most of the Scrum roles were staffed. Considering the 15–30 min of the Daily Stand-Ups, this timeframe is exceeded by some cases and extended up to one hour. The frequency deviation of the Stand-Up is also common [1]. For the sprint length variance from two to four weeks could be confirmed. Only one project reasonably decided to have four weeks due to synchronizations of teams and disciplines such as hardware and software.
Benefits of Agile Practices.
Considering the benefits reported by [12], we see some similarities: The benefits increased team productivity, improved project visibility, increased team moral/motivation, better delivery predictability, and reduced project risk can directly be mapped to the ones reported to us. In contrast, the benefits dealing with engineering and quality, such as enhancing software quality, software maintainability, or improving engineering discipline, were not mentioned within our interviews. Compared to [9], five of nine benefits were also mentioned by our participants: transparency, customer orientation, timing, teamwork, and employee motivation. The results of [9] (similar to [12]) additionally showed quality as highly impacted, not indicated by our results.
Besides these studies, there are some practices studied in detail with their different impacts, e.g. User Stories [4], Planning Poker [5] or Pair Programming [7]. Furthermore, some studies analyzed which agile practice influence one specific benefit, e.g. [10] dealing with communication: Daily Stand-Ups improve communication and transparency, due to keeping developers, project leaders, and customers aware of the status. Iteration Planning created awareness of the project plan and iteration goals, whereas the Retrospective was a good way for working on process improvement. Even if we consider the benefits on a more fine-granular level, the results confirm each other.
6 Validity of the Results
An interview guideline and data collection sheet eased aggregation and comparisons. The guideline reduced the risk of misinterpretation and increased the objectivity. We could not recognize any misunderstanding, since all interview participants were aware of the common concepts, methods and practices. Additionally, we experienced that assuring anonymity led the interviewees to answer openly. Regarding the interviewed people within a project, we selected independent ones (not from the same team). Thus, our data is a representative sample of agile development in the area of autonomous driving. Within the data analysis, the aggregation of interview data within one project was the most difficult and error-prone, because of considering different project roles and teams with their viewpoints into one data set. The IESE and Bosch team discussed the aggregated results involving colleagues for an external point of view. We provided a summary report of the results via e-mail and gathered the feedback. We also performed a presentation and discussion session with all participants. That our qualitative results from Bosch CC are in line with most of the related work is another strong indicator for their validity.
7 Conclusions and Future Work
Within this paper, we present the results of an interview series covering five different automotive projects at Bosch CC with overall nine interviews on the topic of usage, deviation, and benefits of single agile practices.
The usage of agile methods as well as the underlying agile practices shows a similar picture as common studies. The most commonly used method is Scrum, which is adapted and extended by other practices. There seem to be similar variations of agile practices in the automotive domain as in information systems. Our study could confirm some of the benefits mentioned by other agile surveys, and could provide further answers to the question, which agile practice provides what specific benefits, and furthermore, that agile practices overall are most beneficial for transparency and planning.
Within future work, we intend to use the elicited data to instantiate the Agile Capability Analysis [2] for Bosch CC, a goal-oriented SPI approach using agile practices. The next step will be the integration of A-SPICE® and connection to the agile practices.
References
Diebold, P., Ostberg, J.-P., Wagner, S., Zendler, U.: What do practitioners vary in using scrum? In: Lassenius, C., Dingsøyr, T., Paasivaara, M. (eds.) XP 2015. LNBIP, vol. 212, pp. 40–51. Springer, Cham (2015). doi:10.1007/978-3-319-18612-2_4
Diebold, P., Zehler. T.: The agile practice impact model. In: Proceedings of ICSSP 2015. ACM (2015)
Diebold, P., Zehler, T.: The right degree of agility in rich processes. In: Kuhrmann, M., Münch, J., Richardson, I., Rausch, A., Zhang, H. (eds.) Managing Software Process Evolution, pp. 15–37. Springer, Cham (2016). doi:10.1007/978-3-319-31545-4_2
O’hEocha, C., Conboy, K.: The role of the user story agile practice in innovation. In: Abrahamsson, P., Oza, N. (eds.) LESS 2010. LNBIP, vol. 65, pp. 20–30. Springer, Heidelberg (2010). doi:10.1007/978-3-642-16416-3_3
Haugen, N.: An empirical study of using planning poker for user story estimation. In: Proceedings of AGILE 2006, pp. 23–34. IEEE (2006)
Hirz, M., Dietrich, W., Gfrerrer, A., Lang, J.: Overview of virtual product development. In: Hirz, M., Dietrich, W., Gfrerrer, A., Lang, J. (eds.) Integrated Computer-Aided Design in Automotive Development, pp. 25–50. Springer, Heidelberg (2013)
Hulkko, H., Abrahamsson, P.: A multiple case study on the impact of pair programming on product quality. In: Proceedings of ICSE 2005, pp 495–504. ACM (2005)
Kugler Maag CIE. Agile in Automotive – State of the Practice (2015)
Kumos, A.: Status Quo Agile 2014. University of Applied Science Koblenz (2014)
Pikkarainen, M., Haikara, J., Salo, O., Abrahamson, P., Still, J.: The impact of agile practices on communication in SW development. ESEJ 13(3), 303–337 (2008). Springer
Shen, M., Yang, W., Rong, G., Shao, D.: Applying agile methods to embedded software development: a systematic review. In: Proceedings of SEES 2012, pp. 30–36. IEEE (2012)
VersionOne: The 10th annual State of Agile Report (2016)
Acknowledgements
We thank all interviewees for their time, participation, and openness. We also thank A. Schmitt, T. Zehler, S. Theobald and Dr. P. Fröhlich for providing feedback.
Author information
Authors and Affiliations
Corresponding author
Editor information
Editors and Affiliations
Rights and permissions
Open Access This chapter is licensed under the terms of the Creative Commons Attribution 4.0 International License (http://creativecommons.org/licenses/by/4.0/), which permits use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license and indicate if changes were made.
The images or other third party material in this chapter are included in the chapter’s Creative Commons license, unless indicated otherwise in a credit line to the material. If material is not included in the chapter’s Creative Commons license and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder.
Copyright information
© 2017 The Author(s)
About this paper
Cite this paper
Diebold, P., Mayer, U. (2017). On the Usage and Benefits of Agile Methods & Practices. In: Baumeister, H., Lichter, H., Riebisch, M. (eds) Agile Processes in Software Engineering and Extreme Programming. XP 2017. Lecture Notes in Business Information Processing, vol 283. Springer, Cham. https://doi.org/10.1007/978-3-319-57633-6_16
Download citation
DOI: https://doi.org/10.1007/978-3-319-57633-6_16
Published:
Publisher Name: Springer, Cham
Print ISBN: 978-3-319-57632-9
Online ISBN: 978-3-319-57633-6
eBook Packages: Computer ScienceComputer Science (R0)