On hardware dependencies and scrum - Embedded.com

On hardware dependencies and scrum

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 prioritized 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 prioritized 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 seven 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 minimizing 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 prioritizing user stories; some tasks such as documentation, performance / size optimizations 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.

Mike Hogg leads an embedded development team within Zuhlke, an engineering consultancy. He and his colleagues have been using agile techniques and their precursors for over a decade in multiple sectors including telecoms, transport, and medical. He has 15 years development experience primarily in real-time embedded systems written in C++ and C, and he has also delivered business applications in Java. Mike writes the blog Agile Adventures in an Embedded World for Embedded.com .

4 thoughts on “On hardware dependencies and scrum

  1. Hi,
    It is very interesting approach.
    I would like to know if the architecture that is described in following link can suite this attitude and to be a “software architectures with thin abstraction layers encapsulating the hardware and operating system” ?

    Log in to Reply
  2. Yes, the hardware and device abstraction layers described in your architectural concept are one way of achieving a good level of abstraction and encapsulation.

    Log in to Reply
  3. Even using all the best practices listed above, there is one place agile fails. How do you include open ended debugging issues in an Agile methodology.
    In the real world, sometimes the hardware/software is broken. When you get a sometimes it crashes at low

    Log in to Reply
  4. How would you fit and open ended debugging issue in any process where features are committed to a dead line? This is not a problem of scrum or any other process (RUP, Waterfall…).
    With an empirical process you have the built in opportunity to frequently

    Log in to Reply

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.