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

Re: Bob Schatz in Mechelen: The Sprint Review is for the End-User.

Expand Messages
  • Michael James
    ... Did Ken forget also? http://groups.yahoo.com/group/scrumdevelopment/message/21324 ... --mj
    Message 1 of 62 , Mar 3, 2008
    • 0 Attachment
      --- In scrumdevelopment@yahoogroups.com, "Boris Gloger" <boris.gloger@...> wrote:
      >
      > but -- read Kens Book again. He talked about these six roles in his first book.
      > We simply forgot. Did not understand or did not wanted to hear it.
      >

      Did Ken forget also?

      http://groups.yahoo.com/group/scrumdevelopment/message/21324

      --- In scrumdevelopment@yahoogroups.com, "Ken Schwaber" <ken.schwaber@...> wrote:
      >
      > Dave,
      >
      > We specifically leave off the guidance or prescription to leave the people
      > free and responsible for managing for value, Sprint by Sprint. We break the
      > management role into three parts:
      >
      > 1. The team is responsible for managing itself.
      > 2. The ScrumMaster is responsible for managing the Process
      > 3. The Product Owner is responsible for managing the Product Backlog,
      > or "What" to maximize value. The PO tells the team what to do, the team
      > figures out how to do it.
      >
      >
      >
      > In the matrix, you give a lot of responsibility to the ScrumMaster that they
      > don't own. They aren't a replacement project manager. They are simply a
      > process manager and change agent.
      >
      >
      >
      > Scrum doesn't leave out project management methodological details to have
      > them filled in by other methodologies. It relies on the above three groups
      > to fill them in based on their knowledge, the circumstances, and their
      > intelligence. Scrum relies on a feedback loop for them to improve, not
      > external directions.
      >
      >
      >
      > Ken

      --mj
    • David A Barrett
      ... There are elements of Scrum (and Agile in general) that address the interaction of the Team with the End Users. The approach that we use, which I believe
      Message 62 of 62 , Mar 10, 2008
      • 0 Attachment
        >OK, the poor pigs and chickens have had their time. Instead of
        >interpreting Boris' post in a 0/1 perspective, I would like to extract
        >the valuable information and try to fit it into the Scrum framework.

        There are elements of Scrum (and Agile in general) that address the
        interaction of the Team with the End Users. The approach that we use,
        which I believe is essentially what Ken describes in the book, is that the
        programmers sit down with the actual users and discuss what they need. I
        believe that in a large part, this is what items 1 & 3 of the Agile
        Manifesto are talking about.

        From that perspective, we treat the End Users as "resources" and not Team
        members. It would be different if they were on the project full time,
        however.

        We also do the same thing with our web developer. He spends most of his
        time doing content changes and independant development. When we need him
        to do some work on something more involved and related to core systems, we
        usually only need a day or two of his time. So the Team's BA takes
        responsbility for his involvement, makes sure that he understands what's
        needed of him, and reports on his progress at the daily stand-up meeting.

        I think the biggest point to keep in mind is that you want to keep all of
        the distractions away from the Team if you can. This were the SM really
        earns his paycheck. If there are issues with the PO not talking to the End
        Users, or taking the project in the wrong direction, or whatever, then it
        really is up to the SM to be on top of those things and sort them out. The
        Team may notice them first, in which case I would expect them to be raised
        as impediments at a scrum, and then the SM is supposed to take it from
        there and stop it from further distracting the Team.

        So as far as implementing Scrum goes, I'd pretty much lay it all on the SM.
        He's the one who's supposed to understand how it all fits together, and
        he's the one that the Team needs to count on to make sure that it is, in
        fact, fitting together properly. The idea is to make sure that the needs
        of the chickens are looked after, but at the same time keep them from
        distracting the Team.

        Dave Barrett
      Your message has been successfully submitted and would be delivered to recipients shortly.