Are There Case Studies For Hardware and Software On Same Scrum Team?

Question

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?"

Answer 1

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.