Here’s another post spurred by Bill and our discussion from An Idealist’s View of Agile Hardware Development. This is a good one. If there were an award for best AgileSoC comment, Bill probably would have won it with this…
“Given the cost to tape out a large ASIC these days, we know that these incomplete designs are never going to be shipped. We are going to wait until most or all of the features are in before we ship. We don’t get multiple tapeouts to add incremental features like we can in software.
Now this may sound like I’m arguing against agile HW design but I’m really not. I’d contend that even if we were to just pretend that we could ship a design, it would force us to tie off a lot of loose ends earlier and plan the order we add features much more carefully. In fact, if we were to just change our view to add features in order from most important to least important, we would likely end up with a shippable design much sooner.
I think I may be arguing both sides of the issue here but I truly a believe that if we were to take a more holistic view of chip development and align development, verification and PD to operate in a more incremental fashion, we might just ship the final product sooner even if we don’t end up in that agile nirvana of being about to tape out on any particular Friday afternoon.”
A little context… Bill’s background is physical design. Like the rest of us, Bill finds himself struggling with how we incorporate PD into an ideal agile development flow; one that includes continuous deployment of an ASIC (“agile nirvana” as Bill calls it). Unless you have customers willing to shell out a few million dollars on a monthly basis, continuous deployment isn’t realistic. I think we all understand that as an obvious strike against agile hardware development. But if that’s all it takes for you to walk away from agile, consider Bill’s analysis.
Bill is reminding us there’s no one-strike-and-you’re-out when it comes to agile. Not being able to continuously deploy an ASIC in the strictest sense doesn’t preclude you from using other practices. It also, as he points out, doesn’t keep you from interpreting the practice of continuous deployment such that we’re still able to add value to a product. Just pretending continuous deployment is viable could help us a) prioritize features; b) tie up loose ends sooner; and c) grease the wheels for an earlier tapeout.
Now, would pretending to continuously deploy an ASIC be enough to satisfy the agile police? Nope. But pretending could still lead to the major improvement so who cares if the agile police are happy with us or not! I like Bill’s idea of pretending to ship a design and I hope others give it a little thought, especially the people doing physical design.
To keep the ball rolling, I’m going to try and redirect things slightly. In XP, continuous deployment is a corollary practice. That means if we’re jumping directly into discussion about continuous deployment, we’re ignoring several prerequisites, two in particular. Before an agile team is doing continuous deployment, I’m guessing that, at a minimum, they’ll have to master the primary practices of weekly and quarterly releases. So let’s forget about continuously deployment and focus on those as our pretend deliveries. From there, I’ll put these questions to the PD crowd:
- What meaningful and complete “product” could you deliver in the first week of development? (who cares what it does as long as it’s shippable)
- What meaningful and complete “product” could you deliver in the first three months of development? (again… who cares what it does, it just has to be shippable)
- What inputs would you need from others (designers/architects/etc) for a first weekly/quarterly delivery?
- What loose ends could you tie up on a weekly/quarterly basis that would grease the wheels for early tapeout?
- What other XP primary practices would be required for a successful weekly/quarterly release? (if you don’t know what the other primary practices are, you’ll find them in my satirical post on Why Agile will Never Work In Hardware)
We’re brainstorming here so there are no wrong answers. Also, let’s keep it to the ideal as much as we can without restricting ourselves… what could we do as opposed to what can we do. If you’re looking to strike out on a tangent, there’s always the discussion regarding the tooling required to support weekly and quarterly deliverables. That’d be fun, too.
Back to Bill for a second, thanks for speaking up for the folks on the physical design side of the fence. You’re underrepresented in this discussion about agile development. Hopefully your voice of reason gets things moving a bit.