|
|
|
|
|
|
by dankoss
2243 days ago
|
|
|
Totally agree. I believe Agile works well in environments with shallow tech stacks, but it has worked terribly in my experience in product companies that build hardware, FPGA dev, embedded software, and other disciplines that can't deliver on two week increments or increments that align well with other disciplines. |
|
|
The thing people have to forget is the notion of "deliver on two week increments". It's not about delivering a product that can be fielded each increment, in the case of an embedded system, but about delivering something that has some improvement or new testable component. I can't make an embedded radio handle, in two weeks, a completely new message type (well, depends). But I can do things in each two week interval that is verifiable. I can show that I've actually received the new message, that I can send it back out, that I can pass it through the various internal processors (if multiple processors are used) or processes (if a single one). Then I can start transforming it, storing it, changing other things about the radio state based on the message contents. Each of those is independently verifiable and completable within a short period of time. But taken as a whole, it's a 6-month project. The agile way has you make those small things, verify them, and then move on to the next thing. I can deliver (to the test team, to others using the system) the partially-completed system, it just can't be fielded (and that's fine).
And that's not unique to embedded. If you only focus on things that can be fielded in each increment, you'll never develop the more complex tasks, or address the tech debt.