EN 
DE Good – but for different reasons than your manager believes.
Authors: Dr. Joachim Schlosser, Martin Hillbrand, Elektrobit Automotive GmbH
Contribution – Embedded Software Engineering Congress 2017
Agile – what exactly is it? Agile development sounds effortless. And indeed, agile development helps achieve better results faster. However, it's also true that the process is more rigorous than what you're probably experiencing today. Scrum is stricter with regard to management and requires a functioning integration and testing process, especially in embedded systems.
The first agile value is "Individuals and interactions over processes and tools." To give greater importance to people and interactions in daily work, it is crucial that functioning processes and tools are in place and used naturally.
Agile sounds innovative, as does Scrum with its user stories and collaboration.
The agile principle of embracing change often sends customers and upper management in development organizations into rapturous euphoria. After all, it promises the possibility of tackling changes mid-project without disgruntled project managers, all with the blessing of the Agile Manifesto and a framework called Scrum. Really? If your organization truly wants to succeed with Scrum, it's time to take a closer look. The process is likely far more rigorous than your current approach. Scrum is also stricter with management outside of the team. Furthermore, Scrum is more demanding at the outset than your current integration and testing process, especially for embedded systems.
Mindset
Much has already been written about the agile mindset, for example in the Agile Manifesto [1]. The principles behind Scrum are the same as described in the Agile Manifesto:
„"We are discovering better ways to develop software by doing it ourselves and helping others do the same. Through this work, we have come to appreciate these values:"
- Individuals and interactions more than processes and tools
- Working software is more important than comprehensive documentation.
- Collaboration with the customer goes beyond contract negotiation
- Responding to change rather than following a plan
That is, although we find the values on the right side important, we value the values on the left side more highly.“ [2]
We often find good approaches and motivation, but just as often, the reception within teams focuses solely on the four "more-than" principles. Additionally, the introduction of Scrum can lead to confusion, duplication of effort, and uncertainty, especially during the team's self-discovery phase or when collaborating with clients who are not yet using agile methodologies themselves, as described in [3].
The needs of embedded software engineering, namely the strong dependence on hardware with very price-sensitive electronic components and long lead times, are partly different.
The problems begin when teams overlook the addendum, "although we value the principles on the right." Because the agile principles mean precisely that... not, that processes, tools, and documentation are now unimportant. The preposition in the English original helps clarify this: "Individuals and interactions." over processes and tools". Over, so above.
When individuals and interactions above Processes and tools are available, then these are including and thus form the base. Individuals are more important to us, but in order for this to have space, we need helpful processes and tools.
If functioning software is more important to us, then we need including Just enough documentation so that everyone knows how the existing software and its development are progressing.
If collaboration with the customer is important to us, then we need meaningful contract negotiations to establish and shape this collaboration. Anyone who wants to meet all functional safety requirements in embedded software engineering for automotive systems must clearly define who is responsible.
Especially when we want to react quickly to change, a plan that documents the original idea and the resulting objectives is a helpful foundation. In the development of embedded systems, there are framework conditions that are best addressed in a plan.
Planning replaces chance with error. And the team can learn from error. [1].
The Agile Manifesto is often used as a weapon against all traditional methods. However, the Agile Manifesto is much more than that: it shows a way to place even greater emphasis on success, beyond all traditional approaches, as a result of people collaborating in a changing world.
Infrastructure 1 – DevOps
Scrum states that the cross-functional team should operate almost autonomously, defining its own processes and methods in a way that best suits the project. And yes, with completely stable teams, this can indeed work. In reality, however, companies face employee turnover, meaning new team members are constantly joining. Often, projects are so large that multiple teams work on them, further increasing the likelihood of new team members.
If the team wants to deliver working software on a regular basis, then frequent testing of the software's functionality is essential. This is where "Continuous Integration" and "Nightly Builds" come into focus. Within a suitable infrastructure, these methods automatically retrieve code and other artifacts from a version control system, build the software, and test it extensively.
Although Scrum allows each team to self-organize and determine its own infrastructure, it is essential to ensure that, that Each team uses a functioning build infrastructure. Teams that cannot or do not want to provide their own infrastructure should have access to an existing one.
Creating a project and build infrastructure is not something a developer can accomplish in just an afternoon. Taken together, the build infrastructure, with everything that goes with it, constitutes the Development Operations, in short, DevOps [4]. Without claiming to be exhaustive, this requires:
- Version control system, e.g. Subversion [5], Git [6]
- Ticket system, e.g. Jira [7], Trello, Leankit, Kanbanize
- Build server, e.g. Jenkins [8]
- Deployment automation, e.g. GoCD [9]
- Tool for Static code analysis, e.g. Polyspace [10], Klocwork [11], which run both on the build server and locally for the developers
- Tool for Code Coverage, e.g. Bullseye [12]
- Test automation, framework depending on the technology used
- Branching-strategy so that new feature developments can be developed without risk [13]
- Fully automated reporting. Nobody should have to manually compile statistics and statuses.
- Multi-stage Integration and merger processes on the build server to merge branches [14]
- Sandbox system e.g. Docker [15], so that everyone has the same reproducible environment
- Role definition for Test Manager, Integration Manager, Release Manager, Build Manager
In addition to functioning tools, it's crucial that team members with knowledge of the aforementioned systems and processes remain involved in the project to adapt appropriately to changes. This highlights the importance of Scrum's requirement for cross-functional teams: the individual in question must be and remain part of the project; otherwise, delays will inevitably occur. For large projects with multiple teams, a DevOps team can indeed be the most helpful solution. To counteract the problems of staff turnover, the necessary expertise is ensured by an entire team of knowledgeable individuals. However, this DevOps team must be directly integrated into the development teams. Because it's also clear: the infrastructure must run reliably; it serves as the production system.
Because in Scrum, the following applies: „There is no testing phase. There is only a development phase, which includes testing activities.“ [3, p. 228] The same applies to system software releases: „Releasing must become a standard process that runs completely silently.“ [3, p. 230]
Infrastructure 2 – Embedded Hardware
Another challenge in building the infrastructure becomes clear when considering how to get to the target platform as quickly as possible. Because, in the context of embedded systems, "working software" in the Agile Manifesto should actually be called "a working system."„
Embedded hardware is somewhat brittle to handle, and that's not due to the material of the circuit boards. Anyone developing mechatronic hardware has to consider lead times for circuit board layouts, delivery times, and the availability of current processors.
A functioning system does not necessarily have to be the real-world unit of software, hardware, and mechanics. The functioning system can also be built as a simulation, which allows for the early testing of actual customer benefits [16]. Frameworks such as AUTOSAR are particularly helpful in allowing functionalities to be considered separately from hardware within a simulation [17]. However, caution must be exercised against ill-considered modeling and ill-advised simulation. Setting up simulations that do not provide the necessary insights can be very time-consuming and costly [18].
Successively, pure software simulation methods such as Processor-in-the-Loop (PiL) and Hardware-in-the-Loop (HiL) are added to incorporate concrete effects of processor architecture, ECU hardware, and the mechatronic environment into the automated tests. All the requirements of the DevOps infrastructure still apply: only what can be tested automatically allows the team to deliver a system version at a fixed pace.
The system's architecture can play a further role. Cleanly defined modules – whether as microservices [19] or AUTOSAR components – allow them to be developed, tested, and deployed independently.
All these frameworks and procedures may seem to restrict the freedom of the teams, but in reality they provide more freedom in solving the actual task, provided the framework conditions are known and remain relatively stable.
Manager and introduction of Scrum
Scrum doesn't just affect the development team(s). Scrum affects the entire organization. Even if only parts of an organization actually work according to Scrum, everyone who interacts with these teams should understand what Scrum means.
This applies especially to managers. Scrum explicitly stipulates that work is done in sprints, i.e., development phases lasting a few weeks, at the end of which a working system is delivered to the customer.
After each completed sprint, the requirements for the next one are planned. It's important to note: While of the sprint Requirements remain stable. So, no manager comes in and suddenly gives the developers something else to do. If new requirements arise during a sprint, they are generally not integrated into the current sprint but go into the product backlog. If there are frequent instances of requirements planned for the current sprint suddenly becoming obsolete, this is an implicit request for the Scrum Master and Product Owner to consider better requirements and align them with the customers.
The primary task of the Scrum Master is therefore to protect the team from external organizational interruptions. The leadership of an organization should support these efforts as much as possible by... not does not interfere with the running gearbox, but uses the sprint cycle to feed in changed situations and requirements.
Introducing Scrum solely through team training is therefore insufficient. Training for managers in adjacent organizational units is also explicitly required.
Being agile means that we need to change the entire organization towards a structure that enables project outcomes and is focused on value creation. This does not mean that every department needs to use agile methods, but they should understand their role in the agile organization [20].
The introduction of Scrum has a beginning, but due to the nature of self-organization, it has no end. Changing framework conditions and project environments will be reflected in changes to Scrum implementations. Your manager will have to get used to the fact that they are not dealing with a static development process that is defined once and then remains unchanged indefinitely.
Summary
Agile methodologies in embedded software engineering are not a given. Enabling teams to deliver regularly and efficiently through good infrastructure, and providing them with methods that address the specific needs of embedded systems, is a solid foundation. If managers then allow the teams to work undisturbed, success is almost guaranteed.
At Elektrobit, we have successfully guided large parts of our own development organization, as well as renowned customer organizations in embedded software engineering, through the transition to agile methodologies, and we are constantly learning. Contact us.
Bibliography
| [1] | J. Sutherland and J. Sutherland, Scrum: The Art of Doing Twice the Work in Half the Time, UK: Random House Business Books, 2014. |
| [2] | W. Cunningham and others, „Manifesto for Agile Software Development“, 2001. [Online]. Available: https://agilemanifesto.org/iso/de/manifesto.html |
| [3] | B. Gloger, Scrum: Developing Products Reliably and Quickly, 5th edition ed., Munich: Carl Hanser Verlag, 2016. |
| [4] | G. Kim, J. Humble, P. Debois, J. Willis and T. Demmig, The DevOps Handbook, Heidelberg: O'Reilly / dpunkt.verlag GmbH, 2017. |
| [5] | B. Collins-Sussman, BW Fitzpatrick and CM Pilato, „Version Controll with Subversion,“ 2017. [Online]. Available: https://svnbook.red-bean.com/index.de.html |
| [6] | S. Chacon and B. Straub, Pro Git book, US: Apress, 2009. |
| [7] | M. Doar, Practical JIRA Administration, UK: O'Reilly, 2011. |
| [8] | „Jenkins Handbook,“ [Online]. Available: https://jenkins.io/doc/book/. [Accessed 11 10 2017]. |
| [9] | „GoCD: Open Source Continuous Delivery and Automation Server,“ [Online]. Available: https://www.gocd.org/. [Accessed on 11 10 2017]. |
| [10] | „"Polyspace. Making Critical Code Safe and Secure," MathWorks, [Online]. Available: https://de.mathworks.com/products/polyspace.html. [Accessed on 11 10 2017]. |
| [11] | „Klocwork: Source Code Analysis Tools for Security & Reliability,“ [Online]. Available: https://www.klocwork.com/. [Accessed on 11 10 2017]. |
| [12] | „BullseyeCoverage Code Coverage Analyzer,“ [Online]. Available: https://www.bullseye.com/. [Accessed on 11 10 2017]. |
| [13] | P. Hodgson, „Feature Branching vs. Feature Flags: What's the Right Tool for the Job?,“ May 23, 2017. [Online]. Available: https://devops.com/feature-branching-vs-feature-flags-whats-right-tool-job/. [Accessed on 11 10 2017]. |
| [14] | W. Buchwalter, „A Git Workflow for Continuous Delivery“, June 21, 2016. [Online]. Available: https://blogs.technet.microsoft.com/devops/2016/06/21/a-git-workflow-for-continuous-delivery/. [Accessed on 11 10 2017]. |
| [15] | „Docker – Build, Ship, and Run Any App, Anywhere,“ [Online]. Available: https://www.docker.com/. [Accessed 11 10 2017]. |
| [16] | J. Schlosser, „Early verification of control systems with model-based design“, in Embedded Software Engineering Conference, Sindelfingen, 2011. |
| [17] | J. Schlosser and G. Sandmann, „No fear of AUTOSAR – a guide and benefits analysis for function developers“, ATZelektronik, Vol. 4, No. 2, pp. 66-72, 2009. |
| [18] | J. Schlosser, Architectural simulation of distributed control unit systems, Berlin: Logos Verlag, 2006. |
| [19] | T. Schneider, „Achieving Cloud Scalability with Microservices and DevOps in the Connected Car Domain,“ in Software engineering (workshops), Vienna, 2016. |
| [20] | M. Hillbrand, „Agile methods scale, but please not dogmatically! Scaling successfully!“, OBJECT spectrum, No. 2, 2017. |
| [21] | W. Cunningham, „Manifesto for Agile Software Development“, 2001. [Online]. Available: https://agilemanifesto.org/iso/de/manifesto.html. |
authors
Martin Hillbrand Martin Hillbrand has over 10 years of experience in software engineering and process optimization across various industries, and supports Elektrobit's client organizations in implementing agile methodologies. He studied software engineering and information engineering and management at the University of Applied Sciences Upper Austria. Martin Hillbrand is a certified Scrum Master, Product Owner, and Scrum Professional.
Dr. Joachim Schlosser At Elektrobit Automotive in Munich, he leads computer scientists and engineers who advise automotive manufacturers and suppliers on agile development methods, functional safety, and software architecture. After earning his doctorate in computer science from the Technical University of Munich, he worked for over 10 years at MathWorks, the maker of MATLAB & Simulink. He blogs at www.schlosser.info
Software Engineering Management – our training courses & coaching sessions
Do you want to bring yourself up to date with the latest technology?
Then find out more here MircoConsult offers training courses/seminars/workshops and individual coaching on the topic of Software Engineering Management / process, project and product management.
Training & coaching on the other topics in our portfolio can be found here. here.
Software Engineering Management – Expertise
Valuable expertise in software engineering management / process, project and product management is available. here Available for you to download free of charge.
You can find expertise on other topics in our portfolio here. here.
