As I thought about what I'd like to do here, the image that sprang to mind was a jazz combo. There's a selection of songs, even standards, that we might play here. How we play them is controlled by the song, the participants and the interplay between them, and the soloist at a given time. There's tension, straining against the beat, there's improvisation within a set of rules. (If you have to ask what they are, you ain't never gonna know.)
Jazz has a lot in common with software development, improvisation inside of a controlled structure. The Dikel, Wilson, Kael Software Architecture book has a section on rhythm's importance to software projects:
"Rhythm is important to any development process, but especially for architecture-based development. Rhythm can battle complexity, keep competition off-balance, and maintain sanity and predictability for architecture and development teams.
The sharing of an architecture is like an improvisational jazz ensemble. Each player in an ensemble is autonomous, but each musician's performance is coordinated by cues exchanged with the other musicians as well as the tempo, key, and style of the performance. While the basic elements of the performance may be written down or planned, many elements are performed by the musicians relying on their instinct, training, and talent.
Just as a jazz combo must share a common tempo, phrasing, and progression to have a rhythm, an architecture team must share work products with predictable timing, content, and quality. Software architectures are developed and used in many different organizations. Since many of these groups are autonomous, it is not possible to fully coordinate all of them from the top down. Without rhythm, sharing an architecture can befuddle even the best-designed schemes for communicating across teams.
The authors describe rhythm being instrumental (sorry) in driving tempo, content, and quality and illustrate how patterns like daily build create tempo in a project. If you study OODA loops one thing you will find is that success is driven in large part by cycling faster through your decision loops than your opponent. This brings me to my chief complaint about big business: don't be afraid to make a decision and act on something. Projects can fail because of a lot of factors like not enough budget, not enough expertise, market factors, but the biggest avoidable failure condition that I see is lack of velocity. Observe, orient, decide, ACT.
Awhile back, I wrote about it as well:
In Cuban Jazz music, the drummers’ goal is to aim for a “light touch” providing rhythmic structure to influence the band’s direction without overpowering the other instruments. Similarly, the Software Architect’s biggest ongoing challenge is to find the right balance of maximizing positive influence while minimizing distractions from the software project’s main goal: cost-effective, quality software.