Agile Pain Relief

May 27, 2010 in Agile, Agile FAQ by Mark Levison

Continuous Improvement and Short Feedback loops (think: Test Driven Development; Sprint Demo/Review; …) are at the core of any Agile process. Without a structured improvement process it can be difficult for teams to improve and without improvement we stagnate. For methods like Scrum, XP and et al Retrospectives are that tool.

What is a Retrospective? It is a moment for the team to stop, breathe and take a break from the day to day grind. Its a chance to step back and reflect on the past iteration. To find things that worked well, things that need improvement and what the team has the energy to improve.

How do Retrospectives differ from Post Mortems (see CIO Update and PragmaticSW)?

• Post Mortems occur after the project is done (or even dead), when it’s too late to improve that project.
• Post Mortems are long feedback loops, once per project might mean every 6-18 months
• Post Mortems often generate nice reports that are placed on a shelf and ignored (also called write only documentation).
• Post Mortems sometimes turn into blame and shame events.

Well run retrospectives provide an opportunity for small improvements. The keys to a well run Retrospective:

• Retrospective Prime Directive (Norman Kerth): “Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.” The key here is to remind participants at the start of every retrospective this is not a blame and shame. Its about understanding what happened in the course of the last iteration. The focus is on events and not the people.
• A clear agenda – a simple one:
  • What happened in the last iteration (including what SMART goals did we achieve?)
  • What would like to celebrate/remember/…
  • What areas need improvement?
  • What do we have the energy to improve in the next two weeks?
• Clear Ground Rules see: Meeting Ground Rules Updated
• An Open Mind from all team members with the focus on solutions and not the problems.
• Appreciations – just take a few minutes to share something that you really appreciate that someone else on the team did. Interesting twist I just noticed that Ellen Gottesdiener puts appreciations at the beginning of her Retrospective. That’s very interesting, that will help put people in a positive frame of mind and make it easier to tackle the problems later. Elegant.
• Once you decide what you have the energy to tackle, set SMART Goals (Specific, Measurable, Attainable, Realistic/Relevant, Timely). See: SMART Goal Setting. In the context of an Agile/Scrum team I would always make timely less than two weeks, so that you check back in the next retrospective.
• A great facilitator who is able to stay out of the conversation and maintain the flow. Bring an outsider in occasionally, just to see a different approach.
• Mix-up your retrospective activities to maintain the energy and interest
  • Agile Retrospectives: Making Good Teams Great by Diana Larsen and Esther Derby,
  • Timelines and Mad/Sad/Glad:  (lots of other good retrospective ideas too)
  • SaMoLo (Same of; More of; Less of)
  • Retrospective Wiki

Follow-up:

• Post your SMART goals on the team’s Information Radiator and check up on them in the Daily Scrum.
• If you don’t make the improvements that people choose then Retrospectives will quickly lose their value as people say: “Nothing ever happens from these”.

When: At the end of every iteration or sprint. Allow one hour for every week of iteration. So a 1 week sprint would have 1 hr, 2 weeks a 2 hour retrospective. 3 weeks a 3 hour retrospective, 4 weeks – no one does those anymore right?

Who: The whole team – I like to see (or hear) the Product Owner and the Scrum Master. Some people will tell you that the PO isn’t necessary. Fine, but if they’re not there they can’t help make things better.

April 19, 2010 in Agile, Agile FAQ by Mark Levison

Glenn Waters gave a great session at Agile Ottawa a few days ago, it was a combination of conversation, workshop and talk. As part of the session we identified many ways standups breakdown.

So what did we find going wrong:

• Not held daily
• Boring – no commitment or engagement
• No perceived value
• Too much talking and chit chat (socializing, wandering off topic)
• Not adhering to the 15 minute rule
• Being late and not showing up
• Directed, i.e. one person taking over and telling team members what to do.
• Reporting Directly to a manager vs. sharing with the team.
• Not reporting to the team
• Mumble, mumble disease, i.e. team member not saying anything that the rest of the team can understand.
• Trivia report – reporting in so much detail that no one understands or cares.
• Repetition – someone saying that they worked on one story several days running.
• Not raising impediments
• Not prepared
• Problem solving

February 18, 2010 in Agile, Agile FAQ by Mark Levison

Like clockwork every month, someone on one of the Agile Mailing lists asks a question about “comparing velocity between teams” or “benchmarking data on velocity.” Before we examine the problem, let’s recheck what velocity is—the amount of work completed by the team/time taken to complete it. The amount of work is usually measured in Story Points (a relative measure of size). So velocity is just the number of points the team completes in the average iteration/sprint.

The underlying point is that Agile/Scrum teams use relative estimation (i.e., is this story/feature bigger or smaller than our standard story?) vs. the traditional approach of absolute estimation. The problem with comparisons, benchmarking, or any other attempts to compare velocity is that my story points ≠ your story points, because different projects use different standard stories. They work in different problem domains, and they have different people.