Agile Insights

Lesson #6: Hardware teams may initially struggle with Story writing because they tend to express non-functional requirements where Scrum expects Stories to describe deliverables.

Lesson #7: In hardware development, Product Owners often write only a minority of the Stories. Story-writing responsibility is distributed much more evenly across the Product

Lesson #8: Hardware organizations generally do not have a direct equivalent to the software Quality Assurance specialist who independently tests most Story deliverables. In many cases, the engineer who creates the deliverable is also the person best qualified to test it.

Lesson #9: Story Points depend on a shared understanding of the work being estimated. Because hardware teams are often composed of highly specialized experts, effort-based estimates such as Person-Days frequently provide a more practical alternative.

Lesson #10: When work is estimated in Person-Days, Velocity should also be measured and forecast in Person-Days. The most effective forecasting technique is a resource model that accounts for the actual availability of team members during the Sprint.

Lesson #11: Hardware Sprint Planning must account for both team capacity and individual capacity. A Sprint is feasible only if neither the team nor any individual specialist is overloaded.

Lesson #12: In hardware development, cross-functional teams and swarming are often competing objectives. When forced to choose, organizations should favor cross-functional product teams over discipline-based teams designed to maximize swarming.

The most important lesson from Thermo Fisher Scientific was not that hardware development differs from software development. We already knew that. The important lesson was that Scrum can work remarkably well in a hardware environment once those differences are acknowledged and accommodated.