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

3448RE: [scrumdevelopment] Re: question regarding muliple projects against a small team

Expand Messages
  • Mike Cohn
    May 10, 2004
    • 0 Attachment
      Hi 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.)

      --Mike Cohn
      Author of User Stories Applied for Agile Software Development

      -----Original Message-----
      From: David A Barrett [mailto:dave.barrett@...]
      Sent: Monday, May 10, 2004 8:17 AM
      To: scrumdevelopment@yahoogroups.com
      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.

      Dave Barrett,
      Lawyers' Professional Indemnity Company

      To Post a message, send it to: scrumdevelopment@...
      To Unsubscribe, send a blank message to:
      Yahoo! Groups Links
    • Show all 29 messages in this topic