top of page

Jazz Agile: A Manifesto

Shift Quality Editorial
4 minutes ago
10 min read

A proposal for teams who have noticed that the thing they're doing is not Agile, but they cannot say so out loud.



The State of the Industry


Agile is twenty-five years old. The original manifesto, written in February 2001, was four lines of values. Reasonable people, looking at a software industry mired in two-year waterfall projects, suggested four preferences. They were modest. They worked.


Then the consultants arrived.


What we now call "Agile" in most enterprise organizations is something else. The standup has become a status meeting. The retrospective has become a performance ritual. The sprint has become a calendar event. Planning poker has become a forecasting tool for a number that no one will trust. Story points have become a unit of currency in an internal economy that produces no value. In many of the organizations that adopted it, SAFe has institutionalized waterfall and called it scaling. The "Spotify model" has been copied across the industry, while people who worked at Spotify have said it was never fully implemented there: "part ambition, part approximation," in the words of one of its former agile coaches.


The agile manifesto's first value — individuals and interactions over processes and tools — has been most thoroughly inverted by the people who claim to practice it. Modern Agile is processes and tools wearing the costume of individuals and interactions. Engineers are routed through ceremonies they did not ask for, executing tickets written by people who do not use the system, prioritized by people who do not understand the system, on a cadence that has no relationship to the work.


It is time for a new metaphor.


Not because the original metaphor was wrong, but because the original metaphor has been hollowed out. The word "Agile" no longer means what it meant. The artifacts no longer do the work they were supposed to do. The people in the rooms are not the people the manifesto was written for.


We propose Jazz Agile.



Why Jazz


We are not the first to notice that teams doing original work resemble musical ensembles more than they resemble factories. In 1998 the journal Organization Science ran a special issue on jazz improvisation as a model for organizations. Frank Barrett, a jazz pianist and management scholar, set out the characteristics that let a band improvise coherently, and Karl Weick argued that organizational theory's emphasis on order and control blinds it to how innovation actually happens. The metaphor has been around. What has been missing is the application to software teams specifically.


The jazz we mean has little to do with "loose" or "creative" teams. The metaphor is a disciplined small ensemble producing original work in real time, in response to each other, on a foundation of shared repertoire and individual mastery. Every word in that sentence is doing work.


Jazz musicians practice scales for hours. They study the standards. They listen to thousands of recordings. They develop technical command before they ever take a solo. The improvisation, when it arrives, is the visible part of a deep substrate of preparation. The substrate is not optional. Jazz Agile is not a methodology for chaos. It is a methodology for the kind of expert improvisation that only experts can do, performed by people who have done the preparation.


There are four principles.



Principle One: Play the Head


In jazz, the head is the main melody — the theme the ensemble states at the top of a piece, departs from in the solos, and returns to at the end. The head is the thing that gives the piece its identity. Everything else in the performance is a response to it.


A Jazz Agile team has a head. The head is the product vision, stated in a form short enough to be remembered and specific enough to be useful. The team plays it at the start of every project, returns to it whenever a decision needs to be made, and ends every iteration by checking whether they have honored it.


The head is not a sprint goal. Sprint goals are too small. The head is not a quarterly OKR. OKRs are an accountability instrument, not a creative direction. The head is the thing that, if you ran into a teammate in the hallway and asked them "what are we doing," they could say in one sentence without consulting the wiki.


If the head changes every two weeks, you are not playing a piece. You are riffing without a tune. That is a different thing, and it is not what professional ensembles do.


The discipline of playing the head means: you write it down, you keep it short, you do not rewrite it casually, and you check every meaningful decision against it. The team that does this looks slow at the start and is fast everywhere afterward.



Principle Two: Listen More Than You Play


Jazz musicians say the hardest skill is listening. The young player tries to fill every bar. The old player leaves space. The space is where the music happens.


In software, the same skill is required and almost never named. Listening, in a Jazz Agile sense, means:


  • Listening to the system. The codebase tells you things if you read it. The error rates tell you things if you watch them. The customer support queue tells you things if you read the tickets. Most teams do not listen to any of these in any disciplined way.

  • Listening to the team. Who has been quiet lately. Who is repeating themselves. Whose feedback in the retro is the same feedback they gave three months ago. The recurring complaint is a tonic note. It is telling you something about the structure underneath.

  • Listening to the user. Not asking the user what they want. Watching what they do.


The opposite of listening is the standup that asks "what did you do yesterday, what are you doing today, any blockers." That ritual produces speech. Speech is not the same as music. A Jazz Agile team can replace the standup with a five-minute silent check of the dashboards and the support queue, followed by exactly the conversations that the data revealed needed to happen.


The hardest version of this discipline is not playing when you have something to play. Engineers, like soloists, tend to fill bars they were given. The Jazz Agile principle here is that not every meeting needs your voice in it, not every Slack thread needs your reply, not every PR needs your comment. The silence is part of the music.



Principle Three: Honor the Rhythm Section


In a jazz ensemble, the rhythm section — bass, drums, often piano and guitar — holds the form together. They are rarely the spotlight. The horns get the solos. The audience claps for the trumpet player. But if the bass walks unsteadily, the whole performance falls apart. The rhythm section is the band's central nervous system.


The software industry treats its rhythm section the way audiences often treat bass players: as supporting characters, undervalued, easily replaced, and asked to play their part without complaint while the soloists collect the applause.


The rhythm section in your organization is the platform team, the infrastructure team, the SRE rotation, the observability work, the build system, the developer environment, the documentation, the on-call rotation. These functions do not generate the demos that get shown at the board meeting. They generate the conditions under which demos are possible.


A Jazz Agile organization measures the rhythm section the way a jazz fan measures it: how steady is the time, how solid is the foundation, how well do the soloists land when they are taking risks. The metric is not how many tickets the platform team closes. The metric is whether the feature teams can ship without negotiating with the platform team for every change.


When the rhythm section is cut for cost savings, the band sounds like the band with a worse rhythm section. This is not subtle. The soloists feel it within weeks. The audience feels it within months. By the time the executive who made the cut hears the difference, the players have already left for another band.



Principle Four: Bandleader, Not Manager


A jazz ensemble has a bandleader. The bandleader picks the tunes, calls the changes, sets the tempo, decides who solos when. The bandleader is also playing. This is the part that does not transfer to most organizational charts.


A Jazz Agile leader is a player who serves the band. Not a coach (a coach is not in the game). Not a manager (a manager is, in most modern orgs, a person who attends meetings about people who are doing the work). A bandleader is in the work, knows the repertoire, can play any part, and uses that knowledge to make the band sound better than the sum of its members.


This role exists in some software organizations. It is called staff engineer, principal engineer, sometimes tech lead. It is not the same as engineering manager, which is a different job and a valuable one. The bandleader role is structurally distinct: the bandleader is the most musically credible person in the room, and that credibility is what makes their direction worth following.


A Jazz Agile organization promotes its bandleaders without forcing them off their instruments. A Jazz Agile organization understands that the senior engineer who stops shipping in order to manage other engineers has been removed from the band, not promoted within it. That removal is sometimes the right call. It is not usually the right call.


A bandleader who has stopped playing is just a manager with better taste. That can be fine. It is not what we are talking about.



What Jazz Agile Is Not


This is the section that defends against misreading.


Jazz Agile is not chaos. Jazz musicians study harmony for years. They internalize the standards. They develop technical command. The improvisation is the surface of a deep practice. A team that adopts Jazz Agile without the underlying discipline — without strong engineering practices, without good testing, without code review, without observability, without the boring foundations — will produce noise, not music.


Jazz Agile is not "no process." A jazz performance has tight structures. The form of a standard is known. The chord changes are agreed upon. The order of solos is set before the piece starts. What is improvised is what happens within the structure, not whether there is a structure.


Jazz Agile is not anti-Agile. It is anti-the-thing-being-called-Agile. The original four values of the agile manifesto are entirely compatible with Jazz Agile. The two-page consultancy framework called "Enterprise Agile Transformation" is not.


Jazz Agile is not a license to skip the parts you do not enjoy. The standups, retros, and planning meetings exist for reasons. The Jazz Agile claim is that those reasons can be served by different forms, designed by the team for the team, evaluated by whether they actually serve the music. If your retro produces real change, keep it. If it produces a list of action items that no one will read, replace it with something that produces change. (Sprint Retrospective Templates: Five That Work has formats worth trying first.)



The Monday Morning Question


What does this actually change on Monday?


For most teams, one concrete experiment is enough to start. Pick one of your current ceremonies — the one you secretly suspect produces the least value — and replace it for two weeks with a Jazz Agile equivalent.


If it is the standup: replace it with fifteen minutes of silent reading of yesterday's dashboards, error rates, and support tickets, followed by a five-minute discussion of only the things that surprised someone. No round-robin updates. No status reports. The data tells you who needs to talk to whom.


If it is the retro: replace it with one question, asked of the team and answered in writing before any discussion: what did we listen to this sprint that we should listen to more? Then talk about the answers.


If it is the sprint planning: replace it with restating the head, looking at what the system told you in the past two weeks, and naming the three things you are going to play next. Skip the estimates.


Two weeks. See what happens. Keep what works. Reinstate what you missed.


How you will know


Decide before you start what would count as the experiment working, or the result will be whatever the loudest person felt. Three signals are cheap to collect and hard to argue with:


  • Conversations triggered by evidence. Count how many of the follow-up conversations started from something on a dashboard, in an error log or in a support ticket, rather than from someone's status update. If the number does not rise, the team is not listening any differently; it has just stopped talking.

  • Surprises caught early. Note how many issues the team found in its own data before a customer, another team or an alert told it. This is the listening principle made countable.

  • What people missed. At the end, ask each person in writing what they missed from the old ceremony. If three people independently name the same thing, that thing was doing real work. Put it back in a form that does that work and nothing else.


One team's two weeks


Composite example, assembled from common patterns. The team is invented.


A seven-person payments team replaced its daily standup with fifteen minutes of silent reading: the previous day's error dashboard, the deploy log and the twenty newest support tickets tagged to the team. Each person wrote one line in a shared doc about anything that surprised them, and only the surprises were discussed.


In week one, the doc had nineteen surprises. Most were noise, but two were real. A spike in card-declined errors traced back to a config change another team had shipped, and a cluster of support tickets showed customers misreading a refund status label. Neither would have come up in a round-robin update, because nobody on the team was working on either.


In week two, the team found what it had lost. Two engineers said they missed hearing who was stuck, because silent reading does not surface a person blocked on a code review. The team kept the silent reading and added one written line per person: "blocked on / waiting for." That was the work the old standup had been doing underneath the status theatre, and now it had a form that did only that.


This is the practical heart of Jazz Agile: you cannot adopt a methodology by reading a manifesto. You adopt it by playing.



A Note on the Manifesto Form


We are aware that publishing a manifesto for a methodology called Jazz Agile is, on its face, the kind of thing this manifesto is critiquing. There is a frame in which the most consistent expression of Jazz Agile would be not writing this document, naming nothing, and simply playing.


That frame would be more pure. It would also be less useful. Teams that want permission to work this way need a name to give it, a vocabulary to use when explaining it to their executives, and a reference document to point at when someone says but that's not how Agile works. This piece is the reference document.


Take it, edit it, fight with it. The point is not that you agree with these principles in this form. The point is that your team has a way to talk about what it is already trying to do.


The point of any methodology is not the methodology. The point is the music.


For a less lyrical take on the same problem, Agile Without the Nonsense covers which practices earn their place.


Sources




Part of the Perspectives guide — ShiftQuality's field notes on building, AI, and business.

bottom of page