This chapter is from the book
This chapter is from the book
This chapter is from the book
Motivation
Why is rhythm so important to software architecture? Since software architectures are developed and used across many organizational boundaries, rhythm provides a stabilizing force that coordinates activities within and across teams and organizations. Like an improvisational jazz ensemble, architecture stakeholders need to be able to anticipate the activities of the other stakeholders. If stakeholders cannot plan activities and budget resources, then each transition requires a great deal of effort and time for communication and coordination among the involved parties. Maintaining a rhythm over multiple releases also strengthens the credibility of the architecture supplier.
Our interviews with Allaire Corporation demonstrated how this ability to anticipate enabled the organization to act quickly and efficiently. When Allaire experienced growth, managers knew when in their release cycle to hire testers, when to hire developers, and when to hire customer support personnel. Managers also knew what training to provide and when. Shortages or oversupply of a skill set were identified as a sure sign that rhythm was breaking down.
Rhythm Aids Transition Management
When rhythm is strong, stakeholders build strong skills that enable them to anticipate and execute transitions and handoffs. Organizations are then able to treat transitions as a recurring, regularly planned activity. When rhythm is not strong, transitions and handoffs often come as a surprise. Kathleen Eisenhardt and Shona Brown point out that "because major transitions are periods when companies are likely to stumble, we expected to find that managers would devote extra attention to them. The surprise is that they don't"2 [Eisenhardt98].
Rhythm Drives Closure
lso helps an organization bring activities to closure. "Iterative and incremental releases," writes Booch, "serve as a forcing function that drives the development team to closure at regular intervals" [Booch96]. A study by Connie Gersick illustrates this notion. She observed project groups from six organizations. She found that even though the studied projects ranged from several days to several months, every group exhibited a distinctive approach to its task when it commenced and remained with that approach "until precisely halfway through the group's allotted duration." At the halfway point, she observed that the groups "dropped old patterns, reengaged with their outside supervisors, adopted new perspectives on their work, and made dramatic progress" [Gersick89] (see Figure 4.7). An organization with a good rhythm establishes regular intervals and halfway points to motivate this reassessment and progress.
)
Figure 4.7 Halfway to a deadline, teams typically adjust their approach
and make dramatic progress
Developers can use rhythm to take charge of their fates, even when their parent organization is bureaucratic. In one large, hierarchical information technology organization, a team built a component. Unlike most of the components owned by the parent organization, both the parent organization and customers in other chains-of-command used the team's component. The parent organization controlled the schedule. Component users could not count on timely delivery because release dates were tied to releases of the rest of the architecture, whose tempo was generally chaotic, as illustrated in Figure 4.8.
)
Figure 4.8 Before—The release cycle of the component is tied
to the parent's release cycle.
To resolve the situation, the component team began a regular release cycle, decoupling the release of the component from the release of the rest of the architecture. The component team was capable of delivering multiple releases for each release of the parent architecture. As a result, the component team was able to release more frequently because they cut the time required to deliver a release in half, as illustrated in Figure 4.9. Not only were customers outside the parent's chain-of-command pleased by the predictable schedules, but customers inside the parent organization found it easier to coordinate their releases. Testing became more predictable, quality improved, and customer satisfaction increased. In addition, the parent architecture release cycle became shorter and more regular.
)
Figure 4.9 After—When the release cycle was decoupled, the
component could be released more frequently.