1. Why are best practices relevant for agile software projects in the automotive industry?
According to the principle "What goes around, comes around", agile project methods have increasingly found their way back into the automotive industry in recent years. While at the beginning of the 1990s, the production of vehicles in particular was (more) agilely orientated, software development is now increasingly being implemented by using agile project methods. In Germany, around 50 % of all software projects are currently implemented using agile methods (Source, German text only). The "Scrum" project method was and is by far the most widely used agile project method.
In order to successfully implement agile projects, it is particularly useful for companies in the automotive industry – which are currently facing particular challenges – to observe best practices.
2. What is the area of tension in the automotive industry in agile projects?
Both automotive manufacturers and suppliers are faced with the tension of all large companies when it comes to using agile project methods in the context of software projects: This results cumulatively from the hierarchical personnel structure and the intern requirement to only use established processes. This is not conducive to the approach of agile software projects, as these require flat hierarchies and flexible processes that are open to adaptation, at least at the working level.
The solution to this problem is often sought by automotive manufacturers in a schematic, hybrid approach between waterfall methodology and agile project methodology, for example in the form of special GTCs for agile projects. While this often works for very small projects, this schematic, hybrid approach is unlikely to have any advantages over a purely sequential/waterfall-like approach for medium to large projects, and often even leads to increased failure of such software projects. The application of agile project methods such as Scrum is not an end in itself. It is only beneficial if certain framework conditions are observed.
3. Why does "one-size-fits-all" not work with agile project methods?
The biggest and most avoidable mistake is probably to have one and the same set of contracts – for example in the form of special general terms and conditions (“T&Cs) for agile projects – for all of a company's agile software projects. Agile project methods, and therefore also Scrum, form a framework that must always be adapted depending on the specific project requirements. The contract set-up must therefore reflect at least the following three project types/T&C sets:
- Very innovative, complex projects (the result/the success can hardly be conclusively determined at the beginning of the project), where for the most part only a service contract implementation makes sense.
- Hardly any innovative, but very complicated projects (the result/success can largely be determined at the start of the project), for which implementation under a contract for work is an option.
- Projects of medium innovation and elaborateness. Here, it often makes sense to create the MVP (i.e. the minimum target) under a contract for work and then implement special specifications under a service contract.
Almost all jurisdictions have comparable distinctions between contract types that either require "success" or only "endeavour" (endeavor means that, in legal terms, a service is owed and not a result). If a type of contract does not appear to be suitable for a company, the associated risks can often be mitigated very well by renumeration and termination provisions.
- In the case of a service contract, for example, the client's interest in budget control can be met via a shard risk model in which, for example, the contractor's remuneration is reduced by a certain proportion after a certain target date is exceeded.
- Conversely, the interests of the contractor can be taken into account with regard to the client's ability to terminate the contract at any time. This can be done by, for example, remunerating planned resources for a certain period despite cancellation, even if this work is no longer required (but the resources are blocked).
4. Why do Scrum and programming specifications have to be determined?
As mentioned, agile project methods are only "frameworks". Consequently, every company has a different understanding of what software development in the Scrum process looks like. It is therefore essential that the specific agile project approach is set out in the corresponding contract/T&Cs (i.e. specification of the roles, artefacts and events). Automotive manufacturers in particular will tend to use hybrid forms of agile project methods, which also contain waterfall-like elements, as part of the application of Scrum. This is not necessarily a negative aspect, but it must be communicated clearly enough to the contractual partner in advance – which is usually best done in the contractual provisions.
In addition, it often makes sense to agree on specifications regarding the programming procedure. On the one hand, because this also specifies the success within the framework of a contract for work, and on the other hand, because this can also have a considerable impact on the schedule and budget. There should be at least a basic level of common understanding in advance as to whether "pair programming" is envisaged, which tests (e.g. unit, integration, system tests) will be carried out, what form code reviews will be conducted, etc. If different programming standards are only identified during the course of the project, subsequent adjustments can lead to avoidable project delays.
5. What role does change management play in agile projects?
For every agile project, it is also necessary to define the specific change management. Agility works best and is therefore chosen so that changes in the project (new or different requirements) or in the project environment (the market has changed) can be taken into account promptly enough in the next iteration. The automotive industry in particular is currently exposed to many rapidly changing global factors. Project managers should therefore be aware of the outset of which changes should be considered "on the fly" and for which changes a more formalized process makes sense. Addressing this at an early stage also serves to identify potential project risks and, where possible, to determine optional measures to reduce these risks from the outset (for example, if too many country-specific requirements need to be implemented, it may make sense to aim for at least certain minimum standards for all countries as an alternative).
6. Why does an agile software project stand and fall with the degree of transparency?
Probably the most important subject of regulation are mechanisms and reporting obligations on key aspects of project realization compared to planned project realization. As trivial as this may sound, it is often ignored in practice. In retrospect, it is almost always recognizable at an early stage when an (agile) project gets into trouble. However, both parties often only have partial information on this, which only allows such conclusions to be drawn when viewed together.
It is therefore essential to determine which people in a project need to talk to each other regularly and what information they need. In this respect, the most important information regularly concerns
- changes/exceedances of the scope,
- lack of key resources, and
- actual velocity vs. required velocity.
7. Why is initial project support by Legal useful?
Probably the second most important factor for successful agile projects is that the agreed contractual regulations are also put into practice. It is not expedient if something is written on paper but the relevant information is not passed on to the relevant levels.
Reports on project progress in particular will not be successful (no matter how good they are) if they are ignored and, in particular, if unwise legal decisions are made on their basis. In the event of a project delay, for example, the project managers often deviate from the contractually agreed mechanisms for a project delay and then make completely different agreements in emails/meetings. With this, the client often compromises its legal and contractually secured rights and thus its leverage. Conversely, in critical project situations, contractors often make unfulfillable capacity commitments or switch to parallel sprints, which jeopardizes the overall project structure and quality.
Conclusion
It should be indisputable that agile project methods in the software sector offer significantly more opportunities than risks. However, large companies in the automotive industry in particular, which operate in a volatile environment, are well advised not to structure their processes for agile projects so schematically that the benefits of agile project implementation are jeopardized.
Many of the problems and solutions listed above are also relevant for purely internal agile software projects, albeit not in the form of contracts, but at least in form of mutual arrangements.
