3448RE: [scrumdevelopment] Re: question regarding muliple projects against a small team
- May 10, 2004Hi Dave--
I'm the "wrong Mike" but I have similar concerns as you with tracking
individual burndown. Deb's spreadsheet did have a disclaimer on it about
individual numbers not being comparable. But, the need for disclaimer is
evidence that there's risk in tracking things this way.
I used to use an Excel sheet to track burndown and I had little summary
columns where I could see how much each person still had left to do that
they'd planned to do. This would look something like:
Hours HoursLeftInSprint %
Tod 40 60 67%
Mark 60 50 120%
The idea was that each team member could look at the number of hours he or
she had left in the sprint (these could vary based on vacation, etc.), how
many hours they had signed up for that were still to do and get a feel for
whether they'd finish. Clearly in the above Mark is overcommitted. Tod is
probably about right on.
What I found with this is that it really didn't help individuals know if
they were overcommitted--they had a feel for that faster than Excel could do
the math. And, individuals signing up for tasks was a bad idea in general.
What I've been doing the last couple of years is the team commits
collectively to an amount of work. No one signs up for anything. As
individuals need tasks, they take them off the board. There's no signing up
in advance. We don't have a rule about "no more than 2 tasks at a time" but
I try to discourage anyone taking more than that at once. Sometimes it
happens but always with good reasons. (Example: One of my programmers is
adding optimistic locking to a series of screens. Each screen takes 1-2
hours. He signed up last week for 4-5 of them at once since it was still
less than a day of work.)
Author of User Stories Applied for Agile Software Development
From: David A Barrett [mailto:dave.barrett@...]
Sent: Monday, May 10, 2004 8:17 AM
Subject: [scrumdevelopment] Re: question regarding muliple projects against
a small team
Ok, so now I'm a little worried.
The more I think about it, the less comfortable I am with Deb's spreadsheet
and the way it focuses on the individuals' performance. This clashes
totally with what I perceived to be key component of the Scrum methodology;
the team aspect.
In the ScrumMaster course, Ken made a point about ensuring that the daily
scrums were about the team members reporting to each other. He advised
doing things like avoiding eye contact with the team members in order to
avoid having them report *to* the scrummaster. I can think of numerous
other examples where he went out of his way to stress that the
scrummaster's role was *not* to organize and control the team's activities.
The chicken and pig concept, which seems to be a pillar of the methodology,
puts the emphasis on the team and shared goals.
So why am I worried? Well Deb puts up the spreadsheet which appears to
shift the focus from teamwork back onto individually managed people with
individual goals which are (probably) assigned by management, and the next
thing we see on this list are a whole bunch of posts from people saying
they think this is really cool. So then I wonder if people are looking at
this and saying to themselves, "Hey, this is the missing link! I can
implement Scrum while still keeping my subordinates directly accountable to
myself, and I can maintain control on an individual basis".
Now the last thing I want to be is dogmatic, but I'm thinking that if you
are managing your team with this spreadsheet (and the management style that
it implies) then it's not Scrum anymore. It may be effective, it may
support iterative and incemental, but it's not Scrum. If it's not Scrum,
what does that mean?
Perhaps if Mike or Ken could step in at this time and express an opinion it
would help to clarify this for me.
Lawyers' Professional Indemnity Company
To Post a message, send it to: scrumdevelopment@...
To Unsubscribe, send a blank message to:
Yahoo! Groups Links
- << Previous post in topic Next post in topic >>