Loading ...
Sorry, an error occurred while loading the content.

Re: Retrospective instructions? Yes - SIMPLE if done right.

Expand Messages
  • jay_conne
    ... ... Alan - I think it really is simple. The simplicity comes from a clear understanding of how much and how little you are trying to
    Message 1 of 34 , Sep 2, 2008
    • 0 Attachment
      --- In scrumdevelopment@yahoogroups.com, "Alan Dayley" <alandd@...> wrote:
      > One of my weaknesses is a tendency to seek complex solutions. Maybe
      > retrospective methods are so simple that I'm looking for more
      > complexity where there is none.

      Alan - I think it really is simple. The simplicity comes from a clear
      understanding of how much and how little you are trying to accomplish.
      I like to say that we don't call things we understand 'complex'
      unless we are trying to intimidate others with our pretension of
      knowledge. :-) [sorry if this undermines book sales]

      more in context below...

      --- In scrumdevelopment@yahoogroups.com, "David H." <dmalloc@...> wrote:
      > <snip>
      > Reading and learning about retrospectives has probably been the
      > most challenging part of my becoming a scrum master back in the
      > days and it is still challenging, because it involved soft skills
      > which cannot easily be taught.
      > <snip>

      Interestingly, I found doing effective retrospectives
      straight-forward. Perhaps I have some decades of soft skills that I
      take for granted. But I don't think that's what's going on. I use a
      simple process that I refined while co-teaching a CSM class with
      Miskin Berteig a number of years ago. Another piece of the context -
      I have successful, focused teams - not contentious ones. That comes
      from how I train and coach them. We are just dealing with reality,
      openly and honestly, continuing to learn and delivering value.

      The Process:

      1. Start with flip-chart pages with adhesive backs (PostIt brand)
      placed on the wall.

      2. Put the Project Name, Sprint # and dates on the top, draw a line
      down the center, put a plus sign at the top of the left column and a
      delta sign at the top of the right column. [These are artifacts to be
      kept throughout the project in a heap that can be reviewed by the team
      members when there's a need. Therefore I put the Sprint
      identification below the adhesive area.]

      3. To avoid possibly defensive interaction - I ask all team members to
      silently take small (3"x3") PostIts and write at least three positive
      point about he last Sprint and place them in the left column. I give
      them 10-15 minutes and if people are still writing, I'll give them
      more time.

      3. I then read them out loud and ask for clarification if there's
      ambiguity. We time-box some discussion - perhaps 15 minutes. The
      goal is to appreciate our successes.

      4. I then ask people to write at least three points that could use
      improvement (deltas) - done in the same fashion as the positives.

      5. I group them by theme and read them, asking for clarifications of
      ambiguity as with the positives. We have some time-boxed discussion
      and prioritize the themes by giving everyone five points to distribute
      among them. There's nothing sacred about 5, perhaps 1.5 times the
      number of options. The point is to get highest priority ones

      6. Starting with the highest scoring themes, we discuss action items
      we can take next Sprint to improve this issue. They get written on a
      separate piece of flip-chart paper. We choose actions that people
      feel comfortably are doable. We stop when the team agrees it's enough
      to include in the next Sprint. Examples are:
      a) update the task board at least 5 minutes before the stand-up;
      b) inform the team (or ScrumMaster) if you need to miss a stand-up
      for an emergency or a planned event.
      c) change a meeting time that is not working or conflicts with a
      changing situation.
      d) have the ScrumMaster get impediments escalated and resolved faster.
      e) engage in more team collaboration such as with testers or
      pair-programming to eliminate silos of code-base knowledge.

      These two artifacts (collection of pluses & deltas and retro. action
      items) are kept on the information radiator, typically on top of the
      previous Sprints versions. We can talk to them as part of the daily
      Scrum - like any other tasks being worked on.

      I find everyone gets engaged and takes it seriously as long as the
      team has the authority to make the changes they propose.

      BTW - I do the same for a project retrospective. I just use a full
      flip-chart page for each, plus and delta.

      more in context below...

      --- In scrumdevelopment@yahoogroups.com, Richie Moyle <rsmoyle@...> wrote:
      > Alan,
      > I tend to start with a simple flip chart with sheets (blue tacked)
      on the wall covering "plus delta analysis":
      > What went well?
      > What didn't go so well?
      > What are we going to change (prioritised)?
      > I start with either input from individuals (round table) for what
      went well, this gets the whole team involved and motivated.
      > Secondly you could use the anonymous index cards to kick off what
      didn't go well. I like this method as it gives the team a chance to
      feedback on each other and more importantly, the Scrum Master.
      > Finaly, pick the top 5-10 things that didn't go well and concentrate
      on identifying the changes you are going to make for them. If time
      allows, tackle the remainder.
      > In my experience, the simpler the Retro is, the more success I have
      had from teams.

      Absolutely - as long as it's focused and purposeful.

      > Tip : Try holding it over a lunchtime at a restaurant
      > (or dare I say, pub).

      I think this may distract from the focus - but I should try it sometime.

      > The most important thing is to make the results visable to the team
      during subsequent sprints. I tend to put the flip chart sheets up
      around their white boards, so they can't ignore the changes they
      agreed to make.

      Absolutely - radiate it and act on it.

      Alan - let me know how this works for you - using a kiss principle.

      Jay Conne
      Lean/Agile Coach, Trainer &
      www.jconne.com jay@...
    • James S. Fosdick, PMP, CSP
      ... It seems to me this has less to do with clever mnemonics or retrospective techniques (which are certainly useful tools) and more to do with the fact that
      Message 34 of 34 , Sep 4, 2008
      • 0 Attachment
        --- In scrumdevelopment@yahoogroups.com, Ron Jeffries
        <ronjeffries@...> wrote:

        > Yes. I have some dear friends who used SAMOLO and loved it. I was
        > not as impressed as they were. For reasons such as you're referring
        > to, and others, it seemed to me that important things just couldn't
        > be brought up.

        It seems to me this has less to do with clever mnemonics or
        retrospective techniques (which are certainly useful tools) and more
        to do with the fact that retrospection is not equivalent to
        introspection either individually or collectively. A tendency towards
        superficial examination of past history without a requisite amount of
        serious introspection cannot have a significant impact on future
        development. As with all things Scrum related, teams will get out of a
        retrospective whatever they put in. The trick for the ScrumMaster or
        coach is to inspire them to be more introspective individually and as
        a group. I don't think there is a mnemonic or prescriptive technique
        that provides that.
      Your message has been successfully submitted and would be delivered to recipients shortly.