Building the walking skeleton helps us focus on the interfaces early in the project and to verify that the components will be able to interact to achieve the overall goal. Then teams can go off and add capabilities (muscles) inside each of the components to handle more user stories. Since the architecture is already integrated and running, we have a lot fewer integration problems later on. We can still evolve the interfaces but these are relatively small changes in the context of the overall architecture.

Does this sound similar to what you are doing in hardware?

Usually when I see “collaboration” mentioned it is in context of having the same types collaborating together, such as two sw engineers doing pair programming, or one sw engineer practicing continuous integration so their sw is quickly made available to other sw engineers. In my workshop, I focus on the interface between hw and sw, which means my collaboration focus is on getting hw engineers to collaborate with sw engineers. Things like co-simulations and virtual prototypes are excellent tools to get the two sides working together.

Much of what I discuss in the workshop is focused on defect prevention by correct design. I’ve dealt with many defects over the years that simply would have been avoided had some design practices been followed. This is hard at the hw/sw boundary because hw engineers do not understand sw nuances. This is why collaboration is so important.

I do talk about continuous improvement but in the silicon world, it is 12 to 18 months (maybe) before you see improvement from one version to the next. Automated testing is not an area I cover.

“First-time-right” efforts have been underway for a few years. Ten years ago, companies had the money and time to do three, four, or five respins to get the chip right. But with the business emphasis on shortening time-to-market and minimizing development costs (one respin these days can cost up to three months and a million dollars,) much has been done to reduce respins. The numbers that I have seen lately are that an average chip requires 1.5 to 3 respins. That is really good considering that the leading process technology today is 45nm, which is one sixth of the 250nm process used to make chips 10 years ago. Because of the smaller geometries, chips now come with millions of gates, making for a very complex part to design and verify.

ESL (Electronic System Level) design is big in the industry right now where design efforts start at the system level. The hw/sw boundary is fuzzy at this time. Models are used to emulate components. Simulations help refine the models and designs. Once things are decided at the system level, then detailed design can progress. This helps cut out waste from designing the wrong building blocks or putting in the wrong features (i.e. lean and agile techniques.)

As far as practices to get it right the first time, several are mentioned in my newsletters.

It sounds like the self-preservation techniques, which you call non-agile, are very important. I assume it’s similar today, as days gone by, where there is an emphasis on test and simulation. In the olden days in the 80′s we would spend lots of effort on test vectors for custom gate arrays. We would not dream of sending the design to fab without them. You get to toss one golden horse shoe, you want to aim true.

So, when you commit to a design, you want to be pretty darn sure that it has a good chance of working. In the lean world they call that waiting for the last responsible moment. You also design in flexibility. It sounds like you hedge your bets by designing in design alternatives and probably some programability.

I see from your workshop that you value some of the same things agile software developers value: collaboration, practices, principles, post mortem (we call them retrospectives). I don’t see defect prevention, automated test or continuous improvement, but I suspect they are there.

I bet there are efforts underway to reduce the time from design submission to first silicon. Is it better today than 10 years ago? How many spins of silicon are typical? What are the practices to get it right the first time? What are the lean/agile techniques for silicon design?

I don’t know these answers but I am interested.

These are good points. We have discussed some of these before with our hardware people. The problem is one of “seeing is believing” and they don’t believe enough to try to see. Meaning, they hear the above arguments, declare them fantasy and refuse to try.

Other than calling in a management edict, I have not been successful getting over such flat dismissals of these agile hardware development benefits. Do you have any suggestions on providing the hard skeptics with a positive experience?