Re: Scrum // Respect --> communication
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
Note: This is hardly a lesson that Alistair, of all people, needed to
learn, but some of us still do. I might be one.
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 email@example.com, "aacockburn" <acockburn@...>
> --- In firstname.lastname@example.org, "Paul Hudson" <phudson@>
> > 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.
> Sorry for misinterpreting your words.
- 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.
> aacockburn wrote
> --- In email@example.com
> <mailto:scrumdevelopment%40yahoogroups.com> , Graeme Matthew <scrum@...>
>> Whats the difference between a product backlog and kanban they both
>> 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.