The Good, The Bad, and The Mail-It-In

Teams benefit from regularly examining the ledger of what Worked Well and what Needs Improvement.

The agile Retrospective is the periodic, iteration-ending team-reflection session met with joy, dread, or indifference.

What’s Your Experience?

I’m curious,

  1. Are you comfortable with the heavy lifting called for in true team reflection?
  2. What were the defining characteristics of your most productive retrospectives? 
  3. What is the appropriate level of ceremony? 
My Experience

Retrospectively, I can recall The Good, The Bad, and The Mail-It-In.

One team had the common sense to rotate leadership amongst team members, so each retrospective had a different flavor. It made it lively. It kept it fresh. All good.

Another team, having grown impatient with the lack of candor, adopted a variation of the ritual of passing the rock, dubbed passing the action figure. An action figure, bestowed with alchemistic powers, was passed to each team member.

If you held it, you were expected to say something that was bothering you, something uncomfortable, something controversial, or something wildly informative about team dynamics. Again, good.

Other sleep-walking teams mail it in. For those teams, the retro is just another check box on the list of agile ceremonies.

    Mail-It-In Retrospectives

    I stumbled on a promising antidote for Mail-It-In Retrospectives called Theatre of the OppressedAugusto Boal (1931 – 2009) was a Brazilian theatre director, writer and politician. Boal founded Theatre of the Oppressed.

    A facet of Boal’s Theatre of the Oppressed is Forum theatre described as follows:

    1. Actors perform a play with a script that includes a relevant form of oppression.
    2. At the end of their first performance, where the oppressed in the script do not overturn their oppressors, the actors begin a second performance of the play. 
    3. In the second performance, any audience spectator – called a spect-actor – may call out stop!, then replace of the actor portraying the oppressed character. The actor stays at the side of the spect-actor.
    4. The spect-actor tries to overturn the oppression by using methods untried by the actor replaced. 
    5. The actors portraying the oppressors then improvise, in response to the spect-actor, attempting to steer the performance back to its original script of unabated oppression.
    Some project teams I have participated in coexist with mild, usually subtle, forms of oppression. Oppressive behaviors are uncomfortable to confront. Discussion of these behaviors rarely bubble up in retrospectives. Unresolved, they can be burrs in our collective saddle, or worse. At best, they kill our mojo, often strangling the free flow of ideas.
    I don’t need to enumerate. They’re personal and team issues. You know what they are, so act!

    4 thoughts on “The Good, The Bad, and The Mail-It-In

    1. @project timesheet. I really like your moniker. Agree with your observation too. Some teams have agile rammed into their culture by a pointy-headed boss. Developers smell a rat and mail it in.


    2. I identify 2 topics that I want to comment on.

      1) Group dynamics. The “what works” “what doesn't work” is a great thing. But it fails when their isn't enough trust to be able to say “This doesn't work”.

      2) Agile. I've been part of Agile development for over 2 years. …how to say this… it's no better than not using Agile. Different problems, different gripes. It isn't going to revolutionize software development. It isn't going to reduce backlogs or improve quality.


    3. @MadTom – Thanks for the comments.

      (1) I'm with you about the importance of trust. The other problem is follow-through — It's great to be able to say something doesn't work, but then there should be action items for the “fix”. Then in the following retro, the team looks back to see how they did on the “fix”. So trust and follow-through are essential otherwise it just seems like a stupid ceremony that no one gives a rip about.

      (2) Are you speaking from a code developer's point of view or product developer's? For me, I've found agile to be much more “humane”. That is, developers are not putting in crazy hours and the business accepts the pace at which we produce because they're pretty close to the trenches and know the hurdles we're jumping.

      Just curious, does the “Mad” in your MadTom moniker imply craziness or anger or neither?


    Leave a Reply to MadTom Cancel reply

    Fill in your details below or click an icon to log in: Logo

    You are commenting using your account. Log Out /  Change )

    Google photo

    You are commenting using your Google account. Log Out /  Change )

    Twitter picture

    You are commenting using your Twitter account. Log Out /  Change )

    Facebook photo

    You are commenting using your Facebook account. Log Out /  Change )

    Connecting to %s