Re: [scrumdevelopment] Multi-project teams?
- Hi Johanna,
Johanna Rothman wrote:
> On Sep 11, 2008, at 4:54 AM, Erich Oswald wrote:Your assumptions are absolutely correct. We do provide them with early
>> Johanna Rothman wrote:
>>> On Sep 9, 2008, at 7:01 AM, Erich Oswald wrote:
> You have the same problem any consulting/contracting organization has.
> You offer them slots in your portfolio. "If you sign with us today, we
> can guarantee we can start here. If you wait, we'll discuss when we
> can start." I assume that when the customer has to prepare for
> deployment, you need to make sure people are available when they run
> into trouble? Consider interim demos/drops to them, so they can start
> their deployment activities earlier.
drops, but can't control that they really deploy and test what they get.
>>>> Our main idea is to make our teams bigger and to make them moreI understand that much better now, thanks.
>>>> As a consequence, each team will have to work on multiple
>>>> projects concurrently, some in active development, some in
>>> Why do you need to work on multiple projects concurrently? What's
>>> wrong with decreasing your timebox and making sure people work on
>>> only one project in that timebox? And that everyone keeps working
>>> together on a team inside that timebox?
>> We simply didn't think of that, but it's definitely worth a thought.
>> It would enforce that people really get themselves acquainted with
>> different projects, whereas by giving them multiple projects we risk
>> that they form sub-teams for different projects and know-how remains
>> concentrated on key persons.
>> Do you have any experience how well this goes down with customers?
>> At first it sounds terrible ("sorry, we're not going to do anything
>> for you this week"), but maybe it can be turned into a benefit
>> ("look, you'll have a whole week to review the last delivery and
>> adjust the product backlog").
> My experience is that you don't have to tell them *everything*, and if
> you give them interim drops with a request for feedback, it's *their*
> turn to work on the project, so you can do other work.
> The problem with multitasking is that it's the illusion of progress.
> It's not real progress. What do you say now? "We're working on it."
> You are if you work on only one project in a timebox and devote all
> your mental energy to that one project. You're just not working on
> their project in that timebox.
> Or you have separate teams. But if your team is too small to splitAs I originally wrote, we currently do have separate teams for each
> onto several projects, why is your management committing to those
> projects all at the same time?
project and aren't knowingly over-committing. The problem is the
frequent shuffling of team members and the unrest that causes.
>>>> This will help us in keeping teams collocated, keeping successfulOh yes. Scrum has already helped us focus on doing less things better.
>>>> teams together and allowing teams to distribute their know-how
>>>> and self-organize their workload.
>>>> However, we're worried that we're breaking with Scrum-by-the-book
>>>> with that approach:
>>>> * I seem to remember a discussion on this list where a lot of you
>>>> advised against a team being responsible for multiple concurrent
>>>> projects. What are our alternatives?
>>> Multiple concurrent projects is a great way to get nothing done.
>>> You can:
>>> - use kanban approaches to have everyone work feature-by-feature
>>> for whatever project the feature exists on. This requires giving
>>> up the idea of teams-for-projects.
>> I've read about kanban in the Poppendieck books and that experienced
>> agile teams sometimes choose to abandon iterations in favour of
>> kanban. At our level it sounds like a recipe for total chaos.
> Yeah, it's not so good for teams who don't already have significant
> internal discipline. But the idea behind kanban, that you fix the
> number of tasks in process is something you can use. You can fix the
> number of projects in progress. You can fix the number of tasks in
> progress *inside* a timebox, so you always finish what you commit to.
> You fix a timebox duration.
We just explore where we could go from there.
> Every organization has a need to decide on cross-project priorities. IYes, that's the point I was trying to make, thanks for clarifying.
> prefer doing it with the projects themselves. Which project is #1 for
> this timebox? But if your managers won't manage, the POs need to
> decide. If they are customers, you are opening yourselves to
> significant lack of trust in management: Imagine if customer #1 and
> customer #2 get into a shouting match about who is more important. How
> can they possibly decide? To them, they are each most important. Only
> your managers can decide.
>>> Here's the way one of my clients deals with this problem. They haveThat's what I thought. Sorry if I've given you the impression I was
>>> a single product development team of about 25 people, including
>>> all the developers and testers they are going to get. They have
>>> multiple product owners representing external customers. The POs
>>> get together once every two weeks, just before the start of the
>>> next iteration and fight about who gets what. The POs' managers
>>> manage the project portfolio, deciding which project will be
>>> released first. That helps.
>> 25 people sounds a bit large for a daily Scrum :-)
> SOrry to be unclear. They have Scrum of Scrums. About 7-8 people on a
> team, one team has more.
seriously thinking otherwise. I suppose they try to assign tasks from
the same project to the same team but want to have the added
flexibility of having one team help out another when necessary.