10

Our team is composed of both software and hardware engineers. The software team uses Scrum project management while the hardware team uses waterfall.

The priority of our software requirements change quite frequently, so staying Agile makes sense for us. The priority of our hardware requirements are rather static and slow-moving, so again sticking with waterfall makes sense for us.

The tricky part is the integration of hardware and software. Are there any methodologies for deterministically synchronizing these two contrasting project management styles?

I've worked within DO-178B for some time, and what we used to do was have designated milestones where software and hardware teams would integrate and get preliminary feedback (identify requirement deviations, new requirements, etc.). However we're looking for methodologies which incorporate tighter feedback loops.

  • 1
    How much software emulation or simulation of the hardware do you have? How well defined is the hardware/software interface - is it sufficient to implement simulation or emulation of the hardware to decouple the software from the hardware until a predefined integration phase? The big issue would be that if the interface isn't implemented totally correctly by bother sites, there will be defects found very late in the process (when the hardware is finished). – Thomas Owens Dec 9 '14 at 14:48
  • Perhaps you can describe the difficulties that is uniquely faced by the hardware team that currently prevent them from delivering more frequently. Some examples are discussed in agilealliance.org/files/session_pdfs/… but different hardware teams in different companies could face different challenges because hardware development is a broad umbrella term for many varied R&D activities. – rwong Dec 24 '14 at 20:53
3

TL;DR You should use Scrum in both teams.

sticking with waterfall makes sense for us

There is no benefit in having hardware team doing waterfall whatsoever. In fact, it applies to any team. Choice between it and agile methods is not simple requirements priority. Why would you stick to a process with long lead times, large overheads and low time to market if you can avoid it?

what we used to do was have designated milestones where software and hardware teams would integrate

In Scrum, the team produces working, potentially shippable increments of a product on a regular basis. When you have two teams running Sprint in parallel, their combined definition of done should cover integration as well.

The end of each sprint is a milestone you are talking about. If combined output satisfies the definition of done, you are synchronized.

However we're looking for methodologies which incorporate tighter feedback loops.

More reasons to ditch waterfall altogether :) Wouldn't you want your hardware team deliver something of value in a month rather than in a year?

Also, it makes sense to use the same methodology in all your projects - this will, at least, simplify learning. You could use any other agile approach with the hardware team, but this diversity won't do you any good.

3

Converting your hardware team to Scrum will certainly help. However, as Steve McConnell said:

...if you buy into any single methodology 100 percent, you’ll see the whole world in terms of that methodology. In some instances, you’ll miss opportunities to use other methods better suited to your current problem.

So let's assume waterfall works fine for your hardware project and you just need to sync the two.

I would recommend using the release plan as a dependency point. Like Apple announces new iPhone release coming, your hardware team should announce new hardware release. In your case you're lucky to know the features list beforehand.

Software team, in turn, should plan releases accordingly. Having 1-2 reserve Sprints to go through, if hardware team release is delayed.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.