EN 
DE 
Embedded software in current projects is mostly developed using an agile approach of some sort. The biggest hurdles to truly agile development are primarily security requirements, existing system processes based on the V-Model XT, the difficult-to-assess risk of transitioning to a new development process, and, above all, its integration.
Those who want to develop in an agile way, but cannot switch due to security requirements or are still hesitant to take the plunge, can still benefit from agile advantages and gain experience in agile thinking through the ideas presented here for an iterative traditional process.
Agile values, principles and methods
To delve deeper into the benefits of the agile movement, it is essential not only to act agilely, but also to embrace the agile paradigm with one's attitude and mindset.
„"You don't develop agilely, you are agile."“
Those who heed this principle will reap the benefits of all four agile values of the Manifesto for Agile Software Development [1] even in traditional development, regardless of the domain, i.e., also in the hardware and the overall system. The four agile values are:
Fig. 1: The four agile values of the Manifesto for Agile Software Development
Positive effects of the four agile values can also be achieved in the traditional development environment as follows:
Individuals and interactions more than processes and tools
It is people who create innovative and complex solutions. Consequently, people should be at the heart of development projects. Changing the process rather than the users is more promising and simpler, as long as a structured and orderly approach is ensured. The development process should provide a framework and structure the work, but not be patronizing or perceived merely as an additional burden. Simply eliminate unnecessary process steps or simplify them to the extent that the requirement for process quality allows.
Working software is more important than comprehensive documentation.
Contrary to the common misconception that documentation is unimportant in agile processes, the focus should be on what matters most. The actual product takes center stage. To ensure the product also meets non-functional requirements such as testability, maintainability, and modifiability, appropriate documentation is essential. Invest more effort in the important documents, which should then be kept up-to-date and always reflect the implemented product solution, and simply omit less important documents. Alternatively, create simplified versions to meet formal process requirements.
Collaboration with the customer goes beyond contract negotiation
Many contractual disagreements don't stem from a supposedly differing interpretation of the specifications, but rather from the fact that the client develops a clearer understanding of their requirements during the project. You can only increase customer satisfaction and loyalty if the customer receives what they truly need – regardless of their initial demands. But how do you best obtain qualified feedback early enough to allow for adjustments to the project? The agile development framework Scrum provides the Sprint Review Meeting for this purpose and the Retrospective Meeting for internal improvements. The core principles of both meetings can be implemented in a similar way in traditional development by incorporating as many short feedback loops as possible.
In the section „Agile strengths in a traditional guise“, we will discuss these topics in more detail.
Responding to change rather than following a plan
The greatest strength of agile development processes is undoubtedly their adaptability and speed. Traditional processes quickly reach their limits in this regard. Who isn't familiar with the following scenario? The planning is complete, the high-level and detailed concepts are finished, the product may even be in the middle of development – and now a change is expected. Traditional processes employ a change request procedure to assess the necessary changes and integrate them into development. A project manager will typically spend a significant amount of time on these activities, and project delays often arise due to the sheer number and complexity of change requests. The most efficient way out of this dilemma is iterative development, including continuous integration and at least partial test automation.
Even in the project planning phase, the product development is considered in several successive stages. Each stage progresses through the process from detailed planning to implementation, integration, and testing, similar to a change request. The significant effort required for late changes can be minimized by implementing these changes in a stage that was already planned. The question of whether a less important feature can be omitted to achieve this is a business decision, independent of the development process.
Integration in the V-model
On the one hand, there is agile development with small, incremental steps, each planned one after the other and potentially implemented in tiny micro-steps using test-driven development. On the other hand, in traditional processes, a product always goes through the process steps as a whole. In technically complex projects, traditional development uses prototyping to explore solutions and achieve greater planning certainty.
According to pure theory, the prototype should be discarded and the product redesigned. But everyone knows that prototypes have the longest lifespan. The result is usually a poor architecture, which was only intended for the prototype and drives up the costs for expansions and maintenance.
Fig. 2: Agile approach to software implementation in the V-model
So why not turn necessity into a virtue and develop the product iteratively using the V-model? The magic word is refactoring. Instead of discarding prototypes or accepting poor architecture, the refactoring method involves reworking the prototypes until they evolve into functional increments with clean architecture, allowing the product to grow. These functional increments are considered in the project planning from the very beginning.
If the detailed specification isn't created all at once, but rather allowed to grow iteratively with each functional phase, flexibility increases further. Change costs decrease, and the alignment of the documentation with the implemented solution improves. To achieve this, the detailed specification should be developed in two stages. In the first stage, the design is described relatively superficially, laying the foundation for the subsequent refinement steps. The second stage is divided into the aforementioned functional phases, thus ensuring an iterative deepening of the specification. In terms of the model, you create a new revision of the document for each functional phase.
To ensure you receive valuable, high-quality feedback from the client/user during development, take advantage of the agile approach and repeat the integration and testing phases of the process multiple times for each functional iteration.
This requires continuous integration, automated unit testing, and at least semi-automated system testing. Similar to agile iterative processes, you receive a potentially shippable product increment after each feature rollout. In practice, for cost and time reasons, the quality of the product increment will be limited by less extensive testing. It is intended only as a product demo for feedback purposes. For release, the entire test program is then run in the traditional way.
Agile strengths in a traditional guise
Scrum includes a product demo at the end of each sprint during the Sprint Review Meeting. This approach can be adapted to iterative development using the V-Model. The earlier a partial functionality can be demonstrated, the easier it is to implement change requests. A good relationship with the customer, and thus the opportunity to perform demos on a development board or, ideally, early prototyping hardware with limited integrated software functionality, is particularly beneficial. Being prepared for change requests and being able to easily incorporate them into feature increments ensures satisfaction and strong motivation among all involved.
In large organizations, traditional development processes include Lessons Learned meetings, held once or twice a year, and sometimes upon reaching important milestones in a development project. These meetings pursue the same goal as retrospective meetings in Scrum: ultimately, they aim to increase productivity by seeking answers to the questions, "What went well, what went badly, what prevented us from delivering optimal results?" In agile development, these questions are consistently discussed at the end of each sprint to obtain rapid feedback.
The willingness to continuously improve is completely independent of the development process used. Following Scrum principles, feedback sessions should be conducted as frequently as possible. The end of each iterative feature lift described above is an ideal opportunity for this. Crucial to the success of these sessions is creating an environment characterized by a willingness to change, even when it is uncomfortable. Each individual must step outside their personal comfort zone and give change a chance.
Conclusion
The line between traditional and agile development is blurred. All agile values can also be leveraged in traditional development. So why should you switch to an agile approach?
Agile development is not a set-in-stone law. The will and motivation to improve things ensure constant change. This continuous change can lead to a lack of direction. Orienting oneself towards existing frameworks such as Scrum provides support and security. For example, introducing self-organizing teams and structuring them according to customer value is easier to implement in Scrum than in a modified V-model that prescribes a distribution of roles within the process steps.
In summary, the iterative traditional process outlined here must be carefully adapted to the existing environment to avoid unnecessary friction. The approach described here shows you a way to continuously increase customer satisfaction and the motivation of those involved. If desired, we would be happy to accompany you on this journey. agile training, process workshops and Project consulting accompany.
Further information
MicroConsult expertise on the topic of Agile & Scrum
MicroConsult Training & Coaching on the topic of Agile & Scrum
Bibliography and list of sources
[1] https://agilemanifesto.org
