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

Re: [scrumdevelopment] Paper on a basic structured retrospective released

Expand Messages
  • Michael D. James
    Strong agreement on getting the tables (and other armor like laptops and iPhones) out of the way. I recently found the timeline exercise useful beyond the
    Message 1 of 6 , Sep 21, 2010
      Strong agreement on getting the tables (and other armor like laptops and iPhones) out of the way. 

      I recently found the timeline exercise useful beyond the scope of a Sprint when there was still unfinished business, or history only part of the team was aware of. 

      BTW I am in Phoenix for the Scrum Beyond Software event if anyone else is also here early and wants to grab Mexican food. 


      On Sep 20, 2010, at 10:05 AM, Ilja Preuß <iljapreuss@...> wrote:


      Hi Henrik,

      nice work! You might also want to send the link to the retrospectives mailing list: http://finance.groups.yahoo.com/group/retrospectives/

      Some comments:

      - I find that for shorter sprints (two weeks and less), there isn't much value in doing a timeline. I often find that Mad, Sad, Glad or similar exercises work better in that context.

      - Your picture shows that you only categorize and vote on the "Can get better" post its. I find that there is a lot of value in actually mixing up all the post its on the board and include them all in the categories for voting. Often, we find interesting connections between things that could be improved, things that already work, and neutral events. Also, sometimes there can be a lot of energy in working on something that we learned is a good idea - for example be bringing it to other parts of the process. It doesn't always have to be problem solving - in fact, always concentrating on the problems can suck a lot of energy out of a team, in my experience.

      - I don't share your take on timeboxes in the retrospectives. I don't see it as the responsibility of the facilitator to enforce them. I see the facilitator as a servant to the team, and as such, he should make it visible to the team when the end of a timebox is reached, and perhaps make a suggestion. But in the end the team knows best what it needs, and when they decide to extend the timebox, the facilitator should be happy to accept that.

      - I find that there is an important step missing - the closing. I use it to
        * check whether there are any open threads being left that we need to decide how to handle,
        * get feedback on the retrospective, for example using the Plus/Delta exercise, and
        * congratulate/thank the participants for the good work

      - interesting that you let participants stand for up to two hours. Somehow I'm reluctant to try that with my teams. I always make sure participants are sitting in a (semi)circle, without any tables in between, though. Makes a big difference to the typical meeting room layout.

      Again, thanks for a useful resource!

      Cheers, Ilja

      2010/9/16 Henrik Berglund <henrik.cedur@...>


      Here is a link to a paper I wrote on how to run a basic structured retrospective:
      The intention is to provide a description that new teams can keep handy. It is free to download and somewhere between a blog-post and a book in size.
      All veterans on the this list will know most of this if not all already, but who knows, even perhaps you could pick up a thing or two also.  

      The paper is shared under a Creative Common License, Attribution 3.0 Unported,
      http://creativecommons.org/licenses/by/3.0/, so you can pretty much use and modify
      it as you like.

      Hope that some of you will find it useful!



    Your message has been successfully submitted and would be delivered to recipients shortly.