Jazz and Collaboration, A Cho

The Jazz Process

By Adrian Cho, February 18, 2010

What can software developers learn from jazz musicians?

Adrian Cho has worked in the software development industry for more than 20 years as a consultant to banks and research development labs at Fujitsu and IBM and as a key contributor to multiple class-leading and award-winning software engineering and team collaboration tools. He currently manages the development of IBM's Rational Team Concert and Rational's Collaborative Application Lifecycle Management project at jazz.net. Adrian is also a freelance jazz musician, the Artistic Director of the Impressions in Jazz Orchestra and the author of upcoming The Jazz Process: Collaboration, Innovation and Agility, to be published by Addison-Wesley this year. You can contact Adrian at jazzprocess.com


Software development projects fail all the time. Teams deliver late, blow out budgets, underwhelm or disappoint users with missing or deficient functionality or simply crash-and-burn before reaching their goal. Why do some projects and teams perform so poorly? For decades the practice of software development has focused intently on tools, technology and intricate, heavyweight processes. Wave after wave of programming interfaces, frameworks, toolkits, and methods have come and gone, each accompanied by a horde of evangelists and zealous practitioners. These people will be the first to tell you that failed projects are a result of using the wrong technology or process. They may even try to sell you the right one. While such things can make a difference, there is an easier way to fail.

In software development, multi-disciplined teams must collaborate and innovate with agility. Disciplines of requirements analysis, design, development, testing, finance, and in the case of software products, sales, marketing, and support, must work in concert to produce creative solutions while constantly reacting and responding to change. Change may be generated from within an organization or externally. Changing business conditions or the actions of partners or competitors are examples of external change. A software development team is similar to a basketball team, a squad of soldiers, or a group of jazz musicians. This may be surprising since each activity has completely different domain-specific practices. Basketball players must be able to handle a ball and implement game strategy. Soldiers must be skilled in various aspects of combat while following orders. Jazz musicians must be able to play instruments and navigate through a musical form. Software developers must be able to write code and adhere to a development process. Yet none of these groups can succeed without effective collaboration and the ability to execute on a plan, or as it sometimes happens, in the absence of a plan.

Like software developers, jazz musicians must work in synergy to deliver unique, high-quality offerings that will attract and retain customers. They must deliver on-time and in real-time, often under continuous scrutiny. They do this by integrating strong individual contributions from passionate and committed practitioners and ensuring success with best principles. The Jazz Process is a framework for improving collaboration, innovation, and agility with a method for execution and 14 best principles that act on that method. While its primary inspiration is jazz performance, the process draws on examples of excellence in business, software development, music, military operations, and sports, while applying laws of sociology, psychology, physics, biology, and systems theory.

Jazz Process Principles

  1. WORKING
  2. Use Just Enough Rules
  3. Employ Top Talent
  4. Put the Team First
  5. Build Trust and Respect
  6. Commit with Passion
  7. COLLABORATING
  8. Listen for Change
  9. Lead on Demand
  10. Act Transparently
  11. Make Contributions Count
  12. EXECUTING
  13. Reduce Friction
  14. Maintain Momentum
  15. Stay Healthy
  16. INNOVATING
  17. Exchange Ideas
  18. Take Measured Risks

The execution method of the Jazz Process is based on the OODA loopdeveloped by Colonel John Boyd, a legendary maverick U.S. Air Force fighter pilot, military strategist, and aircraft designer. Boyd believed that agility was the key to winning dogfights or any other competitive situation. Tactics used in Desert Storm were patterned after Boyd's theories and many business methods such as Plan-Do-Check-Act (PDCA) are similar to his method. The name "OODA" comes from the four phases in the loop:

  • Observe: Acquire all potentially relevant data including that which originates from collaborators (those we work with), consumers (those we work for), and competitors (those we work against).
  • Orient: Interpret that data as useful information.
  • Decide: Make the best decisions while avoiding groupthink, the not-invented-here syndrome and the many other cognitive biases that can skew good individual or group decision-making.
  • Act: Execute on the decision in a correct and rapid manner.

The goal is to do all of this more rapidly than the competition although it's important that execution speed shouldn't sacrifice quality and correctness. Paths of re-observation (look twice), re-interpretation (reconsider what was observed), and evaluation (try something before committing to a decision) may increase cycle time while feed-forward (predict by guessing or experience) may shorten it. Individuals, teams and organizations all execute in OODA loops.

The principles of the Jazz Process affect the execution of the loop. There are five principles in support of working.

  • Use Just Enough Rules is right-sized governance with just enough process to avoid chaos and confusion while affording people the autonomy to get things done. Processes must be continually improved by being honest about problems and less-than-optimal execution and updating rules and practices for greater future success. Tools such as IBM's Rational Team Concert, built on IBM's Jazz team collaboration platform, allow processes to be defined and customized in a way that tools can enact and enforce the process and guide people to do the right thing.
  • Employ Top Talent focuses on hiring and retaining the best people possible. Aim for quality and not quantity. One genius may succeed where 1,000 others failed. The Manhattan Project's race to develop the atomic bomb employed more than 130,000 people but it was a small group of individuals, the project's scientific and engineering geniuses, who were most vital to the project.
  • Put the Team First places the team's goals before those of any individual. The team succeeds together and absorbs mistakes together.
  • Build Trust and Respect and Commit with Passion are essential. Trust enables everything to happen more quickly. Respect allows people to contribute without fear. Commitment wills people to push through in spite of challenges. Infectious passion excites and motivates others to participate and consume.

There are four principles in support of collaborating.

  • To Listen for Change is to know what's going on at all times. Not surprisingly, jazz musicians place great importance on the skill of listening. If one jazz musician remarks that another jazz musician has "big ears" it's a compliment that means the person is constantly aware and ready to respond to change and that they are open to exchanging ideas. Listening in the abstract sense is acquiring all relevant data to understand what's happening in the team, what customers are thinking and what are competitors doing. Team awareness is vital to working together. It helps avoid conflicting and duplicate efforts and facilitates synergy from complementary efforts. Rational Team Concert makes team awareness a high priority and this is especially important for geographically-distributed teams.
  • Lead on Demand is about taking initiative. However this can only happen when organizations decentralize leadership and give people the power to make decisions and act.
  • Act Transparently focuses on open and honest communication. When others can see what's going on it makes it easier for them to collaborate. Customers also appreciate openness, hence the success of open source projects and IBM's Open Commercial Software Development taking place atjazz.net.
  • Making Contributions Count is to carefully consider the effort, value, and impact of everything we do. It only takes one careless contribution to break a software development build.

In support of executing are three principles.

  • Reduce Friction is actually about optimizing friction. Friction is resistance that can increase the difficulty and/or time taken to complete a task. Some causes of friction don't seem like a problem until you have to perform that task frequently. Yet you must have some friction. Without it we couldn't walk and objects would slide off even slightly sloped surfaces. Business controls such as legal and finance are often seen as impediments by software developers but without any such controls an organization exposes itself to intolerable risk.
  • Maintain Momentum promotes continual progress by establishing regular cycles and rhythms for such tasks as planning, software builds, meetings, and so forth. This is the essence of iterative software development methods.
  • Stay Healthy alerts us to the fact that injury to a project or team can impair performance. Left untended, poor health may degrade to a total loss of stability. It also discourages people from consuming or participating -- the Broken Window Theory. In software development, build health is everything and broken builds must be repaired immediately.

Finally, innovating is pursued through two principles:

  • Exchange Ideas is the key to innovation fueled by diversity. A team with diversity in technical experience increases divergent thinking which enables more possible solutions to be generated. At the same time it increases convergent thinking which improves selection of the best possible solution.
  • Take Measured Risks is reality. While it makes sense to only undertake tasks that are free of risk, it's not really practical. Few things that are truly risk-free and anything that is will most likely be exploited by your competitors, thereby reducing the likelihood that it could provide you with a competitive advantage.