Embedded projects and agile - Can/should you do this with hardware?

Question

What are the ways that a hardware design group could use iterations and general agile practices to design boards?

Such as:

• Should the hardware group be integrated with the project team?
• How does the hardware group schedule iteration work? Using stories?
• Because of the cost of PCB/board spins, could an agile team do a partial-feature board first, then continue by adding new hardware to support new features each spin?
• Is there a way for the hardware to be "continuously integrated" with the software? Daily?

Answer 1

yes agile applies, TOYOTA is an hardware compagny (kind of), and it's considered (with LEAN and toyota's way) a pioneer in agiles methodologies (Kanban comes from there too I think)

Answer 2

I just starting reading about scrum/agile and friends so i speaking from my mind not from experience here :

• Should the hardware group be integrated with the project team?
  Don't see any reason why not. If part of the development done by hardware ppl they should be part of the project team.
• How does the hardware group schedule iteration work? Using stories?
  Stories is just another names for the task right ? So usually development splits to task and i see no differences between hw and sw development.
• Because of the cost of PCB/board spins, could an agile team do a partial-feature board first, then continue by adding new hardware to support new features each spin?
  You just need to sync sw development with evolution of your hardware. By the way the hw task should be moved to the done state after it was verified by software team. IMHO.
• Is there a way for the hardware to be "continuously integrated" with the software? Daily?
  I would say integration should be event driven, something comparable to commit to the repository in the software world should trigger the integration/regression tests. Daily seems to me a little bit overkill, unless each day you can complete something. There is no reason to run test if none of additional function modules completed.

Answer 3

As has been alluded to in the original question, one of the biggest problems when setting out to do iterative hardware design is going to be the cost of the spins. Obviously the costs are going to depend on the nature of the hardware (eg. board size, board complexity, component cost, loading costs) - but if you have a complex board the costs of doing lots of iterations are going to be prohibitive.

And while it might be possible to leave the fine detail of the design of particular portions of your hardware to later iterations it's likely that you will have to accommodate those portions right from the start (eg. allocation of I/O, allocation of pcb real estate), which again is going to make it difficult to iteratively do hardware.

To some extent it depends on what you mean by hardware. If your hardware team is responsible for developing all of the drivers and the hardware test code then that's a different story. There's no reason why they can't make features available to the software team in an iterative fashion, also meaning that they should (must?) be a member of the project team.

Depending, again, on the type of hardware that you're developing and the interfaces that the software will use to talk to it, it will potentially be useful to design a partial-feature board. This board will be of the most benefit if it exposes all of the interfaces in a way that allows for debugging and verification - so that the low level routines can be at least partially tested before the real hardware comes along. But this is only going to be worthwhile if the time it takes to do the real hardware is prohibitive and the time to do a development version is much lower. Otherwise just go for the real hardware and save the cost.

Continuous integration is a great ideal in principle, but the practicalities are going to be determined by the type of hardware that you're developing. If your hardware lends itself to automated tests then this is a good way to go. See this question for some pointers on how to achieve this. (btw. programmable logic, such as fpgas, should always be continuously integrated)