Why Embedded software?
As ubiquitous computing pushes the Internet of Things revolution, embedded software development is starting to be placed under more pressure and is facing a new challenges. We are seeing impressively short time to market life cycles, with products that pack ever more computing power and with higher demands from the customers that seem to be ever changing. The scenario is one we would clearly associate as requiring an agile software development method, however embedded software has been know to be reluctant to embrace this rather recent approach to development as opposed to more traditional approaches which it inherited from the hardware product life cycle.
What are the problems for embedded software development to go agile?
Embedded software faces specific hurdles that limit the application of agile practices, including the difficulty (if not outright impossible) to apply release of upgrades or fixes to embedded software, the fact that the new release of software must still be compatible with a certain range of hardware that has already been supplied to the customer, and well as the close ties to the actual development of the hardware. It has been suggested that due to these limitations, embedded software companies would have to make adjustments to the agile practices in order to better accommodate their needs. However, one pitfall in such an attitude is that the easy practices are adopted, and those that would have really brought a change to the company are not adopted using the excuse that they need customization [1].
What is the feedback from industry ?
In the paper [2], O. Salo and P. Abrahamsson present the results of a survey carried out across 13 embedded software development companies that have shown interest in adopting agile practices. Since the sample is know to be biased in favour of adopting agile methods, the authors present this work not as a survey of the whole industry, but rather as a means to better understand the usefulness reported by such companies of their experience of agile. The survey investigated the actual implementation of two agile methods, Scrum and XP, and the perceived usefulness of the methods amongst project managers and software developers of large, medium and small companies.
Results
One clear point that emerges from the survey is that Extreme Programming (XP) practices were more popular than Scrum, with 54% of the responses stating that the practices were systematically, mostly or sometimes applied, as opposed to 27% for Scrum for the respective range. However, a clear point to note is that knowledge of Scrum practices seems to be less widespread than XP, with the percentage of “never” and “I don’t know” for scrum practices being much higher than that for XP.
Another possible reason for this discrepancy is the difference between XP and Scrum, where XP is presented as a set of 12 practices that can be implemented somewhat independently of each other. On the other hand Scrum is a whole “process framework”, and is not easily implemented successfully as separate parts, making adoption a more disruptive move. By definition Scrum should NOT be implemented in separate parts, as this undermines the whole framework. [3]
The feedback regarding the experience was positive in both XP and Scrum, however even here, the experience of XP seemed to have more positive feedback (90%) rather than Scrum (70%).
One particular comment by the authors that struck me as strange was that they claim that the feedback regarding actual experience proved more positive than the predicted positive experience by those who had not yet implemented agile techniques. They use this to argue that agile techniques are better than perceived before adoption. I find it hard to draw this conclusion, when this could be clearly biased, since people who have negative expectations of a technology will probably not take it up, resulting in the higher negative prediction. For all we know, these companies may be justified in their belief since the practice may not be directly effective for the company/project.
Comments about the research.
What appears clearly from the research is that companies implement some of the agile principles more than others. While this may work for XP, it is strange for Scrum since it should be implemented as a whole, rather than just parts. (It was split according to scrum meetings, which may not make sense using just a few of them). However this may be a clear indication that the agile techniques need to be modified to cater for the embedded software development, since some principles seem to be more beneficial than others.
Another point to note was that Test-Driven Development was one of the least techniques that was implemented from the XP techniques. I find this surprising, since Test-Driven Development would greatly aid the identification of problems very early in the implementation stage, and has been identified as a means of increasing the reliability of code developed. I wonder whether this percentage remains through today, 5 years after this survey was carried out.
I also find interesting the range of risk that the respondents identified. Although the authors did not discuss this in detail, I believe that the risk assessment of the software may greatly influence the way and extent that agile software development is implemented. In fact in this survey, most projects involved software that could potentially cause loss of discretionary funds or just loss of comfort. Only 2 projects involved potential loss of life or more. I believe that it would be of interest investigating the correlation between the risk involved and the way the company adopts agile techniques, as I speculate that it would be very hard for companies that produce high risk equipment/embedded software to change long standing development methods with stringent stages and control to a more flexible and less documented agile technique.
Conclusion?
I believe that due to the advancement in both software development methods, as well as the rapid increase in smarter devices that surround us, it would be very interesting to carry out this research once again now, 5 years down the line, and observe current trends, with clearer indication of the complexity, scale and risk associated with the embedded software. However, I believe that this paper gives enough proof that projects that used agile techniques for embedded software, usually considered conservative, proved useful and a positive experience.
References
[1] B. Boehm, “Get ready for agile methods, with care,” Computer, vol. 35, no. 1, pp. 64–69, 2002.
[2] O. Salo and P. Abrahamsson, “Agile methods in european embedded software development organisations: a survey on the actual use and use-fulness of extreme programming and scrum,” Software, IET, vol. 2, no. 1,pp. 58–64, 2008.
[3] K. Schwaber and J. Sutherland. (2011) The scrum guide–the definitive guide to scrum: The rules of the game.