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.
-neil
Thanks Bill & Neil for this insightful sharing.
I thought about this topic for a while. In a nutshell, people may mix up product and tapeout whereas we talk about taped out product. In the opinion of many, a shippable released product iteration should also include the tapeout. I can understand why product is not considered as shippable until it’s taped out since the customer is the final external customer and the business value is how much this external customer pays the company.
In my opinion, the tapeout in shippable release from the last iteration. If the problem was addressed that way (by going back to the definition of terms), then we may see a shippable set of features which does not contain any taped out data. What if the customers were now internal and the business value (computed in $$) computed of the budget allocated to each team? Each team would have their customers and vendors ala “Scale Agile”/SAFe/Scrum-of-scrums so that each team would release by package creating business value, inspecting & adapting at the end of their iteration.
The physical tapeout would hence not be a bottleneck anymore in this process, in which Agiles concepts and frameworks shall still be applied.
Any thoughts on this axis?