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

Year End Retrospectives question

Expand Messages
  • Mark Levison
    With apologies to anyone who has already seen this I asked on the retrospectives mailing list and got no response. Since time is a ticking I thought I would
    Message 1 of 2 , Jan 13, 2009
      With apologies to anyone who has already seen this I asked on the retrospectives mailing list and got no response. Since time is a ticking I thought I would ask again in larger forum.

      I've been asked to organize a year end retrospective for a team of 6 + 2 (team members + part timers UI etc). As I do my planning I've been rereading sections of both "Agile Retrospectives" and "Collaboration Explained" – both suggest using a Timeline to gather data which seems like a great idea. The problem is that a number of team members have very specific issues (not doing enough Unit Testing/TDD, Not doing any automated acceptance testing, ...) that want to see raised and I'm not sure how that fits with the use of a timeline for data gathering. How do we raise issues like this with a timeline?

      Also as I read through Rough Agenda (p141 Agile Retrospectives), I'm struck by the fact that the "Locate Strengths" exercise is in the Gather Insights phase and not Gather the Data. Am I missing something here?

      Here's a list the team's Manager (interestingly he's not currently the SM) just feed me the list of issues he wants to see addressed:

      SCRUM / AGILE:
      - AUTOMATED TESTS!!!
      -  LESS BACKLOGS (eg  bugs)
       - another look at TDD? (FPM TDD kick-off)
      - consistent scrum practices
      -estimate backlog + release burndown chart (move to RTC?)
      -more real user stories (user X want to do Y because Z) with acceptance criteria (and use cases)
      - understand LEAN software dev theory better
      - how do we use automatic code test coverage reporting?
      - bugs assignment: who should do most of it? me or the team? review and pick new bugs in the meetings?
      - cutting down on emails : more IM and RSS feeds
      - log tests (manual or automated)  in the sprint backlog (or tasks)
      - assign one scrummaster only? should it be me?
      ....

      As you can see very little of this would come up using a timeline. My concern is that these feel like iteration retrospective issues and if I drop the timeline activity then we will miss the opportunity to find the meta issues that don't come up in regular retrospective events.

      Thoughts?

      Mark Levison
      Blog: http://www.notesfromatooluser.com/
      Recent Entries: Agile/Scrum Smells:  http://www.notesfromatooluser.com/2008/06/agilescrum-smells.html
      Agile Games for Making Retrospectives Interesting: http://www.notesfromatooluser.com/2008/10/agile-games-for-making-retrospectives-interesting.html

    • Richard Lawrence
      Most of the items on that list are solutions to particular problems. For example, automating tests solves problems like: - Regression testing takes too long -
      Message 2 of 2 , Jan 13, 2009
        Most of the items on that list are solutions to particular problems.
        For example, automating tests solves problems like:
        - Regression testing takes too long
        - Tests aren't done the same way every time
        - Too many defects slipping past the manual testing process
        - Too much cycling between dev and test

        On a timeline, this might be revealed by showing when testing started
        and ended in each sprint if the team tends to do mini waterfalls; you
        might see that testing tends to get pushed out the back of each sprint
        or gets shorter or longer. Or you might graph the defect count over
        time on the timeline and see that it increases. (Based on the list
        below, I would definitely graph defect count for this team's timeline.
        It connects to several of the concerns.)

        Here's another example: If someone believes that automated code
        coverage would solve the team's problems, they can collect data for
        the timeline about that. They can check out the code as it was at the
        end of each sprint and check the coverage. That goes on the timeline.

        You can hang lists on the timeline for each sprint of the stories
        planned and actually delivered. You can add the sprint burndowns if
        you still have them.

        Don't be in such a hurry to get to solutions before collecting the
        data. Since you can't adopt all these new practices at once, you need
        a way to determine which will have the most impact. Having a shared
        pool of data makes that conversation more productive.

        Richard
        --
        Richard Lawrence
        Certified Scrum Coach
        Founder and Principal Consultant, Humanizing Work, LLC
        303-895-7688
        richard@...
        www.humanizingwork.com
        www.richardlawrence.info

        On Tue, Jan 13, 2009 at 8:13 AM, Mark Levison <mark@...> wrote:
        > With apologies to anyone who has already seen this I asked on the
        > retrospectives mailing list and got no response. Since time is a ticking I
        > thought I would ask again in larger forum.
        >
        > I've been asked to organize a year end retrospective for a team of 6 + 2
        > (team members + part timers UI etc). As I do my planning I've been rereading
        > sections of both "Agile Retrospectives" and "Collaboration Explained" – both
        > suggest using a Timeline to gather data which seems like a great idea. The
        > problem is that a number of team members have very specific issues (not
        > doing enough Unit Testing/TDD, Not doing any automated acceptance testing,
        > ...) that want to see raised and I'm not sure how that fits with the use of
        > a timeline for data gathering. How do we raise issues like this with a
        > timeline?
        >
        > Also as I read through Rough Agenda (p141 Agile Retrospectives), I'm struck
        > by the fact that the "Locate Strengths" exercise is in the Gather Insights
        > phase and not Gather the Data. Am I missing something here?
        >
        > Here's a list the team's Manager (interestingly he's not currently the SM)
        > just feed me the list of issues he wants to see addressed:
        >
        > SCRUM / AGILE:
        > - AUTOMATED TESTS!!!
        > - LESS BACKLOGS (eg bugs)
        > - another look at TDD? (FPM TDD kick-off)
        > - consistent scrum practices
        > -estimate backlog + release burndown chart (move to RTC?)
        > -more real user stories (user X want to do Y because Z) with acceptance
        > criteria (and use cases)
        > - understand LEAN software dev theory better
        > - how do we use automatic code test coverage reporting?
        > - bugs assignment: who should do most of it? me or the team? review and pick
        > new bugs in the meetings?
        > - cutting down on emails : more IM and RSS feeds
        > - log tests (manual or automated) in the sprint backlog (or tasks)
        > - assign one scrummaster only? should it be me?
        > ....
        >
        > As you can see very little of this would come up using a timeline. My
        > concern is that these feel like iteration retrospective issues and if I drop
        > the timeline activity then we will miss the opportunity to find the meta
        > issues that don't come up in regular retrospective events.
        >
        > Thoughts?
        >
        > Mark Levison
        > Blog: http://www.notesfromatooluser.com/
        > Recent Entries: Agile/Scrum Smells:
        > http://www.notesfromatooluser.com/2008/06/agilescrum-smells.html
        > Agile Games for Making Retrospectives Interesting:
        > http://www.notesfromatooluser.com/2008/10/agile-games-for-making-retrospectives-interesting.html
        >
        >
      Your message has been successfully submitted and would be delivered to recipients shortly.