Agile systems engineering from the perspective of VW and Vector employees
I recently discovered a paper published a few years ago entitled "Agile Systems Engineering", written by Christof Ebert (Vector Consulting) and Frank Kirschke-Biller (Volkswagen). Even if the authors do not explicitly address the situation at their companies, the perspectives of these people will certainly be of interest to many readers.
To say it up front: I particularly miss the aspect of extremely short development cycles and regular system tests, which I consider essential in agile systems engineering. On the other hand, the article contains useful checklists to get the agile transformation going in your own company.
The paper
The nine-page paper is available free of charge and a quick read. It was published in IEEE Software in 2021. This was before the ChatGPT hype, which is relevant in that it briefly mentions the role of Artificial intelligence is discussed. The article also deals (not very positively) with SysML. Many points of criticism, particularly with regard to formality, are addressed by SysML v2 defused. As this has been in development since 2017, it is a shame that the authors have not taken this into account.
The challenges
The paper begins with the usual statements: complexity is exploding, innovation, costs and quality have emerged as the most important short-term challenges across all industries.
The authors see a further problem in the lack of basic skills such as requirements management and traceability. They see these as a basic prerequisite for being able to start with agile systems engineering at all. I only partially agree with this statement: it is true that "agile" is sometimes used as an excuse to omit certain practices. On the other hand requirements management and traceability differ radically in agile systems engineering of these practices in traditional product development.
Four dimensions along the product life cycle
The authors emphasize that the following four dimensions must be considered across the entire product life cycle and implemented as follows for agile systems engineering:
- BusinessRequirements must have a clearly recognizable business value in order to avoid rework and ensure quality. Product catalogs with feature planning accelerate decisions and create clear development roadmaps. Systematic regression techniques facilitate agile delivery, while reusable hardware and software elements with traceability make the development process more efficient. KPIs support the management and identification of trends.
- PeopleCollaboration must be guaranteed and requires effective supply chain management based on contractually defined requirements. Efficient knowledge management and central roles such as a safety officer in scrum teams ensure coordination and compliance with standards.
- ProcessAdapted agile methods with hierarchical Scrum and test-driven approaches ensure consistency between development and validation. Regular synchronization points and flexible coordination of hardware and software deliveries enable continuous integration and delivery. A clear separation of tasks ensures transparency and better collaboration.
- TechnologyModeling, simulation and the use of digital twins enable early validation and adjustments before real systems are affected. Architecture and interface simulation as well as powerful tool chains with integration into software development tools are essential.
This list literally screams the balancing act between true agility without being too disruptive (Hierarchical Scrum?!?). This list should therefore be taken with a grain of salt, especially for small or already agile teams. The authors also discuss continuous delivery, but this is secondary to the process. There is a lack of courage here for real agile systems engineering, as practiced at SpaceX, for example.
Systems engineering perspectives
Another useful list is the table of 9 perspectives, including typical risks and mitigation tactics:
| Perspective | Relevance | Dangers and risks | Defusing |
|---|---|---|---|
| Value | The perceived value that translates the product into a viable business model | Endless feature lists without traceability to business value | Ensure traceability of requirements to a business value, a responsible person and preferably a customer. Use prioritization. |
| Behavior | Primary functions and their results, such as algorithms and their results, end-to-end | Functions are only specified for "sunshine scenarios" | Capture real worst-case functionalities. Use negative requirements, such as misuse and error scenarios. |
| Structure | Logical building blocks and their interfaces | Systems grow organically by adding content here and there | Apply periodic refactoring and architecture analysis. Use metrics such as coupling, overwriting and similar. |
| Information | System information objects and their relationships, validity and data protection | Inconsistent data and unclear validity of information | Check data objects at runtime with plausibility checks. |
| Services | Access points to trigger behaviors at runtime, including definition, discovery and orchestration | Software functions are designated as a service without the necessary orchestration | Development of a service-oriented architecture with orchestration, registry and flexible use. |
| Performance | Runtime interaction, including management to ensure robustness and availability | Runtime behavior is not taken into account, which slows down the entire system | Analysis of predictability, real-time responses and time constraints based on actual requirements. |
| Reuse | Defined variation points in the system structure | Non-maintainable, stand-alone variants | Define variation points for black box reuse to deploy systems in specific market deliveries. Maintain a master product catalog and roadmap. |
| Portability | Use of a system or product in a different context | Product components are connected to each other or to specific hardware | Assign components and products dynamically and keep them flexible. |
| Deployment | Assignment of services to software and of software to hardware components | Too specific restrictions or no consideration of hardware requirements | Specify hardware restrictions and possible deployment scenarios during the requirements analysis. |
This table also made me wonder what this has to do with agility. At best, we need to ensure that we do not neglect these perspectives in agile systems engineering.
Nevertheless, this list is also very useful. After all, these perspectives must always be taken into account in systems engineering, whether agile or not. On the other hand, this list is not new and is also INCOSE-SE manual to find.
Desired results
The third and final list in this paper can be helpful in measuring the effectiveness of measures of any kind. These are:
- ReliabilitySelf-organization reduces the coordination effort compared to the classic project management approach.
- TransparencyTransparency of the project status and therefore also of project management is improved.
- EfficiencySpeed and quality are optimized. Managers and teams recognize improvements. In particular, the early definition of requirements and the acceptance of changes during development as part of an agile process are crucial for efficiency.
- Life cycle managementThe complexity of products is better managed and controlled.
- QualityReuse and embedded quality responsibility lead to higher quality.
Well, here too there is no reference to agility. I would also have been pleased to see concrete figures from a real project.
Weaknesses
Unfortunately, the paper has significant weaknesses and even errors, especially with regard to SysML (1.x). On page 11, the authors write that "there is no uniform standard for SysML" and that "SysML models lack precise, unambiguous semantics, so that formal verification and model checking are not possible".
These statements are at least very misleading: SysML is an international, harmonized standard. In some places, the standard is ambiguous, which can indeed lead to problems. Extensions such as MARTE or UPDM can create clarity here. In addition, SysML v2 solves precisely these problems.
The biggest blunder is probably to call MagicDraw a "painting tool". I suspect the authors simply inferred the function from the name.
Conclusion
Unfortunately, a disappointing paper, at least for those who were hoping for an innovative approach to agile systems engineering. The lists and tables, on the other hand, are quite useful for any kind of systems engineering. Because even these have little to do with agility.
Photo by Martin Katler on Unsplash
