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

How to distribute engineers among project teams

Expand Messages
  • Sam Edwards
    I work for a company that typically has 5-10 projects going on simultaneously, some very short (a week or two), some quite long (up to a year). I like the
    Message 1 of 5 , Nov 2, 2005
    • 0 Attachment

      I work for a company that typically has 5-10 projects going on simultaneously, some very short (a week or two), some quite long (up to a year).  I like the team concept of Agile, but find it is difficult to keep the same people on the same project team for the full course of a project.  Sometimes a new, higher-priority project comes along, or sometimes an existing project discovers it needs expertise only found in a member of a different project.  How do you minimize the disruption that naturally occurs when people are forced to switch projects?  A second question: is it acceptable to have the same person a member of more than one project?  If so, does that person then commit to a certain amount of time for each project?

       

      Thanks in advance for your advice.

    • Keith Sader
      ... It sounds like you could use a scrum of scrums, but one thing at a time. ... Task switching considered harmful - for humans:
      Message 2 of 5 , Nov 2, 2005
      • 0 Attachment
        > I work for a company that typically has 5-10 projects going on
        > simultaneously, some very short (a week or two), some quite long (up to a
        > year).

        It sounds like you could use a scrum of scrums, but one thing at a time.

        >I like the team concept of Agile, but find it is difficult to keep
        > the same people on the same project team for the full course of a project.
        > Sometimes a new, higher-priority project comes along, or sometimes an
        > existing project discovers it needs expertise only found in a member of a
        > different project. How do you minimize the disruption that naturally occurs
        > when people are forced to switch projects?

        Task switching considered harmful - for humans:

        http://www.joelonsoftware.com/articles/fog0000000022.html

        > A second question: is it
        > acceptable to have the same person a member of more than one project? If
        > so, does that person then commit to a certain amount of time for each
        > project?

        See above.

        hth,
        --
        Keith Sader
        ksader@...
        http://www.saderfamily.org/roller/page/ksader
        http://www.jroller.com/page/certifieddanger
      • Steven Gordon
        ... One way to minimize disruptions in the long run is to use pair programming to crosstrain your engineers to learn each other s expertises (so that there
        Message 3 of 5 , Nov 2, 2005
        • 0 Attachment
          On 11/2/05, Sam Edwards <sedwards@...> wrote:

          I work for a company that typically has 5-10 projects going on simultaneously, some very short (a week or two), some quite long (up to a year).  I like the team concept of Agile, but find it is difficult to keep the same people on the same project team for the full course of a project.  Sometimes a new, higher-priority project comes along, or sometimes an existing project discovers it needs expertise only found in a member of a different project.  How do you minimize the disruption that naturally occurs when people are forced to switch projects?

           
          One way to minimize disruptions in the long run is to use pair programming to crosstrain your engineers to learn each other's expertises (so that there will be no expertise only found in one engineer).
           
          Another way is to only allow interuptions to teams at sprint boundaries.  If 1 month sprints make this impractical, then that would be impetus to move to 1 or 2 week sprints. 
           
          I would suggest having a small, fixed number of teams and when a new, hotter project comes along, suspend the project that one team is working on, apply that whole team to the new project, and then bring the same team back to continue the suspended project (as opposed to having both projects limp along at the same time).  Having only a few projects going at the same time will force the company to prioritize, focus, and finish projects fast enough to start the projects that are waiting.
           
          All easier said than done in the context of an existing business culture.
           

            A second question: is it acceptable to have the same person a member of more than one project?  If so, does that person then commit to a certain amount of time for each project?

           

          This is not recommended.  It dilutes focus and agility.
           

          Thanks in advance for your advice.


        • Arun Batchu
          Perhaps you are talking about a Matrix ed organization taking fungibility of resources to the extreme, treating human resources as CPU resources. It is my
          Message 4 of 5 , Nov 2, 2005
          • 0 Attachment
            Perhaps you are talking about a Matrix'ed organization taking fungibility of resources to the extreme, treating human "resources" as CPU resources. It is my take that it is almost next to impossible to utilize scrum . Scrum is an ecosystem, take away a few of the supporting ideas/principles/and practices, you will have a degenerate system that will not work.

            You should get hold of Slack, by Tom DeMarco who writes very convincingly about the cost of task switching.

            However, there might be a few people in this community who might have attempted /failed/passed Scrum in a matrixed environment run by Taylorist efficiency experts.

            -Arun.

            On 11/2/05, Sam Edwards <sedwards@...> wrote:

            I work for a company that typically has 5-10 projects going on simultaneously, some very short (a week or two), some quite long (up to a year).  I like the team concept of Agile, but find it is difficult to keep the same people on the same project team for the full course of a project.  Sometimes a new, higher-priority project comes along, or sometimes an existing project discovers it needs expertise only found in a member of a different project.  How do you minimize the disruption that naturally occurs when people are forced to switch projects?  A second question: is it acceptable to have the same person a member of more than one project?  If so, does that person then commit to a certain amount of time for each project?

             

            Thanks in advance for your advice.



            To Post a message, send it to:   scrumdevelopment@...
            To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...




            YAHOO! GROUPS LINKS






            --
            http://netrii.com - Your agent for limitless growth
          • Ron Jeffries
            ... If you re going to swap people, you re going to have disruption. That will cost all the projects in terms of delay and bugs. If that s what your company
            Message 5 of 5 , Nov 2, 2005
            • 0 Attachment
              On Wednesday, November 2, 2005, at 10:42:19 AM, Sam Edwards wrote:

              > I work for a company that typically has 5-10 projects going on
              > simultaneously, some very short (a week or two), some quite long (up to
              > a year). I like the team concept of Agile, but find it is difficult to
              > keep the same people on the same project team for the full course of a
              > project. Sometimes a new, higher-priority project comes along, or
              > sometimes an existing project discovers it needs expertise only found in
              > a member of a different project. How do you minimize the disruption
              > that naturally occurs when people are forced to switch projects? A
              > second question: is it acceptable to have the same person a member of
              > more than one project? If so, does that person then commit to a certain
              > amount of time for each project?

              If you're going to swap people, you're going to have disruption.
              That will cost all the projects in terms of delay and bugs. If
              that's what your company wants, by all means keep doing it.

              To minimize the problems when new people show up, pair programming
              is a very useful technique.

              Ron Jeffries
              www.XProgramming.com
              Just because XP doesn't talk about how to make fire, should we assume it
              requires us to use sticks? -- Richard MacDonald
            Your message has been successfully submitted and would be delivered to recipients shortly.