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

Re: [leandevelopment] Re: An online resource of Retrospectives

Expand Messages
  • George Dinwiddie
    ... Nice article. I disagree that retrospectives are an advanced technique, even though many people seem to struggle with them. It takes a certain amount of
    Message 1 of 20 , Jun 30 11:14 AM
      allan kelly wrote:
      >> Posted by: "Robin Dymond" robin.dymond@... rdymond1
      >
      >> I am not aware of any "problems with retrospectives."
      >
      > Problems I have seen:
      > - retrospectives don't happen
      > - they happen by people don't trust one each other (or the company) to
      > name the problems
      > - project managers cancel the sessions citing lack of time (really they
      > don't trust people to hear what they say)
      > - when they do people don't take action on the results
      >
      > And a few others, I wrote this a few months back:
      > http://www.agilejournal.com/content/view/774/111/

      Nice article. I disagree that retrospectives are an advanced technique,
      even though many people seem to struggle with them. It takes a certain
      amount of courage to engage in honest introspection.

      I'm of the opinion that retrospectives are NOT a process improvement
      mechanism. The process improvement happens outside the retrospective.
      A retrospective is an observation tool. Sure, you can observe at any
      time, but there's value in taking a longitudinal view over a period of
      time to see things that are missed in the day-to-day work. I advise
      doing so not only at each iteration, but also in a deeper and less
      frequent cycle. You'll see different things.

      To add to your list of observed problems:

      - Retrospectives that limit themselves to the three questions, "What
      worked? What didn't work so well? What are we going to change?"
      - Retrospectives that don't ensure that all the participants are
      represented. It takes care to get the thoughts and feelings of the
      introverts.
      - Retrospectives that don't establish safety, or at least acknowledge
      the level of safety felt by the participants.
      - Retrospectives that are designed to lead to a particular conclusion.
      It's not a retrospective if you've got "the answer" before you start.
      It's not a retrospective if the answers come from the leader instead
      of the participants.

      - George

      --
      ----------------------------------------------------------------------
      * George Dinwiddie * http://blog.gdinwiddie.com
      Software Development http://www.idiacomputing.com
      Consultant and Coach http://www.agilemaryland.org
      ----------------------------------------------------------------------
    • Bartels, Mel
      ... I m of the opinion that retrospectives are NOT a process improvement mechanism. The process improvement happens outside the retrospective.
      Message 2 of 20 , Jun 30 11:31 AM
        >>>
        I'm of the opinion that retrospectives are NOT a process improvement
        mechanism. The process improvement happens outside the retrospective.
        <<<
         
        I second this.  Respectives brainstorm to root causes and suggest prioritization.  The change in people's behavior occurs between retrospectives.
         
        People, teams, can change only so fast; one can consider only so many upsets going about the day's business.  If one solid behavioral change can occur after each retrospective, well, that's wonderful in my book.
         
        Mel Bartels
         
      • Matt
        Allan, ... ... solvers, ... I know a couple of sociologists and they tend to describe what they do as more finding the problem than solving the
        Message 3 of 20 , Jun 30 11:42 AM
          Allan,


          --- In leandevelopment@yahoogroups.com, allan kelly <allan@...> wrote:
          <snip/>

          > One team that was good at retros was struggling with
          > > some issues, and decided to bring a sociologist into their retro to
          > > help. The Sociologist thought the team had better problem solving
          > > skills than most sociologists.
          >
          > :)
          >
          > I'm not really surprised, as software developers we are problem
          solvers,
          > problem solving is what we do earn our living.
          >
          > allan
          >


          I know a couple of sociologists and they tend to describe what they do
          as more "finding the problem" than "solving the problem". Human
          interaction is a far more complex domain than the ones most software
          developers get into. Just figuring out what the problem is can be the
          hard part.



          Matt
        • Martin Jul
          Hi all In my experience I see retrospectives being one possible starting point for kaizen: namely they serve as a way to collect observations about pain
          Message 4 of 20 , Jun 30 3:16 PM
            Re: [leandevelopment] Re: An online resource of Retrospectives Hi all

            In my experience I see retrospectives being one possible starting point for kaizen: namely they serve as a way to collect observations about pain points. Many times, however, I see retrospectives being held, the observations being added to a journal, and the game stopping there without anything being done to address the problem – or nothing being done to address its root cause.

            That’s not how to do it.

            Currently, I tend to frame the kaizen process in terms of the PDCA cycle. The retrospective can be a way to collect observations about something that is broken. The next important step is to sort through these observations, do the root cause analysis to get to the real cause, then do the PDCA:

            PLAN an experimement that will prove/disprove an improvement hypothesis
            DO it for a while
            CHECK the result of the experiment (often this can be in a retrospective later on) and if the improvement is successful,
            ACT to roll out the improvement on a wider scale

            So, the retrospective is not kaizen, but may be a useful frame to get the kaizen process rolling.

            That said, however, we do a lot of kaizen with respect to software quality without doing retrospectives, by simply observing the pain points of the software architecture while addressing them while we do other work (ie. refactorings, build and test automation etc). In the small the formal PDCA approach with might be a bit overkill, but in many organisations good data is a prerequisite for making changes in the large.

            All the best,
            Martin



            On 30/06/08 20.31, "Bartels, Mel" <Mel.Bartels@...> wrote:


             

            >>>
            I'm of the opinion that retrospectives are NOT a process improvement
            mechanism. The process improvement happens outside the retrospective.
            <<<

            I second this.  Respectives brainstorm to root causes and suggest prioritization.  The change in people's behavior occurs between retrospectives.

            People, teams, can change only so fast; one can consider only so many upsets going about the day's business.  If one solid behavioral change can occur after each retrospective, well, that's wonderful in my book.

            Mel Bartels

             
                
          • Igor Maciel Macaubas
            Hi all, Jumping in the middle, here I am. Coincidence or not, just about a few hours ago I finished a SCRUM retrospective meeting with my team, and this thread
            Message 5 of 20 , Jun 30 7:53 PM

              Hi all,

               

              Jumping in the middle, here I am. Coincidence or not, just about a few hours ago I finished a SCRUM retrospective meeting with my team, and this thread came to my attention.

              I’m a Scrum Master (not really, I wish I had this cool job title, but my job title is actually “Project Manager”) on a mid-size softwarehouse in Brazil; we develop software for huge companies, mostly CRM (not that it matters – just wanted to give some background). I’ve started a world-changing crusade along with a coworker a few months ago, and we started to adopt Scrum in our projects. Things were going well, we had 3 projects fully on SCRUM (with teams varying from 4 – 5 people), a product backlog well described, prioritized and with proper business value and poker estimates. I’m acctually facing a few problems with some scrum cerimonies, and would like your help to get thru. And my big first problem is with the SCRUM Retrospective, subject of this thread. In our retrospective today, my coworker (he’s part of the team, and an agile enghusiast like me) and I came to a few conclusions:

              ·         The team isn’t contributing as much as it should – at least we think so. Let’s say that more than 50% of the good/bad/change post-it’s are being written by my coworker and I. We want to make the team part of it, but how can we do it? Any recommendations?

              ·         Our meeting is deadly boring. Really really boring. How can we do it more fun?

              ·         The result of the meeting – the proccess improvement thing – isn’t acctually going live. So we see the problem, we determine the solution but the team just don’t get it. What am I doing wrong?

               

              Our retrospective session is based on the three-questions: what worked, what didn’t work so well and what are we going to do to change. Is there any better way to do it?

              I’ve already read the article before mentioned, and learned a lot – I’m pretty sure that our next retrospective will be much better, but I still want to address the questions above.

               

              Best Regards,

              Igor Macaubas

              --

              listas@...

               

               

              From: leandevelopment@yahoogroups.com [mailto:leandevelopment@yahoogroups.com] On Behalf Of Martin Jul
              Sent: Monday, June 30, 2008 7:17 PM
              To: leandevelopment@yahoogroups.com
              Cc: Jan Elbæk; Martin Gildenpfennig
              Subject: Re: [leandevelopment] Re: An online resource of Retrospectives

               

              Hi all

              In my experience I see retrospectives being one possible starting point for kaizen: namely they serve as a way to collect observations about pain points. Many times, however, I see retrospectives being held, the observations being added to a journal, and the game stopping there without anything being done to address the problem – or nothing being done to address its root cause.

              That’s not how to do it.

              Currently, I tend to frame the kaizen process in terms of the PDCA cycle. The retrospective can be a way to collect observations about something that is broken. The next important step is to sort through these observations, do the root cause analysis to get to the real cause, then do the PDCA:

              PLAN an experimement that will prove/disprove an improvement hypothesis
              DO it for a while
              CHECK the result of the experiment (often this can be in a retrospective later on) and if the improvement is successful,
              ACT to roll out the improvement on a wider scale

              So, the retrospective is not kaizen, but may be a useful frame to get the kaizen process rolling.

              That said, however, we do a lot of kaizen with respect to software quality without doing retrospectives, by simply observing the pain points of the software architecture while addressing them while we do other work (ie. refactorings, build and test automation etc). In the small the formal PDCA approach with might be a bit overkill, but in many organisations good data is a prerequisite for making changes in the large.

              All the best,
              Martin



              On 30/06/08 20.31, "Bartels, Mel" <Mel.Bartels@...> wrote:


               

              >>>
              I'm of the opinion that retrospectives are NOT a process improvement
              mechanism. The process improvement happens outside the retrospective.
              <<<

              I second this.  Respectives brainstorm to root causes and suggest prioritization.  The change in people's behavior occurs between retrospectives.

              People, teams, can change only so fast; one can consider only so many upsets going about the day's business.  If one solid behavioral change can occur after each retrospective, well, that's wonderful in my book.

              Mel Bartels

               
                  

            • Bartels, Mel
              ... So we see the problem, we determine the solution but the team just don’t get it. (and) The team isn’t contributing as much as it should
              Message 6 of 20 , Jun 30 10:48 PM
                >>>

                So we see the problem, we determine the solution but the team just don’t get it.

                (and)

                The team isn’t contributing as much as it should

                <<<





                I suggest that the first leads to the second. You going to have to listen to your fellow professionals and understand the problems as they see them. Support them and facilitate them. If they are quiet, then give them room to begin to voice their concerns. You are relevant to them to the extent that you help them achieve more and solve their problems. If you get too far ahead of them and you keep pressing them, they will probably dutifully follow but build resentment towards you. Think of how you would want to be coached in a football clinic.



                Mel Bartels
              • Ilja Preuss
                Hi Igor, I m currently low on time, so just this one short advice for now: ask your question on the retrospectives yahoo group. Cheers, Ilja
                Message 7 of 20 , Jun 30 10:54 PM
                  Hi Igor,

                  I'm currently low on time, so just this one short advice for now: ask
                  your question on the retrospectives yahoo group.

                  Cheers, Ilja

                  Igor Maciel Macaubas wrote:
                  > Hi all,
                  >
                  >
                  >
                  > Jumping in the middle, here I am. Coincidence or not, just about a few
                  > hours ago I finished a SCRUM retrospective meeting with my team, and
                  > this thread came to my attention.
                  >
                  > I’m a Scrum Master (not really, I wish I had this cool job title, but my
                  > job title is actually “Project Manager”) on a mid-size softwarehouse in
                  > Brazil; we develop software for huge companies, mostly CRM (not that it
                  > matters – just wanted to give some background). I’ve started a
                  > world-changing crusade along with a coworker a few months ago, and we
                  > started to adopt Scrum in our projects. Things were going well, we had 3
                  > projects fully on SCRUM (with teams varying from 4 – 5 people), a
                  > product backlog well described, prioritized and with proper business
                  > value and poker estimates. I’m acctually facing a few problems with some
                  > scrum cerimonies, and would like your help to get thru. And my big first
                  > problem is with the SCRUM Retrospective, subject of this thread. In our
                  > retrospective today, my coworker (he’s part of the team, and an agile
                  > enghusiast like me) and I came to a few conclusions:
                  >
                  > · The team isn’t contributing as much as it should – at least we
                  > think so. Let’s say that more than 50% of the good/bad/change post-it’s
                  > are being written by my coworker and I. We want to make the team part of
                  > it, but how can we do it? Any recommendations?
                  >
                  > · Our meeting is deadly boring. Really really boring. How can we
                  > do it more fun?
                  >
                  > · The result of the meeting – the proccess improvement thing –
                  > isn’t acctually going live. So we see the problem, we determine the
                  > solution but the team just don’t get it. What am I doing wrong?
                  >
                  >
                  >
                  > Our retrospective session is based on the three-questions: what worked,
                  > what didn’t work so well and what are we going to do to change. Is there
                  > any better way to do it?
                  >
                  > I’ve already read the article before mentioned, and learned a lot – I’m
                  > pretty sure that our next retrospective will be much better, but I still
                  > want to address the questions above.
                  >
                  >
                  >
                  > Best Regards,
                  >
                  > Igor Macaubas
                  >
                  > --
                  >
                  > listas@... <mailto:listas@...>
                  >
                  >
                  >
                  >
                  >
                  > *From:* leandevelopment@yahoogroups.com
                  > [mailto:leandevelopment@yahoogroups.com] *On Behalf Of *Martin Jul
                  > *Sent:* Monday, June 30, 2008 7:17 PM
                  > *To:* leandevelopment@yahoogroups.com
                  > *Cc:* Jan Elbæk; Martin Gildenpfennig
                  > *Subject:* Re: [leandevelopment] Re: An online resource of Retrospectives
                  >
                  >
                  >
                  > Hi all
                  >
                  > In my experience I see retrospectives being one possible starting point
                  > for kaizen: namely they serve as a way to collect observations about
                  > pain points. Many times, however, I see retrospectives being held, the
                  > observations being added to a journal, and the game stopping there
                  > without anything being done to address the problem – or nothing being
                  > done to address its root cause.
                  >
                  > That’s not how to do it.
                  >
                  > Currently, I tend to frame the kaizen process in terms of the PDCA
                  > cycle. The retrospective can be a way to collect observations about
                  > something that is broken. The next important step is to sort through
                  > these observations, do the root cause analysis to get to the real cause,
                  > then do the PDCA:
                  >
                  > PLAN an experimement that will prove/disprove an improvement hypothesis
                  > DO it for a while
                  > CHECK the result of the experiment (often this can be in a retrospective
                  > later on) and if the improvement is successful,
                  > ACT to roll out the improvement on a wider scale
                  >
                  > So, the retrospective is not kaizen, but may be a useful frame to get
                  > the kaizen process rolling.
                  >
                  > That said, however, we do a lot of kaizen with respect to software
                  > quality without doing retrospectives, by simply observing the pain
                  > points of the software architecture while addressing them while we do
                  > other work (ie. refactorings, build and test automation etc). In the
                  > small the formal PDCA approach with might be a bit overkill, but in many
                  > organisations good data is a prerequisite for making changes in the large.
                  >
                  > All the best,
                  > Martin
                  >
                  >
                  >
                  > On 30/06/08 20.31, "Bartels, Mel" <Mel.Bartels@...> wrote:
                  >
                  >
                  >
                  >
                  > > >>
                  > I'm of the opinion that retrospectives are NOT a process improvement
                  > mechanism. The process improvement happens outside the retrospective.
                  > <<<
                  >
                  > I second this. Respectives brainstorm to root causes and suggest
                  > prioritization. The change in people's behavior occurs between
                  > retrospectives.
                  >
                  > People, teams, can change only so fast; one can consider only so
                  > many upsets going about the day's business. If one solid behavioral
                  > change can occur after each retrospective, well, that's wonderful in
                  > my book.
                  >
                  > Mel Bartels
                  >
                  >
                  >
                  >
                  >
                • Michael Maham
                  Also, I think there s lots of good activities in *Agile Retrospectives* (
                  Message 8 of 20 , Jul 1, 2008
                    Also, I think there's lots of good activities in Agile Retrospectives (http://www.amazon.com/Agile-Retrospectives-Making-Teams-Great/dp/0977616649/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1214934793&sr=8-1).

                    And not just for sprint level retrospectives- I leveraged the book heavily to plan a day long retrospective for a team on the last year of their work.  (I second George's recommendation from earlier to not just have iteration level retros).

                    And to the earlier comments about retros not being a "process improvement mechanism"...I guess I agree (I'm not sure what a process improvement mechanism is,and, therefore why it is important to say retros aren't one)- I would say they are part of the "process improvement cycle", though.


                    michael

                    On Tue, Jul 1, 2008 at 12:54 AM, Ilja Preuss <it@...> wrote:
                    Hi Igor,

                    I'm currently low on time, so just this one short advice for now: ask
                    your question on the retrospectives yahoo group.

                    Cheers, Ilja

                    Igor Maciel Macaubas wrote:
                    > Hi all,
                    >
                    >
                    >
                    > Jumping in the middle, here I am. Coincidence or not, just about a few
                    > hours ago I finished a SCRUM retrospective meeting with my team, and
                    > this thread came to my attention.
                    >
                    > I'm a Scrum Master (not really, I wish I had this cool job title, but my
                    > job title is actually "Project Manager") on a mid-size softwarehouse in
                    > Brazil; we develop software for huge companies, mostly CRM (not that it
                    > matters – just wanted to give some background). I've started a
                    > world-changing crusade along with a coworker a few months ago, and we
                    > started to adopt Scrum in our projects. Things were going well, we had 3
                    > projects fully on SCRUM (with teams varying from 4 – 5 people), a
                    > product backlog well described, prioritized and with proper business
                    > value and poker estimates. I'm acctually facing a few problems with some
                    > scrum cerimonies, and would like your help to get thru. And my big first
                    > problem is with the SCRUM Retrospective, subject of this thread. In our
                    > retrospective today, my coworker (he's part of the team, and an agile
                    > enghusiast like me) and I came to a few conclusions:
                    >
                    > ·         The team isn't contributing as much as it should – at least we
                    > think so. Let's say that more than 50% of the good/bad/change post-it's
                    > are being written by my coworker and I. We want to make the team part of
                    > it, but how can we do it? Any recommendations?
                    >
                    > ·         Our meeting is deadly boring. Really really boring. How can we
                    > do it more fun?
                    >
                    > ·         The result of the meeting – the proccess improvement thing –
                    > isn't acctually going live. So we see the problem, we determine the
                    > solution but the team just don't get it. What am I doing wrong?
                    >
                    >
                    >
                    > Our retrospective session is based on the three-questions: what worked,
                    > what didn't work so well and what are we going to do to change. Is there
                    > any better way to do it?
                    >
                    > I've already read the article before mentioned, and learned a lot – I'm
                    > pretty sure that our next retrospective will be much better, but I still
                    > want to address the questions above.
                    >
                    >
                    >
                    > Best Regards,
                    >
                    > Igor Macaubas
                    >
                    > --
                    >
                    > listas@... <mailto:listas@...>
                    >
                    >
                    >
                    >
                    >
                    > *From:* leandevelopment@yahoogroups.com
                    > [mailto:leandevelopment@yahoogroups.com] *On Behalf Of *Martin Jul
                    > *Sent:* Monday, June 30, 2008 7:17 PM
                    > *To:* leandevelopment@yahoogroups.com
                    > *Cc:* Jan Elbæk; Martin Gildenpfennig
                    > *Subject:* Re: [leandevelopment] Re: An online resource of Retrospectives
                    >
                    >
                    >
                    > Hi all
                    >
                    > In my experience I see retrospectives being one possible starting point
                    > for kaizen: namely they serve as a way to collect observations about
                    > pain points. Many times, however, I see retrospectives being held, the
                    > observations being added to a journal, and the game stopping there
                    > without anything being done to address the problem – or nothing being
                    > done to address its root cause.
                    >
                    > That's not how to do it.
                    >
                    > Currently, I tend to frame the kaizen process in terms of the PDCA
                    > cycle. The retrospective can be a way to collect observations about
                    > something that is broken. The next important step is to sort through
                    > these observations, do the root cause analysis to get to the real cause,
                    > then do the PDCA:
                    >
                    > PLAN an experimement that will prove/disprove an improvement hypothesis
                    > DO it for a while
                    > CHECK the result of the experiment (often this can be in a retrospective
                    > later on) and if the improvement is successful,
                    > ACT to roll out the improvement on a wider scale
                    >
                    > So, the retrospective is not kaizen, but may be a useful frame to get
                    > the kaizen process rolling.
                    >
                    > That said, however, we do a lot of kaizen with respect to software
                    > quality without doing retrospectives, by simply observing the pain
                    > points of the software architecture while addressing them while we do
                    > other work (ie. refactorings, build and test automation etc). In the
                    > small the formal PDCA approach with might be a bit overkill, but in many
                    > organisations good data is a prerequisite for making changes in the large.
                    >
                    > All the best,
                    > Martin
                    >
                    >
                    >
                    > On 30/06/08 20.31, "Bartels, Mel" <Mel.Bartels@...> wrote:
                    >
                    >
                    >
                    >
                    >     > >>
                    >     I'm of the opinion that retrospectives are NOT a process improvement
                    >     mechanism. The process improvement happens outside the retrospective.
                    >     <<<
                    >
                    >     I second this.  Respectives brainstorm to root causes and suggest
                    >     prioritization.  The change in people's behavior occurs between
                    >     retrospectives.
                    >
                    >     People, teams, can change only so fast; one can consider only so
                    >     many upsets going about the day's business.  If one solid behavioral
                    >     change can occur after each retrospective, well, that's wonderful in
                    >     my book.
                    >
                    >     Mel Bartels
                    >
                    >
                    >
                    >
                    >


                    ------------------------------------

                    Yahoo! Groups Links

                    <*> To visit your group on the web, go to:
                       http://groups.yahoo.com/group/leandevelopment/

                    <*> Your email settings:
                       Individual Email | Traditional

                    <*> To change settings online go to:
                       http://groups.yahoo.com/group/leandevelopment/join
                       (Yahoo! ID required)

                    <*> To change settings via email:
                       mailto:leandevelopment-digest@yahoogroups.com
                       mailto:leandevelopment-fullfeatured@yahoogroups.com

                    <*> To unsubscribe from this group, send an email to:
                       leandevelopment-unsubscribe@yahoogroups.com

                    <*> Your use of Yahoo! Groups is subject to:
                       http://docs.yahoo.com/info/terms/


                  • George Dinwiddie
                    ... Hi, Igor. I m afraid what you describe sounds less like a retrospective than a process improvement meeting led by a project manager. While that sounds
                    Message 9 of 20 , Jul 1, 2008
                      Igor Maciel Macaubas wrote:
                      > I’m a Scrum Master (not really, I wish I had this cool job title, but my
                      > job title is actually “Project Manager”) .... In our
                      > retrospective today, my coworker (he’s part of the team, and an agile
                      > enghusiast like me) and I came to a few conclusions:
                      >
                      > · The team isn’t contributing as much as it should – at least we
                      > think so. Let’s say that more than 50% of the good/bad/change post-it’s
                      > are being written by my coworker and I. We want to make the team part of
                      > it, but how can we do it? Any recommendations?

                      Hi, Igor. I'm afraid what you describe sounds less like a retrospective
                      than a process improvement meeting led by a project manager. While that
                      sounds like a worthwhile endeavor, I've never found them to uncover the
                      issues that are on the teams' minds. They tend to explore the issues
                      that are on the project managers' mind, instead.

                      I've collected some resources on
                      http://idiacomputing.com/moin/IntrospectionAndRetrospectives and
                      http://idiacomputing.com/moin/RestrospectiveTechniques for my own
                      benefit. Perhaps they will be of use to you, also. (Unfortunately,
                      some of the links are dead. In particular, Rachel Davies reorganized
                      her blog and I've been unable to locate the articles I'd selected.)

                      Unfortunately, as project manager, you may not be the best person to
                      lead the retrospective. In fact, depending on the level of safety felt
                      by the developers, it might be better if you're not in the room. That's
                      not an iron-clad rule, but it's often the case.

                      Retrospectives take facilitation more than leading. The less you try to
                      control them, the better they are.

                      - George

                      --
                      ----------------------------------------------------------------------
                      * George Dinwiddie * http://blog.gdinwiddie.com
                      Software Development http://www.idiacomputing.com
                      Consultant and Coach http://www.agilemaryland.org
                      ----------------------------------------------------------------------
                    • Igor Maciel Macaubas
                      Hi Michael, Thanks for your contribution, and I will have to agree with you. Knowing what’s wrong and what to do to fix it is the first phase of acctually
                      Message 10 of 20 , Jul 2, 2008

                        Hi Michael,

                         

                        Thanks for your contribution, and I will have to agree with you. Knowing  what’s wrong and what to do to fix it is the first phase of acctually solving it. That’s like new year’s eve resolutions: we know what we can improve, we know how to do it, and if we doesn’t succeed doing it it’s just because we didn’t pay the amount of effort needed to do it. And I think that the same applies do the team. Maybe B/C I have inherited the ‘project manager’ title, and we’ve always been a waterfall organization for ages, they’re just waiting for someone to tell them what to do, me, our SEPG or our higher ups.

                         

                        And I’ll definitely get the book and read. Thanks a lot!

                         

                        Cheers,

                        Igor

                        --

                        igor@...

                         

                         

                        From: leandevelopment@yahoogroups.com [mailto:leandevelopment@yahoogroups.com] On Behalf Of Michael Maham
                        Sent: Tuesday, July 01, 2008 2:59 PM
                        To: leandevelopment@yahoogroups.com
                        Subject: Re: [leandevelopment] Re: An online resource of Retrospectives

                         

                        Also, I think there's lots of good activities in Agile Retrospectives (http://www.amazon.com/Agile-Retrospectives-Making-Teams-Great/dp/0977616649/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1214934793&sr=8-1).

                        And not just for sprint level retrospectives- I leveraged the book heavily to plan a day long retrospective for a team on the last year of their work.  (I second George's recommendation from earlier to not just have iteration level retros).

                        And to the earlier comments about retros not being a "process improvement mechanism"...I guess I agree (I'm not sure what a process improvement mechanism is,and, therefore why it is important to say retros aren't one)- I would say they are part of the "process improvement cycle", though.


                        michael

                        On Tue, Jul 1, 2008 at 12:54 AM, Ilja Preuss <it@...> wrote:

                        Hi Igor,

                        I'm currently low on time, so just this one short advice for now: ask
                        your question on the retrospectives yahoo group.

                        Cheers, Ilja


                        Igor Maciel Macaubas wrote:

                        > Hi all,
                        >
                        >
                        >
                        > Jumping in the middle, here I am. Coincidence or not, just about a few
                        > hours ago I finished a SCRUM retrospective meeting with my team, and
                        > this thread came to my attention.
                        >
                        > I'm a Scrum Master (not really, I wish I had this cool job title, but my
                        > job title is actually "Project Manager") on a mid-size
                        softwarehouse in
                        > Brazil; we develop software for huge companies, mostly CRM (not that it
                        > matters – just wanted to give some background). I've started a
                        > world-changing crusade along with a coworker a few months ago, and we
                        > started to adopt Scrum in our projects. Things were going well, we had 3
                        > projects fully on SCRUM (with teams varying from 4 – 5 people), a
                        > product backlog well described, prioritized and with proper business
                        > value and poker estimates. I'm acctually facing a few problems with some
                        > scrum cerimonies, and would like your help to get thru. And my big first
                        > problem is with the SCRUM Retrospective, subject of this thread. In our
                        > retrospective today, my coworker (he's part of the team, and an agile
                        > enghusiast like me) and I came to a few conclusions:
                        >
                        > ·         The team isn't contributing as much as it
                        should – at least we
                        > think so. Let's say that more than 50% of the good/bad/change post-it's
                        > are being written by my coworker and I. We want to make the team part of
                        > it, but how can we do it? Any recommendations?
                        >
                        > ·         Our meeting is deadly boring. Really really
                        boring. How can we
                        > do it more fun?
                        >
                        > ·         The result of the meeting – the
                        proccess improvement thing –
                        > isn't acctually going live. So we see the problem, we determine the
                        > solution but the team just don't get it. What am I doing wrong?
                        >
                        >
                        >
                        > Our retrospective session is based on the three-questions: what worked,
                        > what didn't work so well and what are we going to do to change. Is there
                        > any better way to do it?
                        >
                        > I've already read the article before mentioned, and learned a lot –
                        I'm
                        > pretty sure that our next retrospective will be much better, but I still
                        > want to address the questions above.
                        >
                        >
                        >
                        > Best Regards,
                        >
                        > Igor Macaubas
                        >
                        > --
                        >

                        > listas@...

                        <mailto:listas@...>

                        >
                        >
                        >
                        >
                        >
                        > *From:* leandevelopment@yahoogroups.com
                        > [mailto:leandevelopment@yahoogroups.com]

                        *On Behalf Of *Martin Jul
                        > *Sent:* Monday, June 30, 2008 7:17 PM
                        > *To:* leandevelopment@yahoogroups.com
                        > *Cc:* Jan Elbæk; Martin Gildenpfennig
                        > *Subject:* Re: [leandevelopment] Re: An online resource of Retrospectives
                        >
                        >
                        >
                        > Hi all
                        >
                        > In my experience I see retrospectives being one possible starting point
                        > for kaizen: namely they serve as a way to collect observations about
                        > pain points. Many times, however, I see retrospectives being held, the
                        > observations being added to a journal, and the game stopping there
                        > without anything being done to address the problem – or nothing
                        being
                        > done to address its root cause.
                        >
                        > That's not how to do it.
                        >
                        > Currently, I tend to frame the kaizen process in terms of the PDCA
                        > cycle. The retrospective can be a way to collect observations about
                        > something that is broken. The next important step is to sort through
                        > these observations, do the root cause analysis to get to the real cause,
                        > then do the PDCA:
                        >
                        > PLAN an experimement that will prove/disprove an improvement hypothesis
                        > DO it for a while
                        > CHECK the result of the experiment (often this can be in a retrospective
                        > later on) and if the improvement is successful,
                        > ACT to roll out the improvement on a wider scale
                        >
                        > So, the retrospective is not kaizen, but may be a useful frame to get
                        > the kaizen process rolling.
                        >
                        > That said, however, we do a lot of kaizen with respect to software
                        > quality without doing retrospectives, by simply observing the pain
                        > points of the software architecture while addressing them while we do
                        > other work (ie. refactorings, build and test automation etc). In the
                        > small the formal PDCA approach with might be a bit overkill, but in many
                        > organisations good data is a prerequisite for making changes in the large.
                        >
                        > All the best,
                        > Martin
                        >
                        >
                        >
                        > On 30/06/08 20.31, "Bartels, Mel" <
                        href="mailto:Mel.Bartels@...">Mel.Bartels@...> wrote:
                        >
                        >
                        >
                        >
                        >     > >>
                        >     I'm of the opinion that retrospectives are NOT a process
                        improvement
                        >     mechanism. The process improvement happens outside the
                        retrospective.
                        >     <<<
                        >
                        >     I second this.  Respectives brainstorm to root causes
                        and suggest
                        >     prioritization.  The change in people's behavior occurs
                        between
                        >     retrospectives.
                        >
                        >     People, teams, can change only so fast; one can consider
                        only so
                        >     many upsets going about the day's business.  If one
                        solid behavioral
                        >     change can occur after each retrospective, well, that's
                        wonderful in
                        >     my book.
                        >
                        >     Mel Bartels
                        >
                        >
                        >
                        >
                        >

                        ------------------------------------

                        Yahoo! Groups Links

                        <*> To visit your group on the web, go to:
                           http://groups.yahoo.com/group/leandevelopment/

                        <*> Your email settings:
                           Individual Email | Traditional

                        <*> To change settings online go to:
                           http://groups.yahoo.com/group/leandevelopment/join
                           (Yahoo! ID required)

                        <*> To change settings via email:
                           mailto:leandevelopment-digest@yahoogroups.com
                           mailto:leandevelopment-fullfeatured@yahoogroups.com

                        <*> To unsubscribe from this group, send an email to:
                           leandevelopment-unsubscribe@yahoogroups.com

                        <*> Your use of Yahoo! Groups is subject to:
                           http://docs.yahoo.com/info/terms/

                         

                      • Igor Maciel Macaubas
                        Hi George, First of all, thanks for you answer. I ll just add a couple of comments allright? ... Humm that might be passing in the mind of the team. Just to
                        Message 11 of 20 , Jul 2, 2008
                          Hi George,

                          First of all, thanks for you answer. I'll just add a couple of comments
                          allright?

                          -----Original Message-----
                          > Hi, Igor. I'm afraid what you describe sounds less like a retrospective
                          > than a process improvement meeting led by a project manager. While that
                          > sounds like a worthwhile endeavor, I've never found them to uncover the
                          > issues that are on the teams' minds. They tend to explore the issues
                          > that are on the project managers' mind, instead.

                          Humm that might be passing in the mind of the team. Just to make myself
                          clear, I'm not acting as a project manager throught the sprints. I'm playing
                          the scrummaster role, and that's all. I'm not telling nobody what to do, and
                          the job title I acctually inherited from the time I was acctually a project
                          manager and told people what to do, before our company decided to move to
                          agile. The other coworker which is an agile enthusiast like me is part of
                          the team, and codes along with the guys. I think is more like the Beginners
                          Mind maybe?

                          > I've collected some resources on
                          > http://idiacomputing.com/moin/IntrospectionAndRetrospectives and
                          > http://idiacomputing.com/moin/RestrospectiveTechniques for my own
                          > benefit. Perhaps they will be of use to you, also. (Unfortunately,
                          > some of the links are dead. In particular, Rachel Davies reorganized
                          > her blog and I've been unable to locate the articles I'd selected.)

                          Thanks, this will help a lot! Already eating it :-)

                          > Unfortunately, as project manager, you may not be the best person to
                          > lead the retrospective. In fact, depending on the level of safety felt
                          > by the developers, it might be better if you're not in the room. That's
                          > not an iron-clad rule, but it's often the case.
                          > Retrospectives take facilitation more than leading. The less you try to
                          >control them, the better they are.

                          Totally agree. I'll just let them decide in our next retrospective who will
                          gonna lead it (my name won't be an option, though). And I agree, the more
                          control, the less brains. I'm doing my best to appear in front of the team
                          more like a facilitator and coach than as a boss.

                          - George

                          --
                          ----------------------------------------------------------------------
                          * George Dinwiddie * http://blog.gdinwiddie.com
                          Software Development http://www.idiacomputing.com
                          Consultant and Coach http://www.agilemaryland.org
                          ---------------------------------------------------------------------
                        • Ilja Preuss
                          ... I thought so for a long time, too. Consequently, when I didn t succeed, I told myself that I just had to try harder next time. Surprisingly, that seldom
                          Message 12 of 20 , Jul 3, 2008
                            Igor Maciel Macaubas wrote:

                            > Thanks for your contribution, and I will have to agree with you. Knowing
                            > what’s wrong and what to do to fix it is the first phase of acctually
                            > solving it. That’s like new year’s eve resolutions: we know what we can
                            > improve, we know how to do it, and if we doesn’t succeed doing it it’s
                            > just because we didn’t pay the amount of effort needed to do it.

                            I thought so for a long time, too. Consequently, when I didn't succeed,
                            I told myself that I just had to try harder next time. Surprisingly,
                            that seldom worked.

                            It took me an embarrassingly long time to understand that the reason for
                            me failing those things was not "just" because I didn't put enough
                            effort into it. It's almost always one of two other reasons: there were
                            other things that in some way were more important to me, or there was an
                            impediment that held me from doing what I had set out to do. It takes
                            some amount of effort to reflect on these things, but once I have a grip
                            on the true reason, it often becomes quite easy to either accept that
                            it's not what I'm going to do, or to find a way to remove the
                            impediment. (The impediment often is emotional in nature - I'm afraid of
                            some possible consequence of the action, often subconsciously.)

                            Cheers, Ilja
                          • George Dinwiddie
                            ... I m just cautioning that past history and previous roles you ve played can possibly interfere with facilitating the retrospective. Unfortunately, the
                            Message 13 of 20 , Jul 4, 2008
                              Igor Maciel Macaubas wrote:
                              > -----Original Message-----
                              >> Hi, Igor. I'm afraid what you describe sounds less like a retrospective
                              >> than a process improvement meeting led by a project manager. While that
                              >> sounds like a worthwhile endeavor, I've never found them to uncover the
                              >> issues that are on the teams' minds. They tend to explore the issues
                              >> that are on the project managers' mind, instead.
                              >
                              > Humm that might be passing in the mind of the team. Just to make myself
                              > clear, I'm not acting as a project manager throught the sprints. I'm playing
                              > the scrummaster role, and that's all. I'm not telling nobody what to do, and
                              > the job title I acctually inherited from the time I was acctually a project
                              > manager and told people what to do, before our company decided to move to
                              > agile. The other coworker which is an agile enthusiast like me is part of
                              > the team, and codes along with the guys. I think is more like the Beginners
                              > Mind maybe?

                              I'm just cautioning that past history and previous roles you've played
                              can possibly interfere with facilitating the retrospective.
                              Unfortunately, the nature of such interference is such that it might
                              make itself invisible. It's a hard situation you're in. So hard that
                              bringing in an outside facilitator (perhaps from your Human Resources
                              group) could be a good strategy.



                              >> Retrospectives take facilitation more than leading. The less you try to
                              >> control them, the better they are.
                              >
                              > Totally agree. I'll just let them decide in our next retrospective who will
                              > gonna lead it (my name won't be an option, though). And I agree, the more
                              > control, the less brains. I'm doing my best to appear in front of the team
                              > more like a facilitator and coach than as a boss.

                              Having a rotating lead for the retrospectives is one strategy.
                              Sometimes it's the best available. My personal view is that an
                              experienced facilitator can do better, but that's not always an easy option.

                              Good luck with it. It's apparent that you're working hard and
                              thoughtfully on the issue. I think that you'll do OK.

                              - George

                              --
                              ----------------------------------------------------------------------
                              * George Dinwiddie * http://blog.gdinwiddie.com
                              Software Development http://www.idiacomputing.com
                              Consultant and Coach http://www.agilemaryland.org
                              ----------------------------------------------------------------------
                            • ericculus
                              Hi Robin, I think you have an issue with your DB Server. Maybe I can help? Eric
                              Message 14 of 20 , Apr 18, 2011
                                Hi Robin,

                                I think you have an issue with your DB Server. Maybe I can help?

                                Eric


                                --- In leandevelopment@yahoogroups.com, "Robin Dymond" <robin.dymond@...> wrote:
                                >
                                > Scrum masters really earn their living by help their teams get better. At
                                > the heart of this is the feedback and process improvement opportunity, the
                                > retrospective.
                                >
                                > Now if you are a scrum master and you are running your nth retro by saying:
                                > OK, what went well, what could be improved, etc. and the team rolls their
                                > eyes, then take a hint, and change it up.
                                >
                                > If you have some great retrospectives you have created and have a passion
                                > for this topic, why not help your fellow Scrum Masters learn from you?
                                >
                                > We have set up a new site for sharing retrospectives, the Retrospectives
                                > Wiki!
                                >
                                > http://retrospectiveswiki.org/index.php?title=Main_Page
                                >
                                > It is extremely simple to add a retrospective to the site, there are only a
                                > few steps to get you on your way. Please create an account so we can
                                > attribute the posting to you!
                                >
                                > If you are looking for some good ideas there are around 10 items already on
                                > the site, but this will be driven by the SM/Agile coach community coming
                                > together and adding their great ideas.
                                >
                                > Please check it out, and add your retrospectives today!
                                >
                                > cheers,
                                > Robin Dymond
                                >
                              Your message has been successfully submitted and would be delivered to recipients shortly.