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

RE: [scrumdevelopment] Slacking teams (was:Nitty-gritty detail of updating Scrum artifacts)

Expand Messages
  • Wolfgang Schulze Zachau
    ... Yes, there is a problem. I have known that from the start. On the other hand I have a total of 4 people reporting to me and chances of getting more or,
    Message 1 of 59 , Jul 4, 2006
    • 0 Attachment
      > 1. If Jimmy's team is 1.5 people there is a problem, unless
      > he or his associate is a tragic but valiant victim of a
      > railroad accident.
      > Part-time contributors to sprints cause problems.

      Yes, there is a problem. I have known that from the start. On the other hand
      I have a total of 4 people reporting to me and chances of getting more or,
      alternatively, access to other staff, are extremely slim. I need the half
      resource to cope with the amount of work. Does anyone have good advice on
      how to make things work in such a situation ?

      > 2. Even if the team were 2.0 people, that's pretty thin in my
      > opinion. Not much room for self-organization. I might
      > therefore merge Jimmy's team and their backlog items into
      > some other team.

      I have looked into that. Jimmy's work is substantially different from the
      rest of the team and the skill sets only have minimal overlap (Linux/MySQL
      server admin and script writing vs. .Net development). Does it make sense to
      merge small teams into one big one, even if the tasks and skill sets are
      completely different?

      > 4. I'd have to ask whether the Sprint Goal is actually being
      > committed to by Jimmy and the Halfling, or whether the goal
      > is being pushed or imposed upon them. If the latter, then
      > they can't possibly build up a useful sense of responsibility
      > or the ability to estimate.

      From my perspective the sprint goal is committed to and not imposed. AFAICS
      the problem lies with the sense of ownership. The estimates are good, we
      know that because we have monitored average effort required to
      resolve/complete backlog items vs. estimates and there is a good match.
      What is underedeveloped is the ownership of the sprint. I have recently
      introduced (for both teams) the obligation to track all unscheduled work
      during a sprint, but unless I (as Scrum Master) brew up a storm during daily
      scrums, the tracking is neglected due to "we don't have time for this".
      I suspect you are going to say something like "You need to bring the hammer
      down". I would prefer to solve this through positive motivation rather than
      force. Ideas, anybody ?

      Regards,

      Wolfgang



      > -----Original Message-----
      > From: scrumdevelopment@yahoogroups.com
      > [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Ron Jeffries
      > Sent: 29 June 2006 13:59
      > To: scrumdevelopment@yahoogroups.com
      > Subject: Re: [scrumdevelopment] Slacking teams
      > (was:Nitty-gritty detail of updating Scrum artifacts)
      >
      > On Thursday, June 29, 2006, at 1:08:48 AM, Wolfgang Schulze
      > Zachau wrote:
      >
      > > [Some good stuff about Jimmy]
      >
      > > So in essence I have two problems here:
      >
      > > A) I need to find a way to motivate Jimmy (but that is a line
      > > management problem and therefore off-topic)
      > > B) I need a way to demonstrate to my boss that once a reasonable,
      > > sustainable pace has been achieved, pushing for more will only do
      > > damage
      >
      > > Does that make sense to you?
      >
      > Sure. And as you tell the story, I'm prepared to think that
      > Jimmy is at the center of a problem that needs to be
      > resolved. Some thoughts:
      >
      > 1. If Jimmy's team is 1.5 people there is a problem, unless
      > he or his associate is a tragic but valiant victim of a
      > railroad accident.
      > Part-time contributors to sprints cause problems.
      >
      > 2. Even if the team were 2.0 people, that's pretty thin in my
      > opinion. Not much room for self-organization. I might
      > therefore merge Jimmy's team and their backlog items into
      > some other team.
      >
      > 3. If Sprint goals are consistently not met, Jimmy and his
      > truncated associate need to be informed, in no uncertain
      > terms, that this is not successful. I don't care whether they
      > do it by working harder or by putting feature cards under
      > their pillows for the feature fairy, but their sole job is to
      > estimate what they can do and then do it.
      > I'd keep in mind that they may need help and that the partial
      > person is probably a piece of the problem, but still, you
      > have a right to be able to count on the team to do what they
      > say they will do.
      >
      > 4. I'd have to ask whether the Sprint Goal is actually being
      > committed to by Jimmy and the Halfling, or whether the goal
      > is being pushed or imposed upon them. If the latter, then
      > they can't possibly build up a useful sense of responsibility
      > or the ability to estimate.
      >
      > If Jimmy's team starts to keep what your boss perceives as
      > promises (and what really should be promises, or at least
      > commitments), then discussions of his productivity can be
      > limited. "Yes, Boss, he's a bit of a slug really, but he
      > keeps his promises to us, and that's what counts."
      >
      > Ron Jeffries
      > www.XProgramming.com
      > Agility might be said to be about encountering all the
      > problems so early and so often that the effort to fix them is
      > less than the pain of enduring them.
      >
      >
      >
      >
      >
    • Steven Gordon
      When I read about an organization with rampant context switching, siloing and resource fragmentation, I believe it is management s responsbility to figure out
      Message 59 of 59 , Jul 4, 2006
      • 0 Attachment
        When I read about an organization with rampant context switching,
        siloing and resource fragmentation, I believe it is management's
        responsbility to figure out how to address the organizational
        dysfunctions rather than blame the developers for not being able to
        commit to what they can get done in short time frames under such
        circumstances.

        To say that the problem appears to be that the developers are slacking
        off exhibits so much arrogance on the part of management, my gut
        reaction is to suggest that if management has no more problems to
        solve and yet the development throughput is unsatisfactory, then maybe
        the organization needs less managers and more developers.

        Steven Gordon

        On 7/4/06, Wolfgang Schulze Zachau <wolfgang@...> wrote:
        >
        >
        >
        >
        >
        >
        >
        > The unfortunate lad reports to a different team, and I am allowed to make
        > use of approx. half his time.
        >
        >
        >
        > I don't need to suspect. I *know* they all do things that are unrelated to
        > sprint. This is due to all of us having to do day-2-day IT support for
        > approx. 50-60 other staff (who range from almost complete computer
        > illiteracy to somewhat advanced homw users), plus everyone has their
        > personal career development objectives, which they need to spend 4 hours a
        > week on doing.
        > The support work is on average not enough to keep a full man busy, so we
        > have decided to rotate this around, then at least everybody gets 4 days of
        > relatively uninterrupted work per week.
        >
        >
        > Have you sat
        > > down with Jimmy and his partner and pointed out that they are
        > > failing to meet their commitments, and asked why?
        >
        > Yep, I have. And that's when the excuses come alive. Which is why I wanted
        > them all to report back how exactly they are using their time when not
        > working for the sprint.
        > There used to a habit here that other staff would just walk up to a member
        > of the IT team, state their demands/requirements/wishes and expect things
        > to
        > get done on the spot (supported to some degree by the MD himself). I have
        > pretty much stopped that and now at least these folks either go through me
        > or they log their work requests in the (ever popular) bug tracker, so that
        > we can prioritize them and then schedule them.
        > But then, we are an e-commerce company, our IT systems are the very blood
        > that keep this company alive. There are numerous justified occasions where
        > emergencies need to be responded to right away. I simply want them tracked.
        >
        >
        > Regards,
        >
        > Wolfgang
      Your message has been successfully submitted and would be delivered to recipients shortly.