release date of a hardware unit that interacted with the C&C software was delayed, and the release date was unpredictable, as the HW design had undergone a change from one processor family to another, and that consequently the necessary work was “unknowable” and “impossible to estimate.” At this point in the project, all managers reported the release as high risk of falling behind, due to schedule volatility of dependent HW and FW components. Another manager commented, “We have this issue every release.”
To further complicate matters, the volatility from cross-layer dependencies occurred at the same time as some significant identity concerns in an unrelated requirements group. A product manager exclaimed, “if we didn’t have hardware pressure, [the other requirements] wouldn’t be risky,” indicating the cycle could absorb some uncertainty, but was struggling to handle multiple uncertainties with big potential schedule impacts simultaneously.
8.5 Cross-Cycle Traveling
Perhaps the biggest advantage of developing recurrent software is cross-cycle traveling of requirements (Figure 8–4). Future requirements thought to be highly uncertain were initially introduced as preliminary investigative requirements. The purpose of these investigative requirements was to identify which parts of the future implementation were uncertain, in order to resolve as much uncertainty as possible in future releases.
The requirements list for the release cycle was initially oversubscribed. However, the promise of future releases allowed a low-impact way of delaying implementation of
requirements for something of a higher immediate priority. When implementation of HW-dependent requirements was delayed beyond the release date, other requirements slated for a future cycle were moved forward, with little loss in efficiency.
Figure 8–4: Cross-Cycle Traveling of Requirements
Recurrent release cycles also allowed for some (not customer-facing) development to be only partially finished in a release, with the promise of completion in a future release.
In sprint 6, due to a confluence of factors—major requirements groups from a particular customer were delayed due to identity uncertainty, and development to support new FW and HW were delayed for volatility reasons—development managers indicated during a status meeting that not enough requirements had been decomposed to provide sufficient work for all development teams. As a consequence, some development teams were tasked with complementing work outside the cycle. “I have four [vendor] teams with nothing to do that are currently working defects,” one manager noted. Capacity was not being fully utilized, and was consequently being lost as developers were idle or doing low-priority work. The problem was exacerbated a few sprints later when the major identity uncertainties with regard to a strategic customer were clarified, and scope of included items decreased.
...
C
1C
2C
To address this unutilized capacity, requirements related to software localization that had been investigated and prepared in a previous cycle—but had been withheld from the observed release for capacity reasons—were added to the observed cycle. The localizations were necessary for future strategic goals of the company, but had not initially been included in the observed cycle, ranking below the line of available capacity. However, due to the unexpected increase in immediate capacity, the localization requirements were added. Had these requirements not been investigated and decomposed in a previous cycle; and, had managers not had familiarity with the status of localization work from previous cycles, these requirements would not have been added to the release. A further benefit to adopting the localization requirements to the current cycle was that its scope was variable: localization work had low uncertainty and could be partially completed as capacity allowed with no noticeable effects to the user, and then fully completed in a future cycle. This flexibility permitted managers to use this requirement as a buffer to fill in work as space was available. In this manner, much of the localization effort slated for a future release was accomplished in the observed release.
As an additional but minor example, a developer reading a story concluded the described end state was unintuitive for the user (as it relied on the user remembering a number rather than a name, and search functionality was not available). The developer reached out to the architecture team suggesting that intuitive naming and search functionality be included. While waiting for a response, another team implemented the story, however, the developer’s suggestion was included as a requirement for a future release by the product manager.
The ability to move requirements across cycles was an important tool for the release cycle manager, not just in managing the scope of the release, but in adapting to volatility from revealed uncertainties in development. As one participant described, “Some features [related to a particular meter] were growing too much … to support some functionality we didn’t need until next release. … As the teams were working [they] kept learning more.” Consequently, a portion of the requirements (comprising an estimated 600 person-days of work when HW, FW and SW layers were considered) was moved to the next release. The manager continued, “It was moved because more firmware resources were needed and firmware was strapped. Everything is strapped [for time].”
Lastly, in addition to the forward traveling of requirements through time, the recurrent nature of development permitted anticipatory work on requirements, even before the requirements had been accepted and specified. The analysts understood their time was a bottleneck to the development organization (as made starkly clear in the incident discussed previously). Consequently, analysts and engineers relied on their experience and knowledge-centric position within the organization to anticipate and pre-work selected requirements. As one engineer said, “I knew there wouldn’t be enough time in a release for design … [so] I’ll do up-front design for the most difficult things.”