In a post a few weeks ago I talked about how regular delivery wasn’t actually the point of being agile in hardware development. While the software guys can deliver on a weekly or monthly basis, taping out an ASIC every week doesn’t make much sense. Obviously. But even though regular delivery makes no sense for an ASIC doesn’t mean agile isn’t applicable. The value of agile in ASIC development is the ability to demonstrate progress. I believed that when I wrote it and I believe it now.
So why the contradiction in this post? Why am I now saying regularly delivery should be part of agile hardware development? While it might not make sense for ASICs, regular deliver is entirely possible with an FPGA or an IP block.
Before you shake your head, think about why agile software teams deliver product regularly. The goal for any software team is to satisfy customer need. Sounds simple enough except that sometimes customers don’t know what they need… so they ask for what they think they need or worse, what they want. If you (the development team) disappear for, say 9 months and then hit them with finished product, there’s a decent chance someone ends up being disappointed.
Development team: “All done! This is exactly what you asked for in this giant ambiguous requirements spec! I hope you love it!”
Customer: “I don’t love it because that’s not what I asked for.”… or… “Hmmm, I guess that’s what I asked for but what am I supposed to do with it.”… or… “Super, but I don’t need that anymore”.
Experience has shown agile software teams that keeping your customer involved in development helps avoid delivering a disappointment. Involved doesn’t mean telling, it means showing. Showing customers product as it’s being built helps them identify what they need and prioritize what they might not need. This works in software. There’s no reason to think it couldn’t work for an FPGA or an IP block.
“You mean we should be able to ship an FPGA load or an IP block every few weeks/months?”
“Even though it isn’t done?”
“But we’d have to change our whole delivery process or we’d end up wasting all our time on packaging the thing instead of building it.”
“…and we’d need automated regressions…”
“…and we’d have to help them with integration so they know how to use it…”
“…and we’d need user guides and documentation in place…”
“…we’d probably need a reference design, maybe even a board ready way before we’d usually have one…”
“…but what if there’s a problem with what we’ve built?”
That’s kind of the point.
With an ASIC, it’s not possible to incrementally deliver the real thing but there is still value in hardware simulation/co-simulation demos, emulation demos, intermediate size and power calculations, etc. It’s not perfect but it’s better than going the distance, sharing progress through status reports and hand waiving only to find disappointment when you’re done.
With FPGAs and IP it’s different. Regularly delivering product to your customer even though it isn’t done could end up being an invaluable learning experience. And unlike an ASIC, it’s entirely reasonable. Yes it could require major changes to how you develop and package your product but the customer feedback could be worth your while. Even if you only do it once, think of it as working out the kinks so there’s a better chance of bug free delivery when you are done.
Better to discover that what you’re building isn’t quite what your customers need in a month or 2 than funding a massive development effort and finding out months later.
Possible? Not possible? Ridiculous? Let me know what you think!
2 thoughts on “Regular Delivery… It’s Part Of Being Agile”
Hi Neil. You’re absolutely right.
Years ago, I participated in building a video decoder HW/SW co-design. We had nightly builds and regression tests on a prototype board and it worked great.
Definitely possible. Good delivery mechanisms is key for being able to integrate components well. You’re right that frequency helps get things right faster, though the delivery mechanism should be done right regardless of frequency, for various reasons. I wrote about my vision for an “apt-get for hardware design” here:
Let me know what you think.