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

Re: [scrumdevelopment] Impediment Reporting

Expand Messages
  • Ron Jeffries
    I d have to be there to really know what you re doing, Marc, or what Pete is doing when he speaks similarly. So please don t take the following as being about
    Message 1 of 66 , Oct 2, 2004
    • 0 Attachment
      I'd have to be there to really know what you're doing, Marc, or what Pete
      is doing when he speaks similarly. So please don't take the following as
      being about you. It's about the picture I get when I read what you write.

      On Friday, October 1, 2004, at 11:36:32 PM, Marc Hamann wrote:

      > I suppose it all depends what you mean by absolute. The team must take
      > ultimate responsibility for the success of the sprint. However, it is
      > perfectly reasonable for the team to negotiate down from their estimates if
      > they prove to be unrealistic. I think that is built in to any agile
      > process, and is explicit in the Sprint Burndown.

      Yes ...

      > But one of the prices for that flexibility is that you have to be straight
      > with your team and your product owner when things are in trouble. The
      > natural human instinct (at least in my neck of the woods) to sweep problems
      > under the rug is an enemy to the kind of trust and mutual respect we are
      > trying to build between the people with the money and the people with the
      > skills.

      Yes. But why do people sweep things under the rug?

      Don't see;
      Unpleasant Experience

      One reason can be that they don't see that they are in trouble. It doesn't
      sound like that's the case here: the Scrum Master appears to know that the
      team is in trouble. But the team might not know it, depending on how the
      communication is going. Is the team tracking burndown inside the Sprint? Do
      they all know what's going on?

      The main reason people don't tell the truth is that they envision something
      immediately unpleasant happening when they do. This could be something deep
      in their previous project history. And yet, I'd bet that the team members
      are talking about the impediments over coffee or beer, outside the Scrum.
      Why aren't they saying things in public? I suspect they fear reprisals.

      > So if you find that happening, I don't think it is unreasonable to let the
      > team suffer with unacceptable overtime, keeping the hope that they will
      > self-organize into sustainability in reaction to this by developing the
      > courage to speak up when changing conditions make the original promises
      > impossible to sensibly deliver.

      Well, there we are, reprisals. Speak up or I'll make you work
      //unacceptable overtime//. Unacceptable overtime doesn't even work. It
      doesn't get more software done, it doesn't get better software done. If
      someone pulls the unacceptable overtime card, he's going to lose a lot of
      my respect, and he's signalling strongly (to me) that he's not here to get
      impediments out of my way, he's here to crack the whip.

      What has happened when people raised impediments before? Were they
      belittled, told to deal with it, or did the Scrum Master do what (I'm told)
      he is supposed to do, and take that problem onto his shoulders, even if
      later all he does is sit down with the individual and help him solve it?

      These guys are afraid to talk, so we beat on them. That seems to me
      unlikely to work.

      > The price of the freedom and joy that Agilists seek in their work is
      > responsibility and discipline. And sometimes those values are painful
      > before we master them. Letting the team both suffer and enjoy the natural
      > consequences of their choices is part of the inherent power of Scrum (and
      > like approaches), and I think it is almost the duty of the Scrum Master to
      > let that happen, and point it out when it does.

      I'm not aware that pain and suffering are good teachers. They are not
      proximate enough to the cause to teach. What they will more likely teach,
      in my opinion, is that in this company, Scrum is just like everything else.
      They talk about the team and all that, they talk about helping us out, but
      when push comes to shove it's massive overtime all around.

      Again: I'm not attacking you guys. I'm describing the picture I get when
      two things happen:

      1. The team isn't mentioning impediments;
      2. The response is overtime.

      Ron Jeffries
      Take what you can -- give nothing back. -- Captain Jack Sparrow
    • Deb
      Ken s CSM course does cover Scrum pre-project steps - at different levels of detail for different situations: New Unfunded Projects, New Funded Projects,
      Message 66 of 66 , Oct 9, 2004
      • 0 Attachment
        Ken's CSM course does cover Scrum pre-project steps - at different
        levels of detail for different situations: New Unfunded Projects, New
        Funded Projects, Ongoing Projects, Fixed Price/Fixed Date Projects. In
        my copy of the methodology book, these are grouped under the title
        "planning" which occurs before the first Sprint Planning meeting.

        > On Thu, 07 Oct 2004 12:22:32 -0700, todd <todd@p...> wrote:
        > > The lack of a pre-project phase in all the methodologies is major
        > > in my mind.
        > I would not say this is true of Jim Highsmith's APM. Do others agree
        > or have a different view?
        > This could be an interesting discussion thread in its own right. What
        > do you do wtih the work before a project starts or is funded?
        > ==============================================
        > Alistair Cockburn
        > President, Humans and Technology
        > Phone: 801.582-3162
        > 1814 E. Fort Douglas Circle, Salt Lake City, UT 84103
        > _mailto_ (http://mailto/) : acockburn@a...
        > _http://alistair.cockburn.us/_ (http://alistair.cockburn.us/)
        > Author of
        > "Surviving Object-Oriented Projects" (1998)
        > "Writing Effective Use Cases" (Jolt Productivity Award 2001)
        > "Agile Software Development" (Jolt Productivity Award 2002)
        > "La perfection est atteinte non quand il ne reste rien a ajouter,
        > mais quand il ne reste rien a enlever." (Saint-Exupery)
        > ==============================================
      Your message has been successfully submitted and would be delivered to recipients shortly.