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

Re: [scrumdevelopment] Re: question regarding muliple projects against a small team

Expand Messages
  • Michael D. Ivey
    ... I think I see part of the problem. You ve made an assumption here: individual goals which are (probably) assigned by management If you drop assigned by
    Message 1 of 29 , May 10, 2004
    • 0 Attachment
      On Mon, May 10, 2004 at 10:17:01AM -0400, David A Barrett wrote:
      > So why am I worried? Well Deb puts up the spreadsheet which appears
      > to shift the focus from teamwork back onto individually managed people
      > with individual goals which are (probably) assigned by management, and
      > the next thing we see on this list are a whole bunch of posts from
      > people saying they think this is really cool. So then I wonder if
      > people are looking at this and saying to themselves, "Hey, this is the
      > missing link! I can implement Scrum while still keeping my
      > subordinates directly accountable to myself, and I can maintain
      > control on an individual basis".

      I think I see part of the problem. You've made an assumption here:
      "individual goals which are (probably) assigned by management"

      If you drop "assigned by management" from your thinking, does the
      spreadsheet become more useful?

      In my experiences with Scrum, the team commits collectively to a goal,
      but will naturally divide the work among themselves. This spreadsheet
      is one way to do that. The task assignments are fluid and
      team-determined, but they still exist.

      The ScrumMaster does /not/ make assignments, but merely (?) facilitates
      the process, helping the team manage themselves.

      Does that help?

      --
      Michael D. Ivey, Senior Partner | mdi@...
      Ivey & Brown, Inc. | http://www.iveyandbrown.com
      Process and Technology Consulting | (866) 235-7764
    • David A Barrett
      ... I wondered if anyone would latch onto that. It s a valid point. First, I figure anyone who s going to go to the trouble of maintaining individual
      Message 2 of 29 , May 10, 2004
      • 0 Attachment
        >I think I see part of the problem. You've made an assumption here:
        >"individual goals which are (probably) assigned by management"

        I wondered if anyone would latch onto that. It's a valid point.

        First, I figure anyone who's going to go to the trouble of maintaining
        individual burndowns is probably enough of a control freak to assign the
        tasks as well. I guess what I'm saying is that I don't think it's a shakey
        assumption, so I'm not that willing to toss it out. Even if you do assume
        that the team sets its own goals, this kind of tracking seems specifically
        aimed at preventing the team from acting as a team.

        Second, what's the purpose of such tracking? I see three good reasons for
        maintaining a team burndown graph: 1. To prove to management that you've
        got things under control; 2. To assist the team in knowing if they are on
        track for their sprint goals; 3. As a learning aid for the team when
        setting later sprint backlog lists. These all have value. I don't see how
        the individual burn down graphs are going to add any extra value.

        Lastly - and I hesitate to mention this one - I wonder how someone's use of
        such graphs reflects on the their understanding of Scrum. To me (and I
        have to keep on saying that over and over again, "To me"), the idea of
        Scrum is point the team in the right direction, wind them up, let them go
        and get out of the way. As Reg Braithwaite-Lee said (I'm paraphrasing
        now), "Simply bring together talented people and remove the obstructions
        for them".


        Dave Barrett,
        Lawyers' Professional Indemnity Company
      • Mike Cohn
        Dave-- I think it s a bit of a stretch to question someone s understanding of Scrum because they want to track individual burndown. Like I mentioned in another
        Message 3 of 29 , May 10, 2004
        • 0 Attachment
          Dave--
          I think it's a bit of a stretch to question someone's understanding of Scrum
          because they want to track individual burndown.

          Like I mentioned in another post, I tried tracking individual burndown but I
          did it to help programmers who were overcommitting (especially at the start)
          to see that they were overcommitting. They signed up for tasks. I assigned
          nothing. This was one of those teams that would look at a schedule and
          think, "Hmm, 40 hours this week, let's sign up for 3000 hours of coding. I
          think we can do that." I just wanted them to see--in a single number--that
          they were overcommitting. The individual burndown graphs I did *should have*
          had value in this direction but even confronted with such a number this team
          kept thinking they could make it. (They never would.)

          From what I've seen of Deb's other posts she has a very good understanding
          of Scrum and I suspect her individual burndown tracking is presented to them
          for their benefit, not hers.

          --Mike Cohn
          Author of User Stories Applied for Agile Software Development
          www.userstories.com


          -----Original Message-----
          From: David A Barrett [mailto:dave.barrett@...]
          Sent: Monday, May 10, 2004 9:59 AM
          To: scrumdevelopment@yahoogroups.com
          Subject: [scrumdevelopment] Re: question regarding muliple projects against
          a small team





          >I think I see part of the problem. You've made an assumption here:
          >"individual goals which are (probably) assigned by management"

          I wondered if anyone would latch onto that. It's a valid point.

          First, I figure anyone who's going to go to the trouble of maintaining
          individual burndowns is probably enough of a control freak to assign the
          tasks as well. I guess what I'm saying is that I don't think it's a shakey
          assumption, so I'm not that willing to toss it out. Even if you do assume
          that the team sets its own goals, this kind of tracking seems specifically
          aimed at preventing the team from acting as a team.

          Second, what's the purpose of such tracking? I see three good reasons for
          maintaining a team burndown graph: 1. To prove to management that you've
          got things under control; 2. To assist the team in knowing if they are on
          track for their sprint goals; 3. As a learning aid for the team when
          setting later sprint backlog lists. These all have value. I don't see how
          the individual burn down graphs are going to add any extra value.

          Lastly - and I hesitate to mention this one - I wonder how someone's use of
          such graphs reflects on the their understanding of Scrum. To me (and I
          have to keep on saying that over and over again, "To me"), the idea of
          Scrum is point the team in the right direction, wind them up, let them go
          and get out of the way. As Reg Braithwaite-Lee said (I'm paraphrasing
          now), "Simply bring together talented people and remove the obstructions
          for them".


          Dave Barrett,
          Lawyers' Professional Indemnity Company




          To Post a message, send it to: scrumdevelopment@...
          To Unsubscribe, send a blank message to:
          scrumdevelopment-unsubscribe@...
          Yahoo! Groups Links
        • Deb
          There s some interesting discussion on the individual burndown feature of our spreadsheet here... I m going in to a meeting right now, but I can give you
          Message 4 of 29 , May 10, 2004
          • 0 Attachment
            There's some interesting discussion on the "individual burndown"
            feature of our spreadsheet here... I'm going in to a meeting right
            now, but I can give you some context when I get back later.

            For now:
            a) team decides who does what, breaks Product Backlog items down into
            tasks and estimates them. Only the team does this - scrummaster plays
            scribe.
            b) this created as a local response to culture change issues, and
            operates within a given context. (Seems related to comment by Ken in
            this thread.)

            more later
            :-)
            deb

            --- In scrumdevelopment@yahoogroups.com, David A Barrett
            <dave.barrett@l...> wrote:
            >
            >
            >
            >
            > Ok, so now I'm a little worried.
            >
            > The more I think about it, the less comfortable I am with Deb's
            spreadsheet
            > and the way it focuses on the individuals' performance...
          • Deb
            I guess I m responding to different aspects of this post in a couple of sub-threads... Dave, just to be clear, how do you see the Individual Burndown as a way
            Message 5 of 29 , May 12, 2004
            • 0 Attachment
              I guess I'm responding to different aspects of this post in a couple
              of sub-threads...

              Dave, just to be clear, how do you see the Individual Burndown as a
              way to track performance? It seems to be missing so much information
              (that Scrum does not record) that it could only serve
              to /misinterpret/ performance, and it seems to me that the people
              using it would know that... but maybe you are seeing something
              different?

              deb

              PS: people are not necessarily responding to the Individual Burndown
              aspect, are they? There are a bunch of worksheets there... My
              assumption is: if you are using XP then the Indiv Burndown is
              probably extraneous.



              --- In scrumdevelopment@yahoogroups.com, David A Barrett
              <dave.barrett@l...> wrote:
              >
              >
              >
              >
              > Ok, so now I'm a little worried.
              >
              > The more I think about it, the less comfortable I am with Deb's
              spreadsheet
              > and the way it focuses on the individuals' performance. This
              clashes
              > totally with what I perceived to be key component of the Scrum
              methodology;
              > the team aspect.
              >
              > In the ScrumMaster course, Ken made a point about ensuring that the
              daily
              > scrums were about the team members reporting to each other. He
              advised
              > doing things like avoiding eye contact with the team members in
              order to
              > avoid having them report *to* the scrummaster. I can think of
              numerous
              > other examples where he went out of his way to stress that the
              > scrummaster's role was *not* to organize and control the team's
              activities.
              > The chicken and pig concept, which seems to be a pillar of the
              methodology,
              > puts the emphasis on the team and shared goals.
              >
              > So why am I worried? Well Deb puts up the spreadsheet which
              appears to
              > shift the focus from teamwork back onto individually managed people
              with
              > individual goals which are (probably) assigned by management, and
              the next
              > thing we see on this list are a whole bunch of posts from people
              saying
              > they think this is really cool. So then I wonder if people are
              looking at
              > this and saying to themselves, "Hey, this is the missing link! I
              can
              > implement Scrum while still keeping my subordinates directly
              accountable to
              > myself, and I can maintain control on an individual basis".
              >
              > Now the last thing I want to be is dogmatic, but I'm thinking that
              if you
              > are managing your team with this spreadsheet (and the management
              style that
              > it implies) then it's not Scrum anymore. It may be effective, it
              may
              > support iterative and incemental, but it's not Scrum. If it's not
              Scrum,
              > what does that mean?
              >
              > Perhaps if Mike or Ken could step in at this time and express an
              opinion it
              > would help to clarify this for me.
              >
              >
              > Dave Barrett,
              > Lawyers' Professional Indemnity Company
            • Maurizio Tripi
              Dear Deborah, your individual burndown is what I called the personal sprint backlog & burndown graph, and was one of the experiments I tried 3 years ago
              Message 6 of 29 , May 13, 2004
              • 0 Attachment
                Dear Deborah,
                your individual burndown is what I called the personal sprint backlog &
                burndown graph,
                and was one of the experiments I tried 3 years ago during a project. I
                can't say it is a good
                approach in general. I tried this technique because that team found hard
                to self-organize.
                The team was not as much collaborative as I was willing, their
                estimations were oscillating
                and they didn't reach a good rhythm. Hence I tried to help them with
                the personal sprint backlog.
                I tried to divide the product backlog per person to find the problem but
                things didn't get better.
                I managed the team, organization didn't emerged and in later sprints the
                team was not more
                cohesive and the productivity was "normal". I think I missed the point:
                a lack of values can't be
                avoided introducing new practices, this led to a sort of control that
                hindered collaboration.

                I think the team should collaborate as it was one single organism. To
                show the difference between
                productivity (or other metrics) don't help the team to be more cohesive.
                They know what is going on. We, as ScrumMasters, should help them to
                work better and not to
                show them they don't do it, (imho). This is the hard part of the Scrum
                method, the tacit knowledge that
                Ken cannot to teach us at the certification classes or in his books.

                What do you think about it?

                Maurizio


                Deb ha scritto:

                > I guess I'm responding to different aspects of this post in a couple
                > of sub-threads...
                >
                > Dave, just to be clear, how do you see the Individual Burndown as a
                > way to track performance? It seems to be missing so much information
                > (that Scrum does not record) that it could only serve
                > to /misinterpret/ performance, and it seems to me that the people
                > using it would know that... but maybe you are seeing something
                > different?
                >
                > deb
                >
                > PS: people are not necessarily responding to the Individual Burndown
                > aspect, are they? There are a bunch of worksheets there... My
                > assumption is: if you are using XP then the Indiv Burndown is
                > probably extraneous.
                >
                >
                >
                > --- In scrumdevelopment@yahoogroups.com, David A Barrett
                > <dave.barrett@l...> wrote:
                > >
                > >
                > >
                > >
                > > Ok, so now I'm a little worried.
                > >
                > > The more I think about it, the less comfortable I am with Deb's
                > spreadsheet
                > > and the way it focuses on the individuals' performance. This
                > clashes
                > > totally with what I perceived to be key component of the Scrum
                > methodology;
                > > the team aspect.
                > >
                > > In the ScrumMaster course, Ken made a point about ensuring that the
                > daily
                > > scrums were about the team members reporting to each other. He
                > advised
                > > doing things like avoiding eye contact with the team members in
                > order to
                > > avoid having them report *to* the scrummaster. I can think of
                > numerous
                > > other examples where he went out of his way to stress that the
                > > scrummaster's role was *not* to organize and control the team's
                > activities.
                > > The chicken and pig concept, which seems to be a pillar of the
                > methodology,
                > > puts the emphasis on the team and shared goals.
                > >
                > > So why am I worried? Well Deb puts up the spreadsheet which
                > appears to
                > > shift the focus from teamwork back onto individually managed people
                > with
                > > individual goals which are (probably) assigned by management, and
                > the next
                > > thing we see on this list are a whole bunch of posts from people
                > saying
                > > they think this is really cool. So then I wonder if people are
                > looking at
                > > this and saying to themselves, "Hey, this is the missing link! I
                > can
                > > implement Scrum while still keeping my subordinates directly
                > accountable to
                > > myself, and I can maintain control on an individual basis".
                > >
                > > Now the last thing I want to be is dogmatic, but I'm thinking that
                > if you
                > > are managing your team with this spreadsheet (and the management
                > style that
                > > it implies) then it's not Scrum anymore. It may be effective, it
                > may
                > > support iterative and incemental, but it's not Scrum. If it's not
                > Scrum,
                > > what does that mean?
                > >
                > > Perhaps if Mike or Ken could step in at this time and express an
                > opinion it
                > > would help to clarify this for me.
                > >
                > >
                > > Dave Barrett,
                > > Lawyers' Professional Indemnity Company
                >
                >
                >
                > To Post a message, send it to: scrumdevelopment@...
                > To Unsubscribe, send a blank message to:
                > scrumdevelopment-unsubscribe@...
                >
                >
                > *Yahoo! Groups Sponsor*
                > ADVERTISEMENT
                > <http://rd.yahoo.com/SIG=129ul4nbh/M=295196.4901138.6071305.3001176/D=groups/S=1707209021:HM/EXP=1084466640/A=2128215/R=0/SIG=10se96mf6/*http://companion.yahoo.com>
                >
                >
                >
                > ------------------------------------------------------------------------
                > *Yahoo! Groups Links*
                >
                > * To visit your group on the web, go to:
                > http://groups.yahoo.com/group/scrumdevelopment/
                >
                > * To unsubscribe from this group, send an email to:
                > scrumdevelopment-unsubscribe@yahoogroups.com
                > <mailto:scrumdevelopment-unsubscribe@yahoogroups.com?subject=Unsubscribe>
                >
                > * Your use of Yahoo! Groups is subject to the Yahoo! Terms of
                > Service <http://docs.yahoo.com/info/terms/>.
                >
                >
              • Marco Abis
                Maurizio, ... this make a lot of sense to me! Marco Abis http://agilemovement.it - Italian Agile Movement http://www.agilityspi.com - Agility SPI :: Software
                Message 7 of 29 , May 13, 2004
                • 0 Attachment
                  Maurizio,

                  >a lack of values can't be avoided introducing new practices

                  this make a lot of sense to me!


                  Marco Abis
                  http://agilemovement.it - Italian Agile Movement
                  http://www.agilityspi.com - Agility SPI :: Software Process Improvement
                • Deb
                  makes sense to me too. however, still leaves the problem of load balancing when there are specialists on the team... I m still mulling this over. deb ...
                  Message 8 of 29 , May 13, 2004
                  • 0 Attachment
                    makes sense to me too.
                    however, still leaves the problem of load balancing when there are
                    specialists on the team...

                    I'm still mulling this over.
                    deb

                    --- In scrumdevelopment@yahoogroups.com, Marco Abis <abis@a...> wrote:
                    > Maurizio,
                    >
                    > >a lack of values can't be avoided introducing new practices
                    >
                    > this make a lot of sense to me!
                    >
                    >
                    > Marco Abis
                    > http://agilemovement.it - Italian Agile Movement
                    > http://www.agilityspi.com - Agility SPI :: Software Process
                    Improvement
                  • David A Barrett
                    ... What I meant by performance was the individuals contribution to the group burndown. ... I can t say it any better. Deb, You cite a case where your own
                    Message 9 of 29 , May 14, 2004
                    • 0 Attachment
                      From Deb:

                      > Dave, just to be clear, how do you see the Individual Burndown as a
                      > way to track performance? It seems to be missing so much information
                      > (that Scrum does not record) that it could only serve
                      > to /misinterpret/ performance

                      What I meant by "performance" was the individuals' contribution to the
                      group burndown.

                      From Maurizio:

                      >I think the team should collaborate as it was one single organism.

                      I can't say it any better.

                      Deb,

                      You cite a case where your own individual burndown helped you to do better.
                      Although I was really only being cheeky when I said, "Now, if the team
                      decides to track individual burndowns, that would be a different
                      matter...", I guess this really does fall into that category.

                      Could explain what the expected benefits or goals are from tracking
                      individual burndowns?

                      As to load balancing when there are specialists on a team. I have two
                      thoughts on this. The first is what Ken always stresses, that the pigs are
                      always committed to the team goals and no one says, "That's not my area so
                      I'm not going to help". We often have tasks which require some involvement
                      from a web designer, but we refuse to make him part of the team because his
                      skill set is too narrow to participate fully in the team goals as a pig.
                      We treat him as a resource, and the team's Business Analyst is usually the
                      one who keeps track of how he's doing and reports back to the team on his
                      progress. The Business Analyst, by the way, is the only team member who
                      can't program but she's also usually the only team member who actively
                      participates in every singe Sprint Backlog item each Sprint. Each of the
                      programmers have areas that only they can effectively work in, but these
                      areas are often only a small part of the overall work for a sprint. The
                      specialist parts of the specialist tasks are done (by necessity) by the
                      specialists, but other than that it gets spread around.

                      My second thought on load balancing is that it isn't up to the Scrum Master
                      to come up with a solution. It is the team's problem, and the team needs
                      to find a solution. Let the customer pick the goals, and let the team
                      figure out how to meet them. Even specialist based goals are going to have
                      areas, such as documentation and testing, which can be done by other people
                      so there's always some way to spread a task around. The key point is that
                      it is NOT possible for an individual to fail, but one of the goals isn't
                      met then the ENTIRE team has failed. If a case should come where Joe
                      Specialist was not able to complete a backlog item, the question to ask is,
                      "How did the team let that happen?"


                      Dave Barrett,
                      Lawyers' Professional Indemnity Company
                    • Kent J McDonald
                      Dave, A couple of questions about your first thought: 1) When you say that the web designer is not part of the team, could you describe how that works. From
                      Message 10 of 29 , May 15, 2004
                      • 0 Attachment
                        Dave, A couple of questions about your first thought:
                        1) When you say that the web designer is not part of the team, could you
                        describe how that works. From what you wrote about the BA, is it safe to
                        assume that the BA actually "volunteers" for the web designer-related tasks
                        and then works with the web designer to get them done?

                        2) What all does the BA do in your team? What granularity are your Sprint
                        Backlog items at? I'm trying to get a feel for how a Business Analyst fits
                        into a team using SCRUM.

                        Thanks,
                        --
                        Kent J. McDonald
                        kent@...
                        Master your instrument, master the music, and then forget all that and just
                        play. -- Charlie Parker


                        Quoting David A Barrett <dave.barrett@...>:

                        >
                        >
                        >
                        >
                        > From Deb:
                        >
                        > > Dave, just to be clear, how do you see the Individual Burndown as a
                        > > way to track performance? It seems to be missing so much information
                        > > (that Scrum does not record) that it could only serve
                        > > to /misinterpret/ performance
                        >
                        > What I meant by "performance" was the individuals' contribution to the
                        > group burndown.
                        >
                        > From Maurizio:
                        >
                        > >I think the team should collaborate as it was one single organism.
                        >
                        > I can't say it any better.
                        >
                        > Deb,
                        >
                        > You cite a case where your own individual burndown helped you to do better.
                        > Although I was really only being cheeky when I said, "Now, if the team
                        > decides to track individual burndowns, that would be a different
                        > matter...", I guess this really does fall into that category.
                        >
                        > Could explain what the expected benefits or goals are from tracking
                        > individual burndowns?
                        >
                        > As to load balancing when there are specialists on a team. I have two
                        > thoughts on this. The first is what Ken always stresses, that the pigs are
                        > always committed to the team goals and no one says, "That's not my area so
                        > I'm not going to help". We often have tasks which require some involvement
                        > from a web designer, but we refuse to make him part of the team because his
                        > skill set is too narrow to participate fully in the team goals as a pig.
                        > We treat him as a resource, and the team's Business Analyst is usually the
                        > one who keeps track of how he's doing and reports back to the team on his
                        > progress. The Business Analyst, by the way, is the only team member who
                        > can't program but she's also usually the only team member who actively
                        > participates in every singe Sprint Backlog item each Sprint. Each of the
                        > programmers have areas that only they can effectively work in, but these
                        > areas are often only a small part of the overall work for a sprint. The
                        > specialist parts of the specialist tasks are done (by necessity) by the
                        > specialists, but other than that it gets spread around.
                        >
                        > My second thought on load balancing is that it isn't up to the Scrum Master
                        > to come up with a solution. It is the team's problem, and the team needs
                        > to find a solution. Let the customer pick the goals, and let the team
                        > figure out how to meet them. Even specialist based goals are going to have
                        > areas, such as documentation and testing, which can be done by other people
                        > so there's always some way to spread a task around. The key point is that
                        > it is NOT possible for an individual to fail, but one of the goals isn't
                        > met then the ENTIRE team has failed. If a case should come where Joe
                        > Specialist was not able to complete a backlog item, the question to ask is,
                        > "How did the team let that happen?"
                        >
                        >
                        > Dave Barrett,
                        > Lawyers' Professional Indemnity Company
                        >
                        >
                        >
                        >
                        > To Post a message, send it to: scrumdevelopment@...
                        > To Unsubscribe, send a blank message to:
                        > scrumdevelopment-unsubscribe@...
                        > Yahoo! Groups Links
                        >
                        >
                        >
                        >
                        >
                        >


                        -------------------------------------------------
                        Mail sent from: 64.136.27.226
                      • David A Barrett
                        ... tasks ... fits ... 1) Yeah, that s pretty much how it works out. We treat the web designer like any other scarce resourse (like a video projector) and we
                        Message 11 of 29 , May 17, 2004
                        • 0 Attachment
                          >Dave, A couple of questions about your first thought:
                          >1) When you say that the web designer is not part of the team, could you
                          >describe how that works. From what you wrote about the BA, is it safe to
                          >assume that the BA actually "volunteers" for the web designer-related
                          tasks
                          >and then works with the web designer to get them done?
                          >
                          >2) What all does the BA do in your team? What granularity are your Sprint

                          >Backlog items at? I'm trying to get a feel for how a Business Analyst
                          fits
                          >into a team using SCRUM.

                          1) Yeah, that's pretty much how it works out. We treat the web designer
                          like any other scarce resourse (like a video projector) and we book him for
                          some time with his boss. It usually works out that the BA is one who
                          "volunteers" for the task, but it could be someone else if the task touches
                          on, but isn't completely web based, or if the BA is too busy.

                          2) We rate our SB items with 4 sizes: Tiny < 1 day; Small = 1 to 2 days;
                          Medium = 3 to 5 days; Big > 5 days. Each sprint is different but our
                          current sprint has 1 Very Big item (15 days) and 3 Medium Items and a
                          pantload of Small and Tiny items.

                          Usually, there are one or two Sprint Backlog items that the programmers are
                          right on top of and know intimately. For those items, the BA is bugging
                          the programmers early in the Sprint to review them with her so that she can
                          organize the testing. The remaining items all require some level of
                          investigative activity prior to programming, and she proactively gets on
                          top of those and makes sure that everyone understands what the issues are,
                          how we'll go about testing them, and if things are out of scope. She also
                          co-ordinates demo's and meeting with the users, and polices the "big
                          picture" aspect of the Sprint.


                          Dave Barrett,
                          Lawyers' Professional Indemnity Company
                        • Nick1616
                          I have a question. If you use one team for various projects, don t you have a serious context-switching problem? Every team member has to know every project
                          Message 12 of 29 , Jul 28 11:55 AM
                          • 0 Attachment
                            I have a question. If you use one team for various projects, don't you
                            have a serious context-switching problem? Every team member has to
                            know every project and they work on different projects and different
                            technologies.

                            Nicolas
                          • Bas Vodde
                            Hi Nick, If the whole team works on several projects then they might use one product backlog and one sprint backlog and then there is no difference for the
                            Message 13 of 29 , Jul 28 6:07 PM
                            • 0 Attachment
                              Hi Nick,

                              If the whole team works on several projects then they might use one
                              product backlog and one sprint backlog and then there is no difference
                              for the team members.

                              If they are totally separate, then, it might not be a good idea to do
                              multiple projects with the same people, so don't do it :)

                              Bas

                              Nick1616 wrote:
                              >
                              >
                              > I have a question. If you use one team for various projects, don't you
                              > have a serious context-switching problem? Every team member has to
                              > know every project and they work on different projects and different
                              > technologies.
                              >
                              > Nicolas
                              >
                              >
                            Your message has been successfully submitted and would be delivered to recipients shortly.