Firmware teams may be quite nimble in the early stages while the team can work relatively independently of the hardware teams, but once system integration starts, the overall project often bogs down.
System integration generally tries to minimize the number of expensive prototype units needed. It is planned in large, sometimes weeks-long test suites which assume all features are finished and ready to test. At the same time, the software teams frequently are still responding to late-breaking market changes or changes in the hardware itself. The situation looks rather like this, where there’s no clear relationship between the goals of the tests and the firmware schedule.
Often the teams can’t even discuss their mutual schedule coherently because they’re each describing the system and its parts using a different language. The testers are talking about risks and large-scale behaviors, the firmware team is managing its work as a list of detailed user stories, and the project management office is claiming that everything is “frozen” already.
How can we have the best of both worlds? The answer isn’t to lock down the firmware earlier. That deprives your business of the opportunity to respond to new information. Instead, try an “Integration by slice” planning method. Integration-by-slice can provide a middle ground which benefits both hardware and software teams, and speeds up the project.
Integration-by-slice starts out by splitting the project into regular timeboxes. These are fairly arbitrary, so we might as well align them with the firmware sprints.
Once timeboxes are defined, start discussing what features or behaviors can be tested in each timebox. What is ready to test? What is the most important to test first? Define groups of features and behaviors, at least one group per timebox, and call these “slices”. The slices are described in terms of user-visible behaviors or features, so they provide a single commonly understood target for all the teams. This makes it much easier to discuss what needs to be delivered when in order for everyone to carry out their plans. The test suites are split into smaller suites which each focus on the goals for a particular slice.
The smaller tests do sometimes require more prototype units – but now it’s a conscious and well-informed choice. The team leaders can compare the cost of creating additional prototype units against the value of getting test results back earlier and/or being able to change some of the features very late in the project.
Slice-based integration has several benefits. The focused testing reduces the risk of late-found defects delaying the project, and the improved communication can reduce the overall effort for the project. Certainly there’s less frustration!
To learn more about slice-based integration, read our new book When Agile Gets Physical.