What software development model has worked best for software teams with heavy dependancy on hardware teams?

Question

There are a number of competing best practices for software development. From what I have found, many teams have benefited from Agile practices in some cases. However, in some other cases, using the Unified Process has been championed by large companies like IBM.

The common themes that I find seemed to work well for teams that mainly develop software.

I am interested to know what has worked best for people who have worked in shops where there is a team on the other side that produce the hardware that your software is running on. For example, one team puts together a crate with several custom hardware on it; while you need to develop the software that would run on those crates. I can't find a development model (agile, spiral ...) that works best in this case.

Any wisdom is this area will be well appreciated.

Answer 1

It really depends on how your hardware team will deliver useful artifacts that your software team can use to develop against, and how the teams are set up to communicate with each other.

Typically, you'll find the hardware team will build a product, get it to a prototype stage for testing, and only then will the software team get any sort of requirements documentation from the hardware team. Needless to say this isn't always the best way to go, as the software is usually developed very late in the process, and you generally find yourself with little choice but to work with a waterfall-based methodology. On the upside from the hardware team's point of view, if they suddenly need to change something, the software team won't need to modify their software. The problem here of course is that your average hardware guy needs to develop products in this way, and expects that anything that will benefit him with help out the software team.

As an alternative, if your hardware team is building a product and updating the software requirements as they go, and even better, if they involve the software team early on as each hardware feature is being planned and simulated, then you have the opportunity for the software team to work in a much more Agile manner. Naturally by this I mean that the hardware team is the customer, and gives the software team a list of problems that need to be solved in software. The software team can discuss with their customer the relative priorities of each requirement, and as soon as the hardware prototype is ready, the software will likely be available in an early release form, and can be used to help in testing the hardware. If the requirements change, the software team will hopefully have the agility to change the software as they go, and can provide early feedback to the hardware team before the hardware design is committed to prototype. The software team also have direct access to the customer very early in the project, which means that they can get a better idea about what they need to mock out - and how to do it - while waiting for hardware to test against.

Realistically, you won't find an ideal methodology that just fits off the shelf, and I can guarantee that you will have a lot of tweaking to do no matter which methodology you choose to adopt, or develop. The real issue is that you want to try and make the synchronization between the teams easy to manage, and means that you need to find a way to increase the amount of contact and input between the two teams as early as you can in the process, even if it seems "wasteful" or "counter-intuitive" to do so. This is a big problem in the company that I am presently working with. Our European "parent" is struggling with this exact problem, while the team here in Oz seems to be able to keep things running a little more smoothly, and it's really all due to giving the software team more involvement early in the design and simulation stages of the hardware development.

Answer 2

I am probably biased, having worked more on the hardware side of large software-hardware product development teams. Hardware can be very costly to revise if it's architected or designed wrong. Often an error in the hardware design is so costly it means canceling the entire project. Fixing a chip mask error can cost more than the annual salary of dozens of engineers. So I see the primary purpose of the software team for the first 50%+ of the development cycle is to make sure the hardware team does not fail. This may mean forgetting about the final application code and it's design at first, and just working on hardware architectural and performance simulations, tools to help the hardware team complete and verify their design, and code to test and exercise all the various necessary components of the earliest partially functionally hardware prototypes.

Expect to be agile, not only about the customer spec, but also about various surprising quirks/bugs in the hardware platform, where a software workaround may have far less impact on the schedule than a hardware spin.

Answer 3

One of Agile's main tenants is "fail early". With hardware, this couldn't be more true. Mass producing hardware is extremely expensive. Moreover, physical hardware cannot simply be "patched" like software can. Exacerbating these problems, hardware teams tend to be less customer facing then software teams in practice, and tend to be used to the "big bang" model of development.

For these reasons not catching hardware problems as soon as possible is typically orders-of-magnitudes more expensive then failing to catch software issues early. Customers expect to require software updates, they may stop working with you entirely if they have to deal with a hardware recall.

In short, not expecting and preparing for hardware problems early is a development model's single biggest challenge when developing software and hardware in parallel.

You absolutely must anticipate failure. Get a prototype early. Use the prototype to develop against. Expect it to be a failure. Learn from the failure. Rinse. Repeat. Make sure its expected by everyone that the hardware prototypes are to be revised/critiqued/redesigned based on feedback from stakeholders.