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

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

Expand Messages
  • Ken Schwaber
    May 10 8:09 AM
    • 0 Attachment
      I haven't looked at the product, so this is a general comment. The sprint backlog is a compromise between management (who is anxious and wants to see something, particularly the first sprint) and the team (that needs to manage itself). The sprint backlog sits right between, with team members managing their own work and the spreadsheet reflecting the results and miraculously being demonstrable to management. However, the team manages its own work and any focus on individuals or estimate to actuals removes to focus of self-organizing teams. I continue to be nervous about tools because they implement one procedural vision of the way work should be done, hence limiting self-organization and agility. That said, tools can be helpful.
      Ken
      >
      > From: David A Barrett <dave.barrett@...>
      > Date: 2004/05/10 Mon AM 09:17:01 CDT
      > 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: scrumdevelopment-unsubscribe@...
      > Yahoo! Groups Links
      >
      >
      >
      >
      >
      >
    • Show all 29 messages in this topic