In the fifteen years since the publication of the Agile Manifesto, agile techniques and methodologies have steadily gained in popularity to the point where last year, a survey identified agile as having overtaken waterfall in the majority of software development projects.
In the world of embedded software development, though, it’s not always obvious how agile techniques can be applied. How do you create a user story for a requirement like: “The transceiver must maintain timing and frequency synchronisation with a basestation to within 1.5 parts-per-million”? How do you create a Minimum Viable Product prototype for early feedback when the target hardware isn’t designed yet, let alone built and working?
These sorts of questions can lead to the belief that “agile” and “embedded” just don’t belong together. However, at Cambridge Consultants we believe that agile gives us another set of tools in our software process toolbox, and many of the techniques can be applied just as much in embedded development as in any other software project.
For example, in our recent work to refresh Iridium Communications Inc's Sustaining Engineering process (more to come on that soon), we have adopted a Scrumban-like approach using an Atlassian Jira Kanban board to manage our workflow.
We hold daily stand-ups and work in two-week sprints, with regular retrospectives. During a sprint the team work through a prioritised backlog, and at any given time a developer may be working on fixing a bug, adding a new feature, writing new test scripts to increase coverage, or extending our automated test framework.
Although it wouldn’t make sense to create traditional user stories for many of our backlog items, we do use an interface-centred design approach. We always look first at what interfaces will be affected by a given change, working to pin down exactly what is required and what the impact will be on existing users of that interface. In this case, users include actual human users, third party software interfacing with the product through published APIs, or other modules of code within the same product.
We use frequent peer code review to improve overall code quality and avoid concentrating expertise in a particular area in one person. Code is built – for real and simulated targets – on every commit and our automated regression system alerts us if anything unexpected has happened.
With our clients, although we are not physically co-located, our development team works extremely closely with theirs in an ‘integrated development team’ model. In the case of Iridium, their Technical Product Owner participates in the daily stand-ups via teleconference, and is also joined by the Managing Product Owner for the retrospectives. This provides the fast feedback loop that the development team needs to achieve maximum effectiveness and allows best-case maintenance of the prioritisation of the backlog.
Finally, our process itself is always subject to continuous improvement, and we regularly identify new ways of producing higher-quality software while making our own lives easier (and more fun!).
It’s not just in the Sustaining Engineering part of the life-cycle where these techniques bring value. A completely new product development involving embedded software can benefit from many of the same approaches – perhaps with some tweaks here and there. One of the key precepts of agile is to be mindful about what you are doing, allowing you to keep doing what works and change what doesn’t.
At Cambridge Consultants our projects are so diverse – from miniature implanted cardiac devices to the world’s largest radio telescope – that we never expect the process to work in the exact same way every time, so we’ve designed our process to be flexible and robust. I’d like to think that this approach has helped us to apply the best that agile has to offer, with the client deeply engaged, in our embedded software world.