4

We're in an automation market. All our projects are heavy on mechanical design, and many (but not all) of those projects include significant electrical and firmware components, with PC software being used mostly internally, but some customer-facing demos, etc. Current org structure is delineated along engineering disciplines - there's an Electrical Engineering group, Mechanical Engineering group, Software engineering group, etc. All development teams are doing at least some form of Scrum, with defined Sprint periods and Goals in each Sprint.

There is lots of desire to "try out" multidisciplinary teams, so that all skills relevant to a project are in one team. I'm trying to wrap my head around what 'good' looks like in that kind of environment. Searching for things like "software and hardware on same team" yields some opinion pieces like Scrum Teams, Swarming, and Hardware, but what I'm looking for is an actual example of how this has been done in practice, and if there is a consensus on whether it's actually workable. I can think of plenty of challenges, like the ones in this question, where the Product Owner is more comfortable making a Backlog for one discipline.

Just to be clear, the focus of this question is "are there case studies for integrating mechanical, electrical, and firmware/software on the same Scrum team?"

5
  • 3
    This is a great question and I hope you get some good answers. The closest I have got to what you describe is an ATM team at a bank that had to coordinate the software and hardware development. It wasn't a genuinely agile setup though. Aug 4 at 8:02
  • 2
    Really interesting. I'd be especially interested in the possibly different cadences of software development where 2-week sprints seem to be common, and hardware development where 2 weeks feels a little short to me. But I'm a very amateurish hardware tinkerer, it's possible that professional hardware prototyping would fit well in 2-week sprints. Aug 4 at 9:19
  • I don't have a case study handy, but I did it for 5 years and have coached a number of other orgs who do it, so it's definitely workable and, honestly, I don't think we did anything different than any other successful Scrum team. Are there specific questions you have about how a particular challenge was tackled?
    – Daniel
    Aug 4 at 15:13
  • 2
    I disagree with the close vote. The last sentence clarifies things enough to not make the question closable.
    – Sarov
    Aug 4 at 15:25
  • Saab aerospace seem like a likely candidate to have something like this. They do hardware-software projects (like fighter jets) with autonomous cross-functional teams. Aug 8 at 1:22
3

I can't reveal the company, but I coached a Scrum team that combined hardware, firmware, and software engineers to develop a next-gen utility meter. This requires a slightly different model in which the PO is more like a business analyst, channeling work from separate product managers (treated as the "customers" were in classic Scrum). The PdMs also worked directly with the people in their related disciplines to detail the features (multi-story "epics").

Otherwise it worked like any other Scrum team. They chose to run three-week sprints with full-day grooming/planning sessions on the first day. Everyone could ask questions about any story regardless of discipline, which gained the value of multiple perspectives--such as the "stupid question" that turns out to be quite smart--and better understanding of how choices in one discipline affect the others.

HW sprint deliverables require rethinking: Demonstrate the design of one small part of a circuit, for example, but that should be the proposed final, high-quality design. And while SW had a "potentially releasable product" every sprint, I think FW aimed for quarterly potential releases, and HW for versions ("revs") that might take multiple quarterly releases.

Comment if you have specific questions.

Good luck--Jim

Post-comment edits: This team operated in the ideal scenario of one team working on one project, but I have dealt with both of the scenarios mentioned. My approach retains something like functional managers as dotted-line reports. That is, the team reports to a business manager as a whole, but each discipline is coached by an expert in that discipline. That person is responsible for gathering the discipline members on occasion to make those "standards and libraries" decisions, and then implementing and coaching on them, among other duties. That also establishes a cross-team, within-discipline network people can tap when they need help.

2
  • Thanks! Were there multiple such teams? One particular concern is maintaining cohesion, in e.g. software standards and common libraries. And there's obviously "synergy," e.g. when one software engineer has a tool problem, other software engineers will be best-positioned to help them, the mechanical engineers won't be helpful, and we don't want to lose those advantages. Aug 4 at 19:20
  • 1
    Good question! See my edited answer. Aug 5 at 14:58

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.