Re: [scrumdevelopment] Year End Retrospectives question
- 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.
Certified Scrum Coach
Founder and Principal Consultant, Humanizing Work, LLC
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
> 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.
> Mark Levison
> Blog: http://www.notesfromatooluser.com/
> Recent Entries: Agile/Scrum Smells:
> Agile Games for Making Retrospectives Interesting: