I have taken the liberty of cross-posting to ScrumDevelopment.
I agree with Hubert's points.
I would guess there is a problem with your stories. They are probably
not sliced thin enough. The use of the word "tasks" suggests that
they are technical in nature, as opposed to being stories that use all
the layers of the architecture to directly provide user value. This
makes a big difference in the steady delivery of value, and therefore
Another common problem when you have multiple project for one team is
that individual developers are specialized and only work on stories
for one of the projects. This "siloing" may seem like the most
efficient use of each individual developer, but it actually inhibits
the team efficiency. Pairing a developer who specializes in one
project with a developer who specializes in the project for the
current story will help break down these silos. This may slow the
team down for a month or so, but it will pay off soon after that.
Lastly, I suspect bringing in an experienced agile coach for anywhere
from 1 to 6 weeks would be of great benefit.
On 8/10/06, Hubert Smits <hubert.smits@...> wrote:
> Hi Mikkel,
> You chose an interesting scenario to introduce Scrum into the
> organization, a single team with a single product owner would be
> easier. But life isn't alsways like that. Here is my feedback:
> > I cannot see any sense of urgency among the members of the SCRUM team
> > (lack of real commitment).
> That is a separate problem altogeter, not related to Scrum, Scrum
> highlights it. You have to find out where it hurts and address the
> > Tasks do not get completed in 1 sprint but tends to span more than
> > one sprint.
> Make them smaller.
> > It is hard (harder than pre-SCRUM) to give a date to the client, of
> > when a requested feature will be ready.
> Why? Is planning failing, is the backlog volatile, what is the reason
> you can't give a date?
> > Overall productivity seems low.
> Goes back to issue 1: find out what the problem in your team is, Srum
> just shows it, but doesn't solve it.
> > Senior mgmt is slowly loosing faith in agile methods due to all of
> > the above.
> I can understand this because they don't understand Scrum, they mix
> the identification of issues (which Scrum is doing) with fixing them
> (which Scrum doesn't necessarily do).
> > My derived questions would be something like these:
> > - Can we have a situation with 1 SCRUM team -> 1 Product Backlog -> n
> > PO's?
> Yes, you can - your solution to have a "super-PO" is the right one. As
> long as they produce a single prioritized backlog then Scrum works.
> There is more to say about the topic, and variations on this team, but
> this is the basic answer.
> > - Are we infesting the Sprint with the negative effects of
> > multitasking when we have a Sprint backlog based on minor
> > enhancements to multiple products?
> Yes, task switching is expensive. You may want to think about short
> sprints (2 weeks) and switch between POs between sprints. But I'd need
> to know more about the situation then I currently do to give a proper
> > - Aren't we really keeping the clients (the REAL PO's?) distanciated
> > by having internal PO's AND a "Chief of PO's" role?
> You don't have to, all the chief PO does is coordinate the fights
> between the POs, but the PO who owns the backlog item can still work
> during the sprint with the team.
> > Any feedback, especially from people with experiences in implementing
> > SCRUM in project services organisations, are welcome.
> > Also, this is my first posting in this group, so please be so kind
> > and guide me to any previous discussion/articles on this matter.
> > Best
> > Mikkel Kristiansen
> > IT Project Manager / ScM
> Good luck, keep asking questions!