Why Agile Struggles in Embedded Development

The Reality of Slow Agile Adoption in Embedded Development: Adoption Rates Shown by the IPA Survey

Even in the field of embedded software development, the term “agile development” has become widely recognized. It is featured in many technical articles and study groups as a method that can quickly respond to changes in required specifications. However, looking at the actual adoption status, its widespread use is still limited.

Evaluations within the industry are also not uniform. Among software-only consulting firms and experts, there is an opinion that agile development should be actively adopted even in the embedded field. On the other hand, there remains a persistent view among developers closely tied to hardware that it is difficult to apply it as is. Rather than taking a definitive stance on either side, this article examines the factors that determine success or failure depending on the conditions.

In the “Survey on Trends in the Embedded/IoT Industry for FY2022” conducted by the IPA (Information-technology Promotion Agency, Japan), only 12% of companies responded that they had adopted agile development in more than 60% of their development projects. In contrast, 34% of companies answered that they had adopted waterfall development or V-model development based on the same criteria, showing that the conventional development style is still the mainstream.

This survey was conducted targeting corporate executives and business department heads of companies involved in the embedded/IoT industry. A total of 1,214 responses were received, of which 1,077 valid responses were obtained for the question regarding development styles.

Analysis of other survey data also positions agile development as a development style in the adoption phase within the embedded software industry. In the same analysis, the use of no-code/low-code development, DevOps, and OSS is classified into the development phase, which is one step before the adoption phase, and is evaluated as still difficult to enter the adoption phase. Although agile development is more widely adopted than these, it has yet to become firmly established.

An article in the same chapter (see “Waterfall vs. Agile Development”) explains the general differences between the two methods. This article focuses on circumstances specific to embedded development and delves into why agile development is difficult to run in the field.

Understanding the true nature of this barrier is useful both for development leaders when designing processes and for quality assurance personnel when creating verification plans. The following sections examine the issues step by step, from their causes to practical compromises.

Breaking Down the Reasons It Does Not Work: Four Structural Barriers

There are four main structural barriers behind why agile development is difficult to establish in embedded development.

• Mismatch in prototype cycles: It is not uncommon for hardware prototype cycles to take several weeks to several months, including PCB design, component procurement, mounting, and operation checks. This creates a state where the cycle does not align at all with the software-side 1-to-2-week sprints.
• Cannot verify value without the actual device: Even if working software is completed every sprint, its true value cannot be verified without the actual device to run it on. Screen-based simulations alone cannot verify the effects of the actual environment, such as sensor responses, vibrations, and temperature changes, making it difficult to demonstrate operation and obtain feedback during reviews.
• Cannot be fixed after mass production: Many products cannot have their PCBs or enclosures modified after mass production. For molded enclosures or devices with firmware that cannot be rewritten on-site, the premise of “fixing it later” is difficult to establish, requiring extensive upfront development.
• Documentation load for certification compliance: In areas where compliance with safety standards and certifications is required, preparing traceability documents that can track the development process is essential. It is necessary to record the relationships between requirements, design, and testing, which is not compatible with an approach that changes specifications with each iteration.

These four factors are not independent but are intertwined, making it difficult for development teams to respond flexibly. A chain reaction can easily occur: delays in prototyping lead to a lack of actual devices, modification constraints after mass production require more rigorous upfront specification development, and documentation for certification compliance further raises the hurdle for changes. The overall picture of constraints common to embedded development is also covered in articles in other chapters (see “Constraints in Embedded Development”).

• View PDF for details

Compatibility Between Agile and Products That Cannot Be Fixed After Mass Production: A Structure Where Feedback Is Hard to Obtain

Agile development is based on the premise of first building something that works, receiving feedback, and then fixing it. For products that are completed entirely in software, this premise is easily established, and modifications after release can be made at a relatively low cost.

However, many embedded devices cannot easily have their internal software rewritten after shipment. For products with fixed sensors or control circuits, or devices without communication capabilities, design changes after the start of mass production may be virtually impossible. Even if there is a means of rewriting, the on-site update work itself is costly and time-consuming.

For products that require compliance with functional safety standards, such as medical devices and industrial robots, the impact of each change must be reassessed. This high evaluation cost is one of the reasons why planned development is well suited to such products.

The process of building in a design that prevents rework in advance is explained in an article in the same chapter (see “Development Overview and Rework-Free Design”). The constraint of not being able to make corrections after mass production underscores the importance of that process.

From a quality assurance perspective, postponing the testing process is also risky. Even when adopting agile development, the comprehensiveness of verification must not be sacrificed.

A Realistic Compromise: Layer-Based Hybrid Development

What works in embedded development is neither pure agile development nor pure waterfall development. Hybrid development, which uses both approaches for different layers, is spreading as a realistic compromise.

Areas such as board design, circuit configuration, and selection of production parts, where hardware specifications are fixed, are carried out systematically using a waterfall model. The higher the cost of specification changes, the more suitable an approach that emphasizes requirements definition and design reviews in the earlier stages is.

On the other hand, user interfaces such as display screen layouts, setting menus, and how communication logs are displayed, the application layer, and the upper parts of communication protocols are areas with relatively low dependence on actual devices. This layer is highly compatible with an iterative approach, allowing specifications to be refined while adding functions in short cycles.

In development sites that actually adopt a layer-based approach, the application layer alone may be designed iteratively in advance, even before the hardware is finalized. This has the advantage of allowing early verification of UI usability and the validity of setting items without waiting for the hardware to be completed.

The boundary line separating the layers requires individual judgment for each product. Drawing the line based on the extent to which hardware specifications are finalized and the magnitude of modification costs is a realistic approach. Care must be taken, as mixing both methods without clarifying the boundary can lead to confusion.

• View PDF for details

Prerequisites for Running Sprints: An Environment Where Testing Can Be Done Every Time

Even if a layer-based process is adopted, there is a prerequisite for iterative development to function in the application layer. The prerequisite is a test environment where operation can be verified at the end of every sprint.

If there are not enough actual devices, sprints cannot be run in parallel for all development team members. Situations where teams cannot start the next iteration because they are waiting for prototype completion, or where multiple teams compete for a limited number of actual devices, also occur frequently.

If sprints are introduced only formally without a proper test environment, tasks that cannot possibly be verified will pile up, which could result in lowering team morale. Before deciding on sprint length, it is necessary to check whether a verifiable environment is in place.

A lack of test environments also directly affects the ability to implement automated testing. In a system that relies on manual verification on actual devices, verification work piles up with each sprint, and development speed gradually slows down. The longer verification takes, the more the delay ripples into the next sprint planning.

Preparing an environment where testing can be performed is the starting point for running sprints, and it is worth positioning as a priority in organizational planning.

Means of Iterative Verification Without Waiting for Actual Devices: The Option of Simulated Environments

To overcome the barrier created by a shortage of actual devices, there is a technique spreading in development sites. This method uses a mechanism to simulate the inputs and outputs of connected devices and sensors via software—so-called emulation—to verify software operation even without actual devices.

If sensor signals, outputs to actuators, and communication interface responses can be simulated, iterative verification can proceed without waiting for the completion of prototypes. It also becomes possible to intentionally generate unexpected inputs or abnormal values to verify operation, preventing the prototype waiting period from leading to sprint stagnation.

Such simulated environments are also effective for products that cannot be modified after mass production. Because defects can be identified early under conditions close to actual devices, the accuracy of building in quality before mass production increases, and verification records required for certification compliance can be accumulated from an early stage.

Although preparing simulated environments incurs initial costs, it offers the expected benefit of keeping sprints running without stopping. Even if the barrier of hardware dependency cannot be completely eliminated, it is worth considering as a means to reduce its impact.

This does not mean that the final verification using actual devices itself can be omitted. Simulated environments are merely an aid to keep the iteration cycle running, and final verification using actual devices must always be incorporated before mass production.

• View PDF for details

Summary

Behind the struggle to run agile in embedded development lie structural barriers such as hardware prototyping cycles, modification constraints after mass production, and certification compliance. A realistic solution is a layer-based approach in which hardware-related areas with fixed specifications are developed using a waterfall approach and the application layer proceeds iteratively, along with creating an environment where verification can be performed without waiting for actual devices. The key is to use them selectively after assessing the conditions.