Tag Archives: agile

distributed retrospectives with a twist

Posted on by
Reply

In  the traditional agile retrospective, everyone gets in a room and puts post it notes on a board.  The group then sorts the post its by topic.  Then there is discussion about the points brought up.  I find there are a few limitations with this approach:

  1. It requires everyone to be in the room at the same time.  This isn’t always easy.  (Especially if the team is distributed or partially allocated to other teams.)
  2. Everyone has to watch the sorting exercise.  Throwing more people at this doesn’t make it faster on a big team.
  3. People get worn out by the long meeting.
I’ve done about a dozen retrospectives where people write on post-its in advance of the retrospective and leave them in a shoebox.  (We’ve extended this to having the shoebox available for the length of the project so team members can add thoughts as they occur.)  We then have myself and another team member group the post its by category.  Then we use the actual retrospective meeting for discussion/brainstorming.  For members located remote, we let them e-mail post-it notes.  This loses the anonymity, but people haven’t seemed to mind.
At he end of the season, the programmers of Stuypulse do a  lessons learned over e-mail.  We had more new programmers this year that stuck with the team than ever before.  I wanted to make sure we got their input and the brainstorming wasn’t “biased” by older team members.  I suggested we do a retrospective.  It was an experiment for me too as I’ve never done one completely remote (or without post-its or a shoebox.)  Remember that these are high school students and it is likely they’ve never done any type of agile retrospective before.  Here’s what went down.

Phase 1 – post it generation

I searched if there was an online retrospective website and didn’t find anything.  [If anyone reading this knows of one, please post a comment.]  Instead of post-its, I created a google docs spreadsheet with the following columns:

  • green background – What did we do well?
  • red background – What should we do differently?
  • blue background – What did we learn?
  • purple background – What still puzzles us?
  • Division – I wanted to record whether the comments were coming from a programmer or someone in a different part of the team as perceptions were likely to be different.  This turned out to be a non-issue as only one non-programmer contributed content.  (Which is interesting because when we did lessons learned on the mailing list, we had lots of comments from engineers.  This may still happen in phase 3, but at least programmers got to frame the discussion about programming in the brainstorm phase.)
  • Optional name – In case there we wanted to clarify something.  Only one person choose to be anonymous.  This column turned out to help me because a week after I sent out the request to participate, only the more senior members of the team had contributed content.  This allowed me to “re-invite” the newer members by name.  If everyone was anonymous, I would have just known that turnout was poor but not why.

Phase 2 – post it sorting

Ina corporate environment, I just sort/group the post its.  With the high school team, I also edited a little.  Just to avoid “I agree with so and so” because the sorted post its don’t have names on them.  This took me about an hour.  I did not edit the items for length even though some contributes were sentences (which is really long for a post it note.)  I also added a couple post its to round out groups and get at missing subtext.  I’ve added post-its while grouping in a corporate environment too when the contributed post-its dance around an issue.  This is actually the first time I’ve grouped post-its without having an “other” kitchen sink category!

Now that we are ready for phase 3, the spreadsheet has three tabs:

  1. raw data – what people contributed
  2. grouped – data from tab 1 grouped by category
  3. a summary of the categories, # posts its in each category and a summary with some questions for discussion (in a corporate setting, I order the categories by # posts but don’t come up with questions.  I did here because phase 3 will be over e-mail)

Phase 3 – discussion

This hasn’t happened yet.  I’m sending the spreadsheet out today.  I expect it to be like the lessons learned e-mail threads of the past though.  Which is fine now that we’ve gotten the topics to talk about out there.

the trust cycle vs the hype cycle

Posted on by
Reply

Most of have seen the Gartner hype cycle graph – shown here from wikipedia.  This got me thinking about what would happen if we tried to do the same thing – except with trusting our teammates to see how they compare.  I’m calling that the “trust cycle.”  While we do hear a lot about trust and team in agile, the only place I found using the term “trust cycle” wasDavid Weiss’ blog.

The beginning:

With the hype cycle, we start at basically zero.  We haven’t heard of something and we remain skeptical until we hear a little.  Then we get too excited.

With the trust cycle, I think you start more in the middle.  When you first meet someone, you don’t inherently trust or distrust them.  And at the beginning, people are pretty cautious and don’t do anything to change that.

The middle

With the hype cycle, the trigger for change is reality.  We go from inflated expectations to seeing what the technology can really do.  Since our expectations were too high, we fall harder.

With the the trust cycle, the trigger for change depends on whether it is positive or negative.  For positive trust (teambuilding), it just takes time.  Our trust level slowly goes up until we trust the person fully.  For negative, the jump happens much faster.  Either as a series of little things that make you suspicious (as shown in the graph) or as one big thing that causes a series drop.  Once we’ve dropped, trust either stays at rock bottom or gets re-earned very slowly.

The end

Both cycles stabilize at the end.  The hype cycle stabilizes at reality.  The trust cycle stabilizes at either trust or distrust.

Conclusion

This stickyminds article talks about how to build trust.  What do you think about the trust cycle?