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

Re: Scrum // Respect --> communication

Expand Messages
  • Joseph Little
    Hi, Yet another proof, if we needed one, that two people at a whiteboard is better than...well, any other form of communicating. Perhaps seance is better, but
    Message 1 of 224 , Nov 2, 2008
    • 0 Attachment
      Hi,

      Yet another proof, if we needed one, that two people at a whiteboard
      is better than...well, any other form of communicating.

      Perhaps seance is better, but I haven't seen that work in the work
      world. <smile>

      Note: This is hardly a lesson that Alistair, of all people, needed to
      learn, but some of us still do. I might be one.

      Regards, Joe

      PS. As bonus fun...For those of you who think Respect is an important
      topic and also can't help thinking of Aretha Franklin, let me commend
      that song to you as an alternate view of the subject. And maybe a way
      of getting the team to think about it in a fresh way. Jim Womack has
      also written a good piece on the subject.

      Again, let me voice my sympathy for those developers who have been
      abused in the past.



      --- In scrumdevelopment@yahoogroups.com, "aacockburn" <acockburn@...>
      wrote:
      >
      > --- In scrumdevelopment@yahoogroups.com, "Paul Hudson" <phudson@>
      > wrote:
      >
      > > We got into this discussion because you were saying the PO can
      > > or should dictate the sequence in which sprint backlog items
      > > get done. If there R S T W X Z, and W is in the "must haves", the
      > > PO can or should say to implement them in order W X Z T R S.
      > > I'm busy disagreeing with that.
      > >
      > > I've looked back at my replies and I don't think I said
      > > exactly that.
      >
      > You are correct - I went back and looked at your posts, and indeed,
      > you never said that. That's what I thought you were saying,
      > however :( sorry.
      >
      >
      > > I do think the PO should give an idea of what stories are
      > > most important and should be done first, just in case should
      > > things go awry,. I've agreed that MoSCoW prioritisation would
      > > be enough, for instance.
      >
      > Yes, and I found that posting, too.
      >
      > >
      > > Mostly, I've been arguing it is reasonable to assume up front
      > > that the team MAY not meet their commitment, and it is
      > > reasonable to organise things in advance to cater for
      > > this possibility, rather than wait until the team have
      > > recognised that things aren't going to plan
      >
      > OK, so it appears we agree.
      >
      > whew.
      >
      > Sorry for misinterpreting your words.
      >
      > Alistair
      >
    • 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.