I always thought the analogy would be cheesy, but Adrian Cho’s “Jazz Process” is a carefully researched and well presented “framework for improving collaboration, innovation and agility inspired by the way in which jazz musicians deliver strong, innovative performances.” Mr. Cho, with deep roots in both jazz and application development, presents a method for app dev teams to work together the way jazz musicians do to “deliver on-time, high-quality performances that will attract and retain customers and do it all in real-time under continuous scrutiny.”
To put cards on the table, while Mr. Cho is a dedicated dual-career professional who plays jazz at the highest level, I’m a dedicated IT professional who spends some evenings as a serious amateur at local watering holes and private parties. To me, Mr Cho really nails it. He groups 14 principles into four categories on how teams can effectively work, collaborate, execute, and innovate together, bringing honed skills, “big ears”, trust, and commitment to deliver successful outcomes.
Does the Jazz Process work? Only time will tell if it catches on in the business world, but from my experience the Jazz Process does describe how musicians work together. The two concepts I particularly like are the importance of developing a technical base and the need for humility. Mr. Cho quotes Vijay Govindarajan, who wrote: “The more humble you are, the more you know what you don’t know; you seek to learn” – something John Coltrane might have said.
From the point of view of a jazz-playing IT guy, however, two important topics seem to be de-emphasized in the Jazz Process:
Those who don’t know history don’t know how to repeat it
Every jazz player I know is also a jazz historian, and knows that Coleman Hawkins’ version of “Body and Soul” is a landmark of harmonic improvisation, and if they heard Pentangle’s song “I’ve Got a Feeling” they would know it as Mile’s Davis’s “All Blues.” An accomplished jazz improviser might weave into a solo phrasing or melodic fragments borrowed from jazz greats of the past, which jazz aficionados would recognize and applaud.
How many application developers know that during the early ’70s Larry Constantine first conceived the concepts basic to Object Oriented design, and how many know the (perhaps apocryphal) story that he borrowed them from the social sciences? How many know about Edsger Dijkstra’s landmark article called “Go To Statement Considered Harmful”?
If I’ve stumped you, don’t worry, you could probably stump me just as easily. The point is that, unlike jazz musicians, we in app development have a culture that tends not to respect and build upon the past. As we gain new tools and methods we seem to discard the old ones (does anyone remember Warnier-Orr diagrams?), and we often forget the hard-won lessons of the past (how many process analysis and redesign projects skip logical modeling, causing the new process to retain unnecessary steps related to old systems?)
Play it for the people
In a very real and direct way, the audience is a huge part of any musical performance. The jazz player is not only aware of the style needed for the gig (background, dance, concert, etc) but also of the “feeling in the room”. There’s a gestalt in the performance space that is difficult to explain but very apparent to a musician. Jazz musicians not only constantly listen and interact with each other, but also constantly feel and feed the vibe in the room.
Similarly, excellent development teams are constantly aware of and constantly cultivate good feeling in their organizational community. I was fortunate enough to be involved in a development effort where key business people we were building the application for worked overtime so they could be involved as testers, in part because the system was critical to their process but also because it was a really dedicated and energized group.