Punctuated Continuity: Using Ritual and Ceremony to Avoid Process Fatigue
Agile methods like Scrum and XP involve repetitive meetings and actions that can become routine and lose freshness, challenge and novelty. How do we put “heart” into agile processes? How can team members inject variety or even whimsy into what they do every day? What are effective ways to “punctuate” agile routines? And what exactly is “Haiku-Driven Development (HDD)”? In this workshop, we’ll review actual experiences with teams practicing XP and Scrum, and provide examples of how teams avoided having agile processes become more albatross than aid.
I’ve experimented with this topic a number of times, in venues small and large, and drew interest from a number of “thought leaders” who encouraged me to develop it further. And so I have. Almost everyone I’ve talked to contributes their own stories and experiences of what worked and what didn’t. I’m excited about hearing about those, discussing them with practitioners, and then producing something article- or paper-like that can be a continuing resource for the agile community.
So I’ll start with a non-PowerPointy presentation describing what I’ve experienced and gathered to date, then segue into an exercise that helps the group discover a thing or two that might work for punctuating the session itself — or maybe I’ll do those things in reverse order, or stick the exercise into the middle of the presentation. That’ll take 30 to 45 minutes, based on past experience with this material.
Then we’ll work on the more workshoppy part of things, learning how to create then collaboratively creating haiku that offer insights or observations on agile practices and problems, in the style of the famous computer haiku that have circulated around the Net for years:
A file that big?
It might be very useful.
But now it is gone.
The Web site you seek
Can not be located but
Countless more exist.
Here’s a fantastic example, culled from a version of this session given at the Sprint 2008 Scrum Gathering:
Thirteen point story. Sprint ends; story still not done. Thirteen points too big.
(author unknown, but being sought — contact me and claim authorship, please!)
We’ll gather the results of the session and publish them, in Wiki and maybe even booklet form (credit for that idea going to Jean Tabaka, my muse in this endeavor). At the end of our time, we’ll all have ideas and inspiration on how we can help our teams find freshness in their methods. Attendees will walk away from this talk asking “I wonder if we could do that?” and with some techniques for helping their team find out what might work for them.
The talk consists of some examples of what teams have found to work for them, but then discusses how each team is different, and suggests ways a team can discover their own approaches. Sure, you could say “what would make this more fun for you?” but it’s been my experience that many teams don’t know what that might be (beyond, maybe, having planning sessions in a bar… ;-) )
Some examples:
I worked with an XP team that, for their own reasons, wanted to track the “actual” time they spent on a story and compare it to the “ideal” time — but they kept forgetting to write down when they started a story. (As a poster elsewhere commented, yes, this is pretty much a pointless pursuit, but it was Mostly Harmless — I was sure that the practice would die out once the team realized that it didn’t produce any value). This came up in standup, and we wondered if there was some ritual or habit that might cause the devs to remember to write down the time. Our IT guy, standing off to the side, jokingly suggested, “Well, you could write a haiku.” Everyone laughed. But later that day, the suggestion took root, devs wrote haiku before starting a story and didn’t miss writing down start times anymore. This turned out to have some unexpected, positive side-effects as well, one of which was that the CEO started regularly finding time in her schedule to listen to the team’s review of stories so that she could hear them read the haiku!
Planning meetings had turned into slogs that, while producing a good set of stories for the iteration, ended “with a whimper.” Much of the team shared an interest in Zen and Eastern ritual; on a lark, the customer proxy started presenting the set of chosen stories to the team with a miniature ceremony, with a representative of the team accepting the stories. From that grew a ritual of offering along with the user stories a choice of Zen stories, which were then read and reflected upon. We managed to turn a “petering out” ending into an end that had the team leaving with smile and thoughtfulness.
There are a lot more, of course, and I hope to gather even more at this session, along with presenting ideas on how a team can discover or stumble upon its own rituals, instead of having them imposed by a well-meaning Scrum master or team member.
So the point of the talk is not “try these things and your team will be happier” — it’s “here are things that worked for some teams, and how we discovered them; here are some hints on how to stumble on what you don’t know you’re looking for!”