Embedded systems require hardware. We’ve experienced successful Hardware development following agile principles, in particular by ASIC and FPGA teams. Nevertheless, many Hardware engineers find it impossible to follow an agile approach; their “design – manufacture – assemble – test” lifecycle is often too long and expensive for such an iterative incremental scheme. How can agile software developers work with such hardware engineers?
Let’s focus on running a Scrum process when there are inter-dependencies with a non-agile team. Advice on managing this scenario is rare.
Agile teams work on User Stories that describe the functionality to be delivered. These are collected in a Product Backlog. Should User Stories only cover software features? No, in the embedded space software alone is insufficient to make a product. Rather, we can use top level stories (known as Epics) that reflect the combined software and hardware development needed, and are understood by both disciplines. The software team will likely break these Epics down in to a series of smaller constituent User Stories for the software features, while the hardware team may manage their work differently.
Writing User Stories that span hardware and software allows for the interdependencies to be understood. There might be some software that the hardware team needs to test their first prototype; the teams can ensure that the required stories are correctly prioritised to support this. Similarly there may be software that is most efficiently developed once hardware is available (perhaps low level interface drivers); these can be prioritised based on the hardware delivery schedules. An orchestrator, such as a Project Manager, ensures that each discipline understands the Epics and the cooperation that will be needed in their delivery.
Scrum teams hold a short daily meeting (the “scrum” from which the method derives its name). On small development projects it can be very efficient to have all disciplines attend, this is a great way of promoting cross discipline understanding. Bigger projects (those with over 7 or so members) divide in to smaller teams, often with a software/hardware split. On these larger projects it’s more important to have cross-discipline orchestration, for instance via a Project Manager or by holding a Scrum of Scrums.
It’s worth noting that cross-discipline orchestration can be greatly simplified by minimising the dependence of software on hardware. Use software architectures with thin abstraction layers encapsulating the hardware and operating system; the actual hardware and OS can then be simulated using mock abstraction layers for development and test off-target. Divide hardware specific drivers from higher level application logic, using distinct modules with clear APIs. Application logic can then be fully exercised using mock drivers off-hardware.
Managing risk is important on any project, and particularly when both new hardware and software are being produced. A risk in one discipline may have a major impact on another (for instance if the substitution of a hardware component requires a change in software architecture). Hardware and software engineers should collectively rank the risks, and then wherever possible address the highest risks first. Failing early allows much more time to develop an alternative.
At the end of each development iteration (Sprint), the team must collectively plan the User Stories to be delivered in the next Sprint. Priorities are likely to change as a project progresses, and both hardware and software teams need to meet to agree these with the Product Owner or Project Manager.
A retrospective is also held at the end of most Sprints. This is an important feedback mechanism, and requires participation from all disciplines. Some teams are not used to providing feedback and considering opportunities to improve; in these cases an experienced facilitator and a clear set of rules are useful to keep discussions constructive. A technique we’ve seen work well is alternately holding discipline specific and cross discipline retrospectives as the project proceeds.
Inter-discipline dependencies can lead to gaps in a team’s work, for instance the software team waiting for revised hardware builds. It’s useful to consider such gaps when prioritising User Stories; some tasks such as documentation, performance / size optimisations or lower priority software features might be suited to being left until such gaps are expected. It’s much more efficient to maintain a stable software team throughout a project’s development rather than switching staff back and forth.
Introducing Scrum to software development will influence other disciplines, whatever process they are following. At a minimum, ensure that all teams understand Scrum, and see the transparency that it provides as a positive rather than an intrusion. And make sure that management understand the approach also: their understanding of “Agility” could be completely different from yours.
Many thanks to my colleague Peter Schmid for his insights in this area.