Something is different.
– Good or bad? (Rita)
Anything different is good…
but this could be real good. (Phil)
— Groundhog Day

I’m a relatively young ScrumMaster, so I adopted a retrospective pattern that a colleague suggested to me at the beginning of my tenure. We have been using that same approach for sprint retros for 6 months and it gets the job done. Still, I found myself bored with doing the same old thing for our release retro this month and was concerned about not getting the desired benefit from the process. So I grabbed a promising technique from the Agile Retrospective Resource Wiki called the Four L’s, which Mary Gorman and Ellen Gottesdiener of EGB Consulting developed as a variation of the World Café since they “wanted some variety in eliciting feedback, collectively sharing that feedback and exploring action possibilities.”

The wiki suggests using the Four L’s for “iteration and project retrospectives as well as for retrospection of training and conference events” with a duration of 30 minutes to 2 hours. My 6-member cross-functional team used this technique to reflect on a release and limited our time to an hour, though that wasn’t a hard cutoff. In the context of our release retrospective and the hospitable space of our team meeting room, we gathered our diverse perspectives to explore questions that mattered about how our release went. I titled each of 4 large sticky notes Liked, Learned, Lacked, and Longed For, hanging them side-by-side on a single wall, which was a variation of the suggestion to move around the room. We set a timer of 15 minutes to generate initial feedback for all 4 categories simultaneously and began scribbling madly on uniformly yellow stickies with our Sharpies. Our team ran dry of serious contributions before the time was up, but I think time-boxing activities tends to drive us to get ideas out more quickly.

We read each sticky note’s single idea aloud and then clustered the notes around themes when there was overlap, listening together for patterns and insights. Then, we discussed the whole category among ourselves, hearing out each person’s comments with understanding and humor (we don’t take ourselves too seriously) since we encourage everyone’s contribution to the conversation. We were happy with our technical skills and technologies, but more importantly we have jelled as a team, or made it through the Norming phase of Tuckman’s model. Characteristically, my team identified our successes but did not dwell on them as much as our areas for improvement. We decided we might use the gathered data to satisfy the lacked or longed for items. We posted the following collective discoveries prominently in our team room:

• Iteration
• Continuous Planning
• Continuous Research
• Communication
• Feedback (outside the walls)

These needs resonate with some of the Agile Manifesto principles:

• Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
• Business people and developers must work together daily throughout the project.
• The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
• Continuous attention to technical excellence and good design enhances agility.
• At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

In our efforts to optimize our agility, we are learning from our team’s past and planning for the future so that our results could be real good.