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

Re: [scrumdevelopment] Multi-project teams?

Expand Messages
  • Erich Oswald
    Hi Johanna, ... Your assumptions are absolutely correct. We do provide them with early drops, but can t control that they really deploy and test what they get.
    Message 1 of 24 , Sep 12, 2008
    • 0 Attachment
      Hi Johanna,

      Johanna Rothman wrote:
      > On Sep 11, 2008, at 4:54 AM, Erich Oswald wrote:
      >> 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.

      Your assumptions are absolutely correct. We do provide them with early
      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 more
      >>>> stable.
      >>> Yes.
      >>>> As a consequence, each team will have to work on multiple
      >>>> projects concurrently, some in active development, some in
      >>>> maintenance.
      >>> 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.

      I understand that much better now, thanks.

      > Or you have separate teams. But if your team is too small to split
      > onto several projects, why is your management committing to those
      > projects all at the same time?

      As I originally wrote, we currently do have separate teams for each
      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 successful
      >>>> teams together and allowing teams to distribute their know-how
      >>>> and self-organize their workload.
      >>> Yes.
      >>>> 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.

      Oh yes. Scrum has already helped us focus on doing less things better.
      We just explore where we could go from there.

      > Every organization has a need to decide on cross-project priorities. I
      > 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.

      Yes, that's the point I was trying to make, thanks for clarifying.

      >>> Here's the way one of my clients deals with this problem. They have
      >>> 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.

      That's what I thought. Sorry if I've given you the impression I was
      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.

      - Erich
    Your message has been successfully submitted and would be delivered to recipients shortly.