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

Re[2]: [scrumdevelopment] Re: Prioritization

Expand Messages
  • Doug Swartz
    ... Well, here is where I greatly from classic Scrum philosophy. I believe the product owner is not just an animal who contributes to the success of the
    Message 1 of 224 , Nov 1, 2008
    • 0 Attachment
      Friday, October 31, 2008, 12:34:34 AM, Gerald Williams wrote:

      > Well, anyone can attend a stand-up - the real question is
      > whether they are allowed to talk or not. I would say no -
      > but that they should be there as observers. Would I get
      > up-set if they were talking at a stand-up. No I would not -
      > I would just think whether common sense says its ok given
      > team size etc etc.

      Well, here is where I greatly from classic Scrum philosophy. I
      believe the product owner is not just an animal who
      contributes to the success of the breakfast being made my the
      team, but is definitely a wholly committed animal. Someone
      else on another (this?) thread recently said, "the product
      owner is the one wringable neck". I don't agree with the
      statement, but if considered true, no-one is more "committed"
      than the PO. It is also possible that my "whole team" attitude
      simply shows that I started growing up in the extreme
      programming world two or three years before I spent much time
      learning about Scrum.

      > One of the reasons for them acting as
      > observers at the stand-up  from my exerience is that this
      > allows the meeting to be quick (all the developers can
      > interact with the PO daily in any case as they are
      > co-located (ideally) and for the PO to pick up on what
      > further action s/he needs to get involved with post the
      > stand-up.

      Of course the PO will follow the same rules as the other team
      members in the meeting. Why then would the PO speaking cause
      the meeting to be long. Of course the PO will speak with the
      appropriate team members after the meeting to get in-depth and
      remove impediments. But, just like all the other team members,
      the PO has tasks s/he is working on to make the project
      successful. S/he might be working with the documentation
      writers or trainers, s/he might be working on a sales or
      marketing plan, etc. S/he will report on the progress of these
      tasks and any impediments s/he has encountered. The PO may
      find some of her tasks impeded because of things the
      developers haven't finished, just as the developers may be
      impeded by things the PO is responsible for.

      In my opinion, not allowing the PO to speak in the daily
      meeting can contribute to a parochial attitude by the
      developers that the software is all that matters. It's not.
      It's vitally important, but not solely important.
      The project will not be considered a success by upper
      management unless all the elements come to a successful
      conclusion.

      >  A co-located PO has a very good idea of what is
      > happening in the team for obvious reasons! The visible
      > display of project status - (to be done, in progress, done
      > etc)  helps the PO to also understand progress.  I like also
      > to see constraints and issues shown (and the date they were
      > raised) - as this adds pressure to eliminate them quickly
      > (why has this been there for 3 days, who's dealing etc)- and
      > the PO and anyone else can see it. So why should the PO ever
      > be 'in the dark' in a solid environment set-up?

      Absolutely, impediments should be visible and addressed
      outside the meeting. Absolutely, project status and progress
      should be visible to everyone.

      I don't advocate the PO speaks in the daily meeting to "keep
      the PO out of the dark". I advocate it because it helps keep
      the developers out of the dark, and the "whole project" on the
      right track.


      --

      Doug Swartz
    • Doug Swartz
      ... XP differs from kanban in many of the same ways as Scrum. It is batch pull, not continuous pull. Instead of a sprint, XP calls it an iteration. In XP, like
      Message 224 of 224 , Nov 19, 2008
      • 0 Attachment
        Wednesday, November 19, 2008, 3:05:08 PM, Dillon Weyer wrote:

        > In this case how is XP different to Kanban then?

        XP differs from kanban in many of the same ways as Scrum. It
        is batch pull, not continuous pull. Instead of a sprint, XP
        calls it an iteration. In XP, like scrum, but not kanban, each
        story has a high level estimate attached to it during release
        planning, which is similar, but somewhat different from
        backlog grooming in scrum.

        Doug Swartz


        > aacockburn wrote

        > --- In scrumdevelopment@yahoogroups.com
        > <mailto:scrumdevelopment%40yahoogroups.com> , Graeme Matthew <scrum@...>
        > wrote:
        >>
        >> Whats the difference between a product backlog and kanban they both
        > act
        >> as signaling system to trigger action?
        >>
        >>

        > The kanban is continuous pull, the backlog is batch pull.

        > With the backlogs, each month you *promise* how much you'll do, and
        > pull a *batch* of items from the product to the sprint backlog.
        > You're now locked.

        > With kanban, you pull directly from the product backlog to the
        > work list, one at a time. There is no work estimate attached to the
        > item - you just work on it till you're done, then pull the next.
        > Some teams put size limits on the work list, so you can't work on
        > more than e.g. 5 items at a time.

        > That's quite a difference.

        > Alistair
      Your message has been successfully submitted and would be delivered to recipients shortly.