Embedded systems

Similarly, embedded systems are another field of application for agile methods outside pure software development. They are defined as specialized computer systems designed for specific tasks, that typically consist of software and hardware.

According to Könnölä et al. (2016), in developing embedded systems, usually only the software part makes use of agile development methods, while the hardware development is still exploiting traditional methods. The problem could lie in the absence of guidelines on how to organize development work on a weekly basis for such systems. The authors highlight how standards are present for hardware development, software development (as discussed in Sections 1.3.1 and 1.3.2 analyzing Scrum and XP), but no standard is set for embedded systems.

Some principles could be borrowed from the SW methods, but most of them should be reinterpreted in order to be usefully applied. As an example, the Agile Manifesto states that working software should be the primary measure of progress;

in embedded systems this parameter must be substituted with the whole system development and demonstrations of its working principle should become the measure of progress (Kaisti et al., 2014).

According to literature (Könnölä et al., 2016), the main opportunities for agile methods in embedded systems’ development are :

• System-wide understanding: better communication would foster easier agreements on the interdependencies between different sections of the system and, as a consequence, better alignment during the development phases.

• Acceptance of change: when new requirements are needed the teams would be prepared for them and would have the necessary tools to face them effectively.

• Fluent management of the interdependencies: more transparency would reduce incomprehension in case of interdependencies, thus also the presence of critical paths between different sections.

However, when trying to implement agile in embedded systems’ development, one would also face some challenges (Könnölä et al., 2016):

• Changes may affect the whole system: while agile welcomes change and tries to postpone decisions as much as possible, in embedded systems any change in the software could cause changes in the hardware specifications, and vice versa. This kind of constraints should then be addressed early enough, giving agile some space within these boundaries.

• Difficulty in delivering new versions quickly: unlike software develop-ment, hardware products can not be updated too frequently, due to the presence of systematic tasks that need to follow specific cycles (e.g., design, prototype manufacturing, testing, and verification). This aspect has to be taken into account when implementing agile.

• Team members are highly specialized: in agile development, every team member is welcomed to learn and know about every aspect of the code, instead of limiting himself on specific tasks. In embedded systems, however, usually every team member is highly specialized in one single discipline, due to their complexity. It is very unlikely to have people working both at the hardware components and at the software of the system. Nevertheless, agile could still be applied to foster transparency and help everyone understand what the others are dealing with, even if it will be impossible to reach complete cross-functionality inside the team.

Starting from these premises, Könnölä et al. (2016) performed three different case studies, applying agile methods to embedded systems design, getting feedback from the teams. The companies considered were Ericsson, a multinational company, leader in the field of communications technology; Nordic ID, a SME developing and manufacturing RFID and barcode readers; and Nextfour, another SME which develops embedded systems for medical, industrial, and safety-critical markets.

As a result of the case studies, various aspects emerged. From the first two

companies, it was noted how the need for internal documentation diminished, while the amount of teamwork, visibility, and understanding about the work of other team members improved. On the negative side, team members faced some challenges in changing the process during its development phases, in particular maintenance tasks disturbed these changes. Also, the teams did not feel to be productive as before. Both companies, however, decided to continue the utilization of the new working methods, as the positive aspects overwhelmed the negative ones. The third case, instead, was considered separately, due to the different nature of the project.

Here, practitioners found out that the team perceived the workload to be easier than before, thanks to the absence of circulating tasks. However, the schedules and deadlines were described as something that made the organization of work more difficult and less clear than before. Similarly, they did not experience a positive change in efficiency and productivity, but this might be due to the short length of the project. Viability, instead, improved as in the previous cases.

In general, the teams perceived the new practices useful, and their usage was considered potentially beneficial for future projects. They all appreciated the improved communication inside the teams. The use of backlogs helped to increase the visibility, but an effort had to be done to avoid that people focused too much on the individual tasks, forgetting about the big picture. The authors also point out how embedded systems projects have special characteristics, which need to be taken into account when applying agile methods. They also list some suggestions for this sort of “special tailoring”:

• Take into account the different cycle lengths for developing hardware and software.

• Create team-driven agile practices inside the iterations.

• Accept the different knowledge between developers and build on it.

• Define the progress based on work, not schedules or documentation.

• Clarify the reasoning behind the utilized practices together in the team.

• Try more advanced agile techniques.

• Involve the whole organization.