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

Thought experiment: When might it be good to do multiple projects?

Expand Messages
  • William Tozier
    I d like to follow up on a trope I ve seen recently in the discussions here. Suppose there is something like an XP studio . [I ll be vague and misdirect a
    Message 1 of 20 , Feb 26, 2007
    • 0 Attachment
      I'd like to follow up on a trope I've seen recently in the
      discussions here.

      Suppose there is something like an "XP studio". [I'll be vague and
      misdirect a bit, just to avoid muddying the waters. Imagine I'm
      talking about pure software development, and full-on XP done by Smart
      People who Get It and Like It. I kinda am, kinda am not]

      Say this Studio is a going concern. Clients apply by submitting
      project proposals via an online application process. The Studio team
      picks the their projects from these applications. Imagine these
      clients are lined up, so there's a surplus of applications (no,
      really; stop laughing).

      The Studio as a whole has the staff, time and resources to work on
      about 20 projects a year, on average.

      There are a dozen developers on the Studio team. At least two need to
      work on any given project at a given moment. On average, most
      projects will need only 4-8 people working 8 weeks. Very rarely will
      the whole team be needed to work on a single project to complete it
      in 8 weeks. However, occasionally some of the developers will have
      special skills needed on projects they're not necessarily interested
      in working on.

      The Studio developers themselves choose which project applications to
      accept. This might help: Think of the clients' project proposals as
      "überstories", and the Studio itself as an "übercustomer" in a kind
      of higher-order planning process. The developers (collectively,
      "customer") sit down and review the applications ("stories"), think
      about which ones most appeal to them, determine which will have the
      best business value (for the Studio), and think about how many people
      should and can work on each.

      Got the picture?

      Note: The Studio has the *option* to choose multiple projects to work
      on "at once" -- in a given iteration, if the resources are available.

      Now: The developers are considering when they should work on projects
      serially or in parallel.

      Under what circumstances should they consider it useful to work on
      multiple projects at the same time? Under what circumstances is it
      harmful?

      Suppose it was possible to break the team into subsets, so that each
      subset worked only on one project at a time. How would that affect
      your answer?

      Suppose it was necessary that two members with special skills work on
      every project, but only some of the time? I know it sounds weird for
      development, but as I said there's a helpful veil of fiction
      overlying what I'm really talking about. Imagine it's a union rule or
      something. How would that affect your answer?

      Please discuss.
      -----
      Bill Tozier
      AIM: vaguery@...
      blog: http://williamtozier.com/slurry
      plazes: http://beta.plazes.com/user/BillTozier
      skype: vaguery

      "Nature, however picturesque, never yet made a poet of a dullard."
      --Hjalmar Hjorth Boyesen
    • dnicolet99
      ... So far, it sounds a lot like the way we did agile work at my previous employer. ... We did this on a per project basis but not on a per iteration basis.
      Message 2 of 20 , Feb 26, 2007
      • 0 Attachment
        --- In extremeprogramming@yahoogroups.com, William Tozier <bill@...>
        wrote:
        >
        > I'd like to follow up on a trope I've seen recently in the
        > discussions here.
        >
        > Suppose there is something like an "XP studio". [I'll be vague and
        > misdirect a bit, just to avoid muddying the waters. Imagine I'm
        > talking about pure software development, and full-on XP done by Smart
        > People who Get It and Like It. I kinda am, kinda am not]
        >
        > Say this Studio is a going concern. Clients apply by submitting
        > project proposals via an online application process. The Studio team
        > picks the their projects from these applications. Imagine these
        > clients are lined up, so there's a surplus of applications (no,
        > really; stop laughing).
        >
        > The Studio as a whole has the staff, time and resources to work on
        > about 20 projects a year, on average.
        >
        > There are a dozen developers on the Studio team. At least two need to
        > work on any given project at a given moment. On average, most
        > projects will need only 4-8 people working 8 weeks. Very rarely will
        > the whole team be needed to work on a single project to complete it
        > in 8 weeks. However, occasionally some of the developers will have
        > special skills needed on projects they're not necessarily interested
        > in working on.
        >
        > The Studio developers themselves choose which project applications to
        > accept. This might help: Think of the clients' project proposals as
        > "überstories", and the Studio itself as an "übercustomer" in a kind
        > of higher-order planning process. The developers (collectively,
        > "customer") sit down and review the applications ("stories"), think
        > about which ones most appeal to them, determine which will have the
        > best business value (for the Studio), and think about how many people
        > should and can work on each.
        >
        > Got the picture?

        So far, it sounds a lot like the way we did agile work at my previous
        employer.

        >
        > Note: The Studio has the *option* to choose multiple projects to work
        > on "at once" -- in a given iteration, if the resources are available.

        We did this on a per project basis but not on a per iteration basis.
        IMO a portfolio of projects flows better when they are done serially
        than when people attempt to do too many of them in parallel. Teams can
        focus on delivering well-defined results one by one. The group as a
        whole gets more work finished in the course of a year and the work
        tends to be of higher quality than when management takes the approach
        of starting all projects so they can pretend everything is "in progress".

        > Now: The developers are considering when they should work on projects
        > serially or in parallel.
        >
        > Under what circumstances should they consider it useful to work on
        > multiple projects at the same time? Under what circumstances is it
        > harmful?

        Studies have shown that people work most effectively when they are
        multitasking between two tasks. It appears we actually do better work
        than when we have only one task to do. In a typical work environment,
        those tasks will be (a) a project and (b) administrative stuff that we
        have to do when we're part of an organization.

        Therefore, the logical conclusion is that it is "useful" to work on
        one project at a time. That, plus our administrative activities, gives
        us two tasks to juggle - just the right number. Beyond that, we begin
        to incur waste through excessive context-switching overhead. (Of
        course, that's assuming a team of humans. I'm not sure how imaginative
        you want us to be in discussing this.)

        >
        > Suppose it was possible to break the team into subsets, so that each
        > subset worked only on one project at a time. How would that affect
        > your answer?

        I've done it that way and it worked well. I may not have understood
        your question, though, because I don't see how it differs from what
        you wrote earlier. You described a "studio" of 12 from which smaller
        teams are carved out to carry out projects.

        >
        > Suppose it was necessary that two members with special skills work on
        > every project, but only some of the time? I know it sounds weird for
        > development, but as I said there's a helpful veil of fiction
        > overlying what I'm really talking about. Imagine it's a union rule or
        > something. How would that affect your answer?

        There is no need to imagine a union rule; this is a perfectly
        realistic issue. There are technical specialties that aren't needed
        full time, but that may be needed on multiple projects occasionally.
        For example, you don't need a database specialist to define your
        tables for you. Any developer can do that sort of routine work. You
        might need the specialist from time to time to help with stickier
        problems, like performance tuning or resolving a deadlock. People like
        that can work with multiple projects on a "consulting" basis.

        >
        > Please discuss.
        > -----
        > Bill Tozier
        > AIM: vaguery@...
        > blog: http://williamtozier.com/slurry
        > plazes: http://beta.plazes.com/user/BillTozier
        > skype: vaguery
        >
        > "Nature, however picturesque, never yet made a poet of a dullard."
        > --Hjalmar Hjorth Boyesen
        >
      • Jason Nocks
        ... I presented an experience report on this very topic for the Agile 2006 conference in Minneapolis last year. Short answer was that one project for one
        Message 3 of 20 , Feb 26, 2007
        • 0 Attachment
          On Monday 26 February 2007 08:26:36 am William Tozier wrote:
          > I'd like to follow up on a trope I've seen recently in the
          > discussions here.
          >
          > Suppose there is something like an "XP studio". [I'll be vague and
          > misdirect a bit, just to avoid muddying the waters. Imagine I'm
          > talking about pure software development, and full-on XP done by Smart
          > People who Get It and Like It. I kinda am, kinda am not]
          >
          > Say this Studio is a going concern. Clients apply by submitting
          > project proposals via an online application process. The Studio team
          > picks the their projects from these applications. Imagine these
          > clients are lined up, so there's a surplus of applications (no,
          > really; stop laughing).
          >
          > The Studio as a whole has the staff, time and resources to work on
          > about 20 projects a year, on average.
          >
          > There are a dozen developers on the Studio team. At least two need to
          > work on any given project at a given moment. On average, most
          > projects will need only 4-8 people working 8 weeks. Very rarely will
          > the whole team be needed to work on a single project to complete it
          > in 8 weeks. However, occasionally some of the developers will have
          > special skills needed on projects they're not necessarily interested
          > in working on.
          >
          > The Studio developers themselves choose which project applications to
          > accept. This might help: Think of the clients' project proposals as
          > "überstories", and the Studio itself as an "übercustomer" in a kind
          > of higher-order planning process. The developers (collectively,
          > "customer") sit down and review the applications ("stories"), think
          > about which ones most appeal to them, determine which will have the
          > best business value (for the Studio), and think about how many people
          > should and can work on each.
          >
          > Got the picture?
          >
          > Note: The Studio has the *option* to choose multiple projects to work
          > on "at once" -- in a given iteration, if the resources are available.
          >
          > Now: The developers are considering when they should work on projects
          > serially or in parallel.
          >
          > Under what circumstances should they consider it useful to work on
          > multiple projects at the same time? Under what circumstances is it
          > harmful?

          I presented an experience report on this very topic for the Agile 2006
          conference in Minneapolis last year. Short answer was that "one project for
          one team" is the simplest approach in general. We documented specific reasons
          why dealing with only one project at a time didn't work for our team, what we
          tried, what we felt worked/didn't, etc.

          > Suppose it was possible to break the team into subsets, so that each
          > subset worked only on one project at a time. How would that affect
          > your answer?

          Is this really a team of teams?

          > Suppose it was necessary that two members with special skills work on
          > every project, but only some of the time? I know it sounds weird for
          > development, but as I said there's a helpful veil of fiction
          > overlying what I'm really talking about. Imagine it's a union rule or
          > something. How would that affect your answer?
          >
          > Please discuss.

          Does the team need to focus on every project every day?

          Also, what iteration sizes would the team use?

          Can individual people focus on tasks from just one project at a time. Then,
          they pull in a pair to work with them. The pair might have a different task
          from a different project they are responsible for. That way, nobody
          has "multiple project" responsibility during a day.

          > -----
          > Bill Tozier
          > AIM: vaguery@...
          > blog: http://williamtozier.com/slurry
          > plazes: http://beta.plazes.com/user/BillTozier
          > skype: vaguery
          >
          > "Nature, however picturesque, never yet made a poet of a dullard."
          > --Hjalmar Hjorth Boyesen

          --
          Cheers,
          Jason Nocks
        • Ron Jeffries
          Hello, William. On Monday, February 26, 2007, at 8:26:36 AM, you ... Excellent ... I suppose there is a natural size to projects ... and
          Message 4 of 20 , Mar 8, 2007
          • 0 Attachment
            Hello, William. On Monday, February 26, 2007, at 8:26:36 AM, you
            wrote:

            > Suppose there is something like an "XP studio". [I'll be vague and
            > misdirect a bit, just to avoid muddying the waters. Imagine I'm
            > talking about pure software development, and full-on XP done by Smart
            > People who Get It and Like It. I kinda am, kinda am not]

            :)

            > Say this Studio is a going concern. Clients apply by submitting
            > project proposals via an online application process. The Studio team
            > picks the their projects from these applications. Imagine these
            > clients are lined up, so there's a surplus of applications (no,
            > really; stop laughing).

            <rubHands>Excellent</rubHands>

            > The Studio as a whole has the staff, time and resources to work on
            > about 20 projects a year, on average.

            > There are a dozen developers on the Studio team. At least two need to
            > work on any given project at a given moment. On average, most
            > projects will need only 4-8 people working 8 weeks. Very rarely will
            > the whole team be needed to work on a single project to complete it
            > in 8 weeks. However, occasionally some of the developers will have
            > special skills needed on projects they're not necessarily interested
            > in working on.

            > The Studio developers themselves choose which project applications to
            > accept. This might help: Think of the clients' project proposals as
            > "überstories", and the Studio itself as an "übercustomer" in a kind
            > of higher-order planning process. The developers (collectively,
            > "customer") sit down and review the applications ("stories"), think
            > about which ones most appeal to them, determine which will have the
            > best business value (for the Studio), and think about how many people
            > should and can work on each.

            > Got the picture?

            > Note: The Studio has the *option* to choose multiple projects to work
            > on "at once" -- in a given iteration, if the resources are available.

            > Now: The developers are considering when they should work on projects
            > serially or in parallel.

            > Under what circumstances should they consider it useful to work on
            > multiple projects at the same time? Under what circumstances is it
            > harmful?

            > Suppose it was possible to break the team into subsets, so that each
            > subset worked only on one project at a time. How would that affect
            > your answer?

            > Suppose it was necessary that two members with special skills work on
            > every project, but only some of the time? I know it sounds weird for
            > development, but as I said there's a helpful veil of fiction
            > overlying what I'm really talking about. Imagine it's a union rule or
            > something. How would that affect your answer?

            I suppose there is a natural size to projects ... and perhaps in
            your studio situation, some natural splits of skills. In software, I
            would generally favor small numbers of projects, ideally one
            project, because going parallel is usually less efficient, resulting
            in slower overall through put, and it is also hard to manage because
            more people have to assume that things are happening, with less
            feedback.

            Ron Jeffries
            www.XProgramming.com
            Make it real or else forget about it -- Carlos Santana
          • Kelly Anderson
            On 08 Mar 2007 21:21:12 -0800, Ron Jeffries ... If you were picking up projects from, say RentACoder or the like, then it would give you a setup very much like
            Message 5 of 20 , Mar 9, 2007
            • 0 Attachment
              On 08 Mar 2007 21:21:12 -0800, Ron Jeffries
              <ronjeffries@...> wrote:
              > Hello, William. On Monday, February 26, 2007, at 8:26:36 AM, you
              > > Note: The Studio has the *option* to choose multiple projects to work
              > > on "at once" -- in a given iteration, if the resources are available.
              >
              > I suppose there is a natural size to projects ... and perhaps in
              > your studio situation, some natural splits of skills. In software, I
              > would generally favor small numbers of projects, ideally one
              > project, because going parallel is usually less efficient, resulting
              > in slower overall through put, and it is also hard to manage because
              > more people have to assume that things are happening, with less
              > feedback.

              If you were picking up projects from, say RentACoder or the like, then
              it would give you a setup very much like what you're talking about. In
              terms of the life of the individual programmer, you would almost have
              to do things in parallel, with periods of stopping while awaiting
              customer feedback (because, perhaps they are time zones away), so
              while it would be locally suboptimal, it would be globally (yeah, I
              mean Globally) optimal.

              The downside of this sort of approach is that there's more than one
              Customer, and there are meaningful deadlines that you couldn't slip
              without risking the loss of funding. Also, the Customer isn't in the
              same room. All of these go against the traditional XP optimum setup,
              but it would also have some upsides because there would be practically
              limitless work, and you would get to pick and choose from the
              projects. Unfortunately, you would also be bidding against programmers
              who's living expenses are many times less than European or US
              requirements. Do you think in such a circumstance that XP would allow
              you to go so fast as to be competitive with a team in India working
              for $5-$7 an hour?

              RentACoder could use a few more XP teams. Hope I am not too close to
              your real plan William.

              -Kelly
            • Bill Caputo
              ... We (I work for Redbox, we have both product development and internal systems development to deliver) often run two projects/features through our iterations
              Message 6 of 20 , Mar 9, 2007
              • 0 Attachment
                > Under what circumstances should they consider it useful to work on
                > multiple projects at the same time? Under what circumstances is it
                > harmful?

                We (I work for Redbox, we have both product development and internal
                systems development to deliver) often run two projects/features
                through our iterations at once, but only if (one ore more of):

                * They affect disjoint areas of our code base (e.g. two different
                systems, different areas of the same system, etc).
                * They don't require an overburdening amount of context switching
                (pair switching is OK!) for those working on one or the other
                * (Usually) one is really small (e.g. sub-full-team-iteration in size)
                * We really have no choice.

                As a first pass we try to work it out with scheduling though (i.e.
                doing twin pipelines is neither as easily optimized nor simple as
                serialization).

                There's one place where I wish (and am planning) for more: Less
                critical (but important) infrastructure work that would benefit from
                having its own prioritization (i.e. its too easy to see the big time
                features win at the cost of starving little or less-well represented
                stakeholders' projects when they all sit in the same stack of cards).

                Best,
                Bill
              • Phlip
                When I m broke and I know each boss won t catch me. ;-) -- Phlip http://c2.com/cgi/wiki?ZeekLand
                Message 7 of 20 , Mar 9, 2007
                • 0 Attachment
                  When I'm broke and I know each boss won't catch me.

                  ;-)

                  --
                  Phlip
                  http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!
                • William Tozier
                  ... Nope. You ll hear more inna bit. ... Bill Tozier AIM: vaguery@mac.com blog: http://williamtozier.com/slurry plazes:
                  Message 8 of 20 , Mar 13, 2007
                  • 0 Attachment
                    On Mar 9, 2007, at 8:55 AM, Kelly Anderson wrote:

                    > RentACoder could use a few more XP teams. Hope I am not too close to
                    > your real plan William.

                    Nope. You'll hear more inna bit.


                    -----
                    Bill Tozier
                    AIM: vaguery@...
                    blog: http://williamtozier.com/slurry
                    plazes: http://beta.plazes.com/user/BillTozier
                    skype: vaguery

                    "Nature, however picturesque, never yet made a poet of a dullard."
                    --Hjalmar Hjorth Boyesen
                  • William Tozier
                    In general, I think it s interesting that none of us have brought up Getting Things Done, or the many variants. Surely when one person has multiple projects
                    Message 9 of 20 , Mar 13, 2007
                    • 0 Attachment
                      In general, I think it's interesting that none of us have brought up
                      Getting Things Done, or the many variants. Surely when one person has
                      multiple projects ongoing, there are reasonably rigorous ways of
                      dealing with time, deadlines, and maybe even paying attention to them
                      "serially" so frequently that it seems like parallel work.

                      I wonder what GTD for teams would be like? If there were, say: 12
                      "active" projects, each with an iteration plan and a list of stories,
                      and 12 team members who came in every day to pair up (as they wanted)
                      and address the open projects... I wonder how some of the insights
                      from GTD might apply to their decisions.
                      -----
                      Bill Tozier
                      AIM: vaguery@...
                      blog: http://williamtozier.com/slurry
                      plazes: http://beta.plazes.com/user/BillTozier
                      skype: vaguery

                      "Nature, however picturesque, never yet made a poet of a dullard."
                      --Hjalmar Hjorth Boyesen
                    • William Tozier
                      ... Reminds me of when I asked John Laird (the SOAR guy) when he would know that his project to train software to play Quake would be done. I was thinking
                      Message 10 of 20 , Mar 13, 2007
                      • 0 Attachment
                        On Mar 9, 2007, at 5:26 PM, Phlip wrote:

                        > When I'm broke and I know each boss won't catch me.

                        Reminds me of when I asked John Laird (the SOAR guy) when he would
                        know that his project to train software to play Quake would be done.
                        I was thinking about an acceptance test for an open-ended exploratory
                        sciency project. His acceptance test was, "When I run out of funding."

                        Wouldn't it be nice, Phlip, if your boss *made* you work on multiple
                        projects? Made you go out and have a life beyond that one measley
                        office?

                        'Nuff said.
                        -----
                        Bill Tozier
                        AIM: vaguery@...
                        blog: http://williamtozier.com/slurry
                        plazes: http://beta.plazes.com/user/BillTozier
                        skype: vaguery

                        "Nature, however picturesque, never yet made a poet of a dullard."
                        --Hjalmar Hjorth Boyesen
                      • Ron Jeffries
                        ... Teams I observe do better to serialize stories rather than try to go parallel, for two reasons: 1. When you do things in parallel, your ROI is pushed out
                        Message 11 of 20 , Mar 13, 2007
                        • 0 Attachment
                          Hello, Bill. On Tuesday, March 13, 2007, at 11:23:43 AM, you wrote:

                          > In general, I think it's interesting that none of us have brought up
                          > Getting Things Done, or the many variants. Surely when one person has
                          > multiple projects ongoing, there are reasonably rigorous ways of
                          > dealing with time, deadlines, and maybe even paying attention to them
                          > "serially" so frequently that it seems like parallel work.

                          > I wonder what GTD for teams would be like? If there were, say: 12
                          > "active" projects, each with an iteration plan and a list of stories,
                          > and 12 team members who came in every day to pair up (as they wanted)
                          > and address the open projects... I wonder how some of the insights
                          > from GTD might apply to their decisions.

                          Teams I observe do better to serialize stories rather than try to go
                          parallel, for two reasons:

                          1. When you do things in parallel, your ROI is pushed out in time
                          for all of them;

                          2. Task switch time is non-zero.

                          Ron Jeffries
                          www.XProgramming.com
                          Yesterday's code should be as good as we could make it yesterday.
                          The fact that we know more today, and are more capable today,
                          is good news about today, not bad news about yesterday.
                        • Kelly Anderson
                          Seems that this is fairly close to the Google model... -Kelly
                          Message 12 of 20 , Mar 13, 2007
                          • 0 Attachment
                            Seems that this is fairly close to the Google model...

                            -Kelly

                            On 3/13/07, William Tozier <bill@...> wrote:
                            > In general, I think it's interesting that none of us have brought up
                            > Getting Things Done, or the many variants. Surely when one person has
                            > multiple projects ongoing, there are reasonably rigorous ways of
                            > dealing with time, deadlines, and maybe even paying attention to them
                            > "serially" so frequently that it seems like parallel work.
                            >
                            > I wonder what GTD for teams would be like? If there were, say: 12
                            > "active" projects, each with an iteration plan and a list of stories,
                            > and 12 team members who came in every day to pair up (as they wanted)
                            > and address the open projects... I wonder how some of the insights
                            > from GTD might apply to their decisions.
                            > -----
                            > Bill Tozier
                          • Kelly Anderson
                            ... Both of these are valid points Ron. But there may sometimes be extenuating circumstances that would make it worth doing anyway. Suppose, for example, that
                            Message 13 of 20 , Mar 13, 2007
                            • 0 Attachment
                              On 3/13/07, Ron Jeffries <ronjeffries@...> wrote:
                              > Teams I observe do better to serialize stories rather than try to go
                              > parallel, for two reasons:
                              >
                              > 1. When you do things in parallel, your ROI is pushed out in time
                              > for all of them;
                              >
                              > 2. Task switch time is non-zero.

                              Both of these are valid points Ron. But there may sometimes be
                              extenuating circumstances that would make it worth doing anyway.
                              Suppose, for example, that you had some really crappy job that
                              absolutely needed doing. Say, fixing damaged user databases using a
                              binary editor, or programming HL7, just to have something to talk
                              about. In order to get people happy about doing such grisly work, you
                              could let them also do the most fun activity in the building the other
                              half of the day. Keep people from burning out on the really un-fun
                              stuff.

                              Whaddayathink?

                              -Kelly
                            • Michael Kelly
                              One option for getting a single team working effectively on multiple projects is a technique developed by Arlo Belshee called Promiscuous Pairing (see
                              Message 14 of 20 , Mar 13, 2007
                              • 0 Attachment
                                One option for getting a single team working effectively on multiple
                                projects is a technique developed by Arlo Belshee called "Promiscuous
                                Pairing" (see http://csdl2.computer.org/persagen/DLAbsToc.jsp?resourcePath=/dl/proceedings/&toc=comp/proceedings/adc/2005/2487/00/2487toc.xml&DOI=10.1109/ADC.2005.37).

                                The core idea is that you swap pairing partners every 90 minutes or
                                so. Typically, you set an egg timer and as soon as the bell rings one
                                person in the pair rotates to a new partner (and a new task). The next
                                time the bell rings, the one who stayed previously moves on while the
                                new person carries the torch.

                                Here's one team's description of using it at Microsoft:
                                http://csdl2.computer.org/persagen/DLAbsToc.jsp?resourcePath=/dl/proceedings/&toc=comp/proceedings/agile/2006/2562/00/2562toc.xml&DOI=10.1109/AGILE.2006.7.

                                After seeing one of Arlo's presentations, my team decided to give it a
                                try. As it happened, we were just embarking on a release that had two
                                main deliverables, each of which had significant design complexity but
                                could not be easily parallelized. We found that promiscuous pairing,
                                while adding additional and regular ramp-up costs, was very effective
                                at getting every mind on the team deeply engaged in both deliverables.
                                My subjective assessment was that both deliverables were better for it
                                in terms of design and implementation, and that there were several
                                critical insights that saved us the time lost in ramp-up. In addition,
                                it was fun--a bit like the coders' version of tag-team wrestling.

                                Perhaps suggestive of promiscuous pairings proper place in the agile
                                toolkit is the fact that the team abandoned it in the next release--a
                                release which required less design goodness and more juggling of
                                mundane details. It was just too difficult to transmit all the details
                                every pair swap, and there seemed to be little value in doing so.

                                To be sure, this technique is not for the faint of heart. We had to be
                                revved up and ready to play. Keeping on top of things, staying focused
                                enough to carry the torch and capable of making useful contributions,
                                required a special vigilance. But I look back on the experience with
                                fondness, and hope to find an appropriate opportunity to do it again.

                                -=michael=-

                                On 3/13/07, Kelly Anderson <kellycoinguy@...> wrote:
                                >
                                >
                                >
                                >
                                >
                                >
                                > Seems that this is fairly close to the Google model...
                                >
                                > -Kelly
                                >
                                > On 3/13/07, William Tozier <bill@...> wrote:
                                > > In general, I think it's interesting that none of us have brought up
                                > > Getting Things Done, or the many variants. Surely when one person has
                                > > multiple projects ongoing, there are reasonably rigorous ways of
                                > > dealing with time, deadlines, and maybe even paying attention to them
                                > > "serially" so frequently that it seems like parallel work.
                                > >
                                > > I wonder what GTD for teams would be like? If there were, say: 12
                                > > "active" projects, each with an iteration plan and a list of stories,
                                > > and 12 team members who came in every day to pair up (as they wanted)
                                > > and address the open projects... I wonder how some of the insights
                                > > from GTD might apply to their decisions.
                                > > -----
                                > > Bill Tozier
                                >
                              • Thomas Eyde
                                Hi. It seems to me that this problem fits the optimization rule, with a little twist: 1. Don t do it 2. If you really have to, do it one story at a time. I
                                Message 15 of 20 , Mar 14, 2007
                                • 0 Attachment
                                  Hi.

                                  It seems to me that this problem fits the optimization rule, with a little
                                  twist:

                                  1. Don't do it
                                  2. If you really have to, do it one story at a time.

                                  I guess the need to do stories in parallel is a tight schedule. In that
                                  case, the stories should be small to get the desired outcome. And the
                                  stories need to be prioritized.

                                  --
                                  Thomas

                                  On 3/14/07, Kelly Anderson <kellycoinguy@...> wrote:
                                  >
                                  > On 3/13/07, Ron Jeffries <ronjeffries@...<ronjeffries%40xprogramming.com>>
                                  > wrote:
                                  > > Teams I observe do better to serialize stories rather than try to go
                                  > > parallel, for two reasons:
                                  > >
                                  > > 1. When you do things in parallel, your ROI is pushed out in time
                                  > > for all of them;
                                  > >
                                  > > 2. Task switch time is non-zero.
                                  >
                                  > Both of these are valid points Ron. But there may sometimes be
                                  > extenuating circumstances that would make it worth doing anyway.
                                  > Suppose, for example, that you had some really crappy job that
                                  > absolutely needed doing. Say, fixing damaged user databases using a
                                  > binary editor, or programming HL7, just to have something to talk
                                  > about. In order to get people happy about doing such grisly work, you
                                  > could let them also do the most fun activity in the building the other
                                  > half of the day. Keep people from burning out on the really un-fun
                                  > stuff.
                                  >


                                  [Non-text portions of this message have been removed]
                                • David Winslow
                                  Hi, Has anyone got experience with using MS team system for the full lifecycle of a project? If so could you provide me with some feedback that worked out for
                                  Message 16 of 20 , Mar 14, 2007
                                  • 0 Attachment
                                    Hi,

                                    Has anyone got experience with using MS team system for the full lifecycle
                                    of a project?
                                    If so could you provide me with some feedback that worked out for you. I am
                                    particular interested in how you structured your requirements in Team
                                    System.

                                    Thanks,

                                    David
                                  • Ron Jeffries
                                    Hello, Kelly. On Wednesday, March 14, 2007, at 12:32:10 AM, you ... There can be reasons. Strategically, however, not my fave. Ron Jeffries
                                    Message 17 of 20 , Mar 14, 2007
                                    • 0 Attachment
                                      Hello, Kelly. On Wednesday, March 14, 2007, at 12:32:10 AM, you
                                      wrote:

                                      > Both of these are valid points Ron. But there may sometimes be
                                      > extenuating circumstances that would make it worth doing anyway.
                                      > Suppose, for example, that you had some really crappy job that
                                      > absolutely needed doing. Say, fixing damaged user databases using a
                                      > binary editor, or programming HL7, just to have something to talk
                                      > about. In order to get people happy about doing such grisly work, you
                                      > could let them also do the most fun activity in the building the other
                                      > half of the day. Keep people from burning out on the really un-fun
                                      > stuff.

                                      > Whaddayathink?

                                      There can be reasons. Strategically, however, not my fave.

                                      Ron Jeffries
                                      www.XProgramming.com
                                      I once had a coworker who worked so hard that when I came in the
                                      morning, he was already sitting there trying to fix the things he
                                      broke after I left the day before ... -- Ilja Preuss.
                                    • Kelly Anderson
                                      Sounds like the Agile equivalent of speed dating. Yikes! -Kelly
                                      Message 18 of 20 , Mar 14, 2007
                                      • 0 Attachment
                                        Sounds like the Agile equivalent of speed dating. Yikes!

                                        -Kelly

                                        On 3/14/07, Michael Kelly <m.sean.kelly@...> wrote:
                                        > One option for getting a single team working effectively on multiple
                                        > projects is a technique developed by Arlo Belshee called "Promiscuous
                                        > Pairing" (see http://csdl2.computer.org/persagen/DLAbsToc.jsp?resourcePath=/dl/proceedings/&toc=comp/proceedings/adc/2005/2487/00/2487toc.xml&DOI=10.1109/ADC.2005.37).
                                      • Peter Ibbotson
                                        There are some replies from a message I posted last week on just this subject. I am investigating the conchango plugin over the weekend running on a TFS demo
                                        Message 19 of 20 , Mar 15, 2007
                                        • 0 Attachment
                                          There are some replies from a message I posted last week on just this subject.

                                          I am investigating the conchango plugin over the weekend running on a
                                          TFS demo server and I then may try on my new gig.

                                          Peter
                                        • Simon Jones
                                          I d agree. For the last year we ve been blending several projects into one work funnel.. it avoids the obvious overhead in going parallel and allow more
                                          Message 20 of 20 , May 7, 2007
                                          • 0 Attachment
                                            I'd agree. For the last year we've been blending several projects
                                            into one work funnel.. it avoids the obvious overhead in going
                                            parallel and allow more flexibility in juggling stories. Given that
                                            there are also common systems involved it ensures those systems grow
                                            organically in such as way as to be sympathetic to each of the
                                            individual project needs. Its also means knowledge gained from
                                            challenges in one project is more immediately available to story
                                            development for the others. Also, also we often encounters stories
                                            where, when it comes to developing them our customers are struggling
                                            for the necessary detail and answers to our questions. By combining
                                            projects its easier to 'park' a story and slot something else in.

                                            Word of caution however. In our environment multiple projects means
                                            a proliferation of customers and domain experts who all need to be
                                            kept in touch throughout the overall uber-project.. this can be very
                                            time consuming and means we often have to fall back to using a
                                            customer-by-proxy and the inherent difficulties this introduces...

                                            But overall, for 3 or 4 concurrent projects my preference is to mix
                                            them together.

                                            Simon

                                            --- In extremeprogramming@yahoogroups.com, Ron Jeffries
                                            <ronjeffries@...> wrote:
                                            >
                                            > Hello, William. On Monday, February 26, 2007, at 8:26:36 AM, you
                                            > wrote:
                                            >
                                            > > Suppose there is something like an "XP studio". [I'll be vague
                                            and
                                            > > misdirect a bit, just to avoid muddying the waters. Imagine I'm
                                            > > talking about pure software development, and full-on XP done by
                                            Smart
                                            > > People who Get It and Like It. I kinda am, kinda am not]
                                            >
                                            > :)
                                            >
                                            > > Say this Studio is a going concern. Clients apply by submitting
                                            > > project proposals via an online application process. The Studio
                                            team
                                            > > picks the their projects from these applications. Imagine these
                                            > > clients are lined up, so there's a surplus of applications (no,
                                            > > really; stop laughing).
                                            >
                                            > <rubHands>Excellent</rubHands>
                                            >
                                            > > The Studio as a whole has the staff, time and resources to work
                                            on
                                            > > about 20 projects a year, on average.
                                            >
                                            > > There are a dozen developers on the Studio team. At least two
                                            need to
                                            > > work on any given project at a given moment. On average, most
                                            > > projects will need only 4-8 people working 8 weeks. Very rarely
                                            will
                                            > > the whole team be needed to work on a single project to complete
                                            it
                                            > > in 8 weeks. However, occasionally some of the developers will
                                            have
                                            > > special skills needed on projects they're not necessarily
                                            interested
                                            > > in working on.
                                            >
                                            > > The Studio developers themselves choose which project
                                            applications to
                                            > > accept. This might help: Think of the clients' project proposals
                                            as
                                            > > "überstories", and the Studio itself as an "übercustomer" in a
                                            kind
                                            > > of higher-order planning process. The developers (collectively,
                                            > > "customer") sit down and review the applications ("stories"),
                                            think
                                            > > about which ones most appeal to them, determine which will have
                                            the
                                            > > best business value (for the Studio), and think about how many
                                            people
                                            > > should and can work on each.
                                            >
                                            > > Got the picture?
                                            >
                                            > > Note: The Studio has the *option* to choose multiple projects to
                                            work
                                            > > on "at once" -- in a given iteration, if the resources are
                                            available.
                                            >
                                            > > Now: The developers are considering when they should work on
                                            projects
                                            > > serially or in parallel.
                                            >
                                            > > Under what circumstances should they consider it useful to work
                                            on
                                            > > multiple projects at the same time? Under what circumstances is
                                            it
                                            > > harmful?
                                            >
                                            > > Suppose it was possible to break the team into subsets, so that
                                            each
                                            > > subset worked only on one project at a time. How would that
                                            affect
                                            > > your answer?
                                            >
                                            > > Suppose it was necessary that two members with special skills
                                            work on
                                            > > every project, but only some of the time? I know it sounds weird
                                            for
                                            > > development, but as I said there's a helpful veil of fiction
                                            > > overlying what I'm really talking about. Imagine it's a union
                                            rule or
                                            > > something. How would that affect your answer?
                                            >
                                            > I suppose there is a natural size to projects ... and perhaps in
                                            > your studio situation, some natural splits of skills. In software,
                                            I
                                            > would generally favor small numbers of projects, ideally one
                                            > project, because going parallel is usually less efficient,
                                            resulting
                                            > in slower overall through put, and it is also hard to manage
                                            because
                                            > more people have to assume that things are happening, with less
                                            > feedback.
                                            >
                                            > Ron Jeffries
                                            > www.XProgramming.com
                                            > Make it real or else forget about it -- Carlos Santana
                                            >
                                          Your message has been successfully submitted and would be delivered to recipients shortly.