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

Re: [scrumdevelopment] Year End Retrospectives question

Expand Messages
  • 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 1 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.