Agile’s success depends, to a great extent, on the seriousness with which the team performs the prescribed ceremonies. Thou shalt start a sprint with a real sprint planning meeting. Thou shalt always end a sprint with working code, which thine customers and stakeholders shall comment upon. If thine daily stand-up meeting goes longer than 15 minutes, then lo! Someone needs to put a cork in it.
Agile keeps the list of ceremonies small, and the ceremonies themselves fairly lightweight. They serve the same purpose as any ritual, to encourage both right behavior and right thinking. Unfortunately, there are not enough of them.
Agile ceremonies must reach beyond the team
The founders of the Agile movement may have spoken with the tongues of angels, but they couldn’t address every imaginable topic. The primary focus of Agile practices was, and still is, the team. Changing the way that development teams operated was the proverbial mustard seed that would one day grow into something bigger, disrupting everything from deployment methods to requirements elicitation, from portfolio management to testing. But the team needed to change first, by following a new cadence of ceremonies as regular as Matins and Vespers.
In organizations where Agile has enjoyed initial success, other people outside the development team soon feel the effects of this conversion. When the team goes out among the Gentiles (i.e., the rest of the software value chain), there are no ceremonies guiding these interactions. Whether the team is trying to collaborate better with the customer, the operations team, and others, methodologies like Scrum are silent. Maxims like Listen to the voice of the customer and Try to see the world from the data center’s perspective are, in the end, statements of principle, not specific guides to action.
In some areas, like the troubled DevOps relationship, Agilists have already started building a toolkit of new techniques to complement and enhance core Agile practices. For example, continuous delivery doesn’t, on its own, heal the DevOps schism, but it’s an important and necessary step forward.
In other areas, Agilists have made less progress. In fact, some try to cloak themselves in false Agile piety to rationalize continued bad behavior. Why talk to customers once a year, if we can’t really do anything with that feedback? transforms into Why talk to customers at all, if they can’t make themselves available every two weeks?
Fortunately, new ceremonies do exist, but they are not yet widely known. They’re not a direct product of the Agile movement, but Agilists can easily adopt them to their purposes, with no greater difficulty than re-branding Saturnalia as Christmas. The ceremonies in question are a particular species of serious games.
Serious games change the normal rules of work, including customer interactions
I’ve been doing some Agile training and coaching lately, during which the conversation has often turned in the direction of value. How do we understand value, from the customer’s point of view? If you can’t answer this question, there’s no way to tell that any given sprint is producing something that the customer will embrace.
Unfortunately, the answers are lost in a murky river of frequent miscommunication. Customers don’t make themselves clear. Developers don’t listen carefully. Customers ask for more than they strictly need, which is hardly surprising when you consider how often they’ve received far less than what they originally requested. Developers don’t take the time to learn about the customer, because they’re too busy writing and delivering code in the name of the customer.
In this situation, development teams need a rapid, reliable way to gain better insights into the customer. They should be just as lightweight as Planning Poker, and just as collaborative. In other words, the new ceremony needs to change the normal rules of interaction just long enough, and just profoundly enough, to achieve an epiphany or two.
That’s how games like Buy A Feature and Prune The Product Tree can become new Agile ceremonies. These are brief exercises, taking no more than an hour to run (though some preparation is necessary). These games are structured, so they don’t let the customers playing them do anything they like, repeating bad behavior in the process. The games are engaging enough, and yes, fun, so that the participants are willing to let these new rules constrain their behavior.
When I talk to clients about their requirements woes, and the further problems that bad requirements generate, I start with the litany of traditional responses. Yea, though I walk through the valley of the shadow of deadlines, I shall still take time to validate what customers told me. Love your developer as you love yourself, so write requirements that she can actually use. And so on.
I deliberately don’t say anything about serious games until the end of this litany, because I don’t want to evangelize to people before the limitations of traditional approaches become clear. These other techniques have their merits, but they don’t change the conversation with the customer in the profound way that serious games do. All I have to say is, “In Buy A Feature, the customers will be negotiating with each other, not you.” Immediately, the client sees how, in the brief duration of a single game, customers will reveal their wants and needs in previously unimaginable ways.
You can read more about these games through the links I’ve provided above. I’ve also started a site with the ambition of helping people match the type of challenge they face (not just understanding customer value) with a game that may help them. Defining the minimum viable product, driving home the important lessons of Agile planning, and synchronizing activity with non-Agile teams are just a few areas where serious games provide the ceremonies missing from the Old Testament of Agile.