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

fragmented team with different technical skills

Expand Messages
  • Pascal Maugeri
    Hi I ve inherited a project that involves different technologies (eg. Java programming, C programming, C#, etc.). Each of the team members has a specialty
    Message 1 of 12 , Jul 28, 2009

      Hi

      I've inherited a project that involves different technologies (eg. Java programming, C programming, C#, etc.).

      Each of the team members has a "specialty" and is reluctant to work on another technology ...

      We could distribute the tasks to everybody based on the skills but most of the time the work effort is not the same for each technology: eg. during one iteration, there might be a lot of work in Java, little in C, and next iteration vice versa.

      Do you have any recommendation to deal with this kind of situation ?

      Regards,
      Pascal 
    • Xavier Quesada Allue
      Hi Pascal, This is the textbook risk of having a team of specialists. Faced with the obviousness of this situation, what does the team think? This is something
      Message 2 of 12 , Jul 28, 2009
        Hi Pascal,

        This is the textbook risk of having a team of specialists. Faced with the obviousness of this situation, what does the team think? This is something I would put forward to them to try to figure out.

        In my view, there are really only two solutions. Either people start cross-training in other technologies (for example by pair programming with the specialist); or you have to somehow rearrange and reprioritize the work so it comes in balanced. This second solution is a very bad one because not only it will imply wasteful overhead, it will also mean you are not prioritizing based only on business value.

        If you are very bold you can always try doing nothing for one iteration to see what the people who have no work decide to do.

        Saludos,
        Xavier

        PS: This is the reason why in Scrum we always recommend people become as cross-functional as possible.

        On Tue, Jul 28, 2009 at 9:16 AM, Pascal Maugeri <pascal.maugeri@...> wrote:
         


        Hi

        I've inherited a project that involves different technologies (eg. Java programming, C programming, C#, etc.).

        Each of the team members has a "specialty" and is reluctant to work on another technology ...

        We could distribute the tasks to everybody based on the skills but most of the time the work effort is not the same for each technology: eg. during one iteration, there might be a lot of work in Java, little in C, and next iteration vice versa.

        Do you have any recommendation to deal with this kind of situation ?

        Regards,
        Pascal 




        --
        Xavier Quesada Allue
        Visual Management Blog
        http://www.xqa.com.ar/visualmanagement

      • Roy Morien
        I would consider it to be highly unprofessional of a developer to refuse, or even be reluctant, to learn a new technology. However, what would be the cost to
        Message 3 of 12 , Jul 28, 2009
          I would consider it to be highly unprofessional of a developer to refuse, or even be reluctant, to learn a new technology.
           
          However, what would be the cost to train various 'specialists' in a new technology; cost in both time and money terms.
           
          It seems to me that this problem should have been seen as a project risk right up front, and the project manned more appropriately.
           
          Having said all that, I would assume from what you have said that that some of these 'specialists' might be a little under-worked during some sprints. Perhaps you can team them up with another 'specialist' in a different technology so that they can use their slack time usefully (unless they are too reluctant, that is). Pair programming for retraining purposes. That way they are more fully occupied in useful work.
           
          Is there any way you can 'smooth out' the development effort, and develop in parallel even during a sprint?
           
          I understand that you have inherited this mess, and are seeking the best way out of it. My best suggestion would be to try to develop in parallel, the various 'technology streams'. This would avoid the cost and time of retraining, the angst of retraining. I would further suggest that you try not to get into this predicament next time, in the middle of a project. :)
           
          Regards,
          Roy Morien

           

          To: scrumdevelopment@yahoogroups.com
          From: pascal.maugeri@...
          Date: Tue, 28 Jul 2009 09:16:08 +0200
          Subject: [scrumdevelopment] fragmented team with different technical skills

           

          Hi

          I've inherited a project that involves different technologies (eg. Java programming, C programming, C#, etc.).

          Each of the team members has a "specialty" and is reluctant to work on another technology ...

          We could distribute the tasks to everybody based on the skills but most of the time the work effort is not the same for each technology: eg. during one iteration, there might be a lot of work in Java, little in C, and next iteration vice versa.

          Do you have any recommendation to deal with this kind of situation ?

          Regards,
          Pascal 



          Web IM has arrived! Use Windows Live Messenger from your Hotmail inbox
        • George Dinwiddie
          ... Pascal, have you talked with the team members about this reluctance? When you do so, you might listen for what they re trying to preserve as they talk
          Message 4 of 12 , Jul 28, 2009
            Pascal Maugeri wrote:
            > I've inherited a project that involves different technologies (eg. Java
            > programming, C programming, C#, etc.).
            >
            > Each of the team members has a "specialty" and is reluctant to work on
            > another technology ...

            Pascal, have you talked with the team members about this reluctance?
            When you do so, you might listen for what they're trying to preserve as
            they talk about what they're avoiding. Dale Emery has written a lot of
            good material on "Resistance as a Resource" that you might find helpful.

            - George

            --
            ----------------------------------------------------------------------
            * George Dinwiddie * http://blog.gdinwiddie.com
            Software Development http://www.idiacomputing.com
            Consultant and Coach http://www.agilemaryland.org
            ----------------------------------------------------------------------
          • juan_banda
            From my experience I can say that it s times easier to learn Java or C# if you have a solid knowledge of C++ and C, the reverse is not always true. If you re a
            Message 5 of 12 , Jul 28, 2009
              From my experience I can say that it's times easier to learn Java or C# if you have a solid knowledge of C++ and C, the reverse is not always true.

              If you're a Java developer trying to learn your ways in C++ you're definitely going to have a hard time learning pointers and memory allocation. I'm not saying that it won't be possible to learn, I'm just bringing your attention to this.

              On the contrary, if you're luckily enough to have a core development team of C++/C developer I don't anticipate much of a trouble for team picking some Java and C#.

              In any case my recommendation would be cross-training and pair programming. But remember that good C++ are nothing something that you can mentor overnight.

              Just my two cents,

              Juan

              --- In scrumdevelopment@yahoogroups.com, Xavier Quesada Allue <xavier@...> wrote:
              >
              > Hi Pascal,
              >
              > This is the textbook risk of having a team of specialists. Faced with the
              > obviousness of this situation, what does the team think? This is something I
              > would put forward to them to try to figure out.
              >
              > In my view, there are really only two solutions. Either people start
              > cross-training in other technologies (for example by pair programming with
              > the specialist); or you have to somehow rearrange and reprioritize the work
              > so it comes in balanced. This second solution is a very bad one because not
              > only it will imply wasteful overhead, it will also mean you are not
              > prioritizing based only on business value.
              >
              > If you are very bold you can always try doing nothing for one iteration to
              > see what the people who have no work decide to do.
              >
              > Saludos,
              > Xavier
              >
              > PS: This is the reason why in Scrum we always recommend people become as
              > cross-functional as possible.
              >
              > On Tue, Jul 28, 2009 at 9:16 AM, Pascal Maugeri <pascal.maugeri@...>wrote:
              >
              > >
              > >
              > >
              > > Hi
              > >
              > > I've inherited a project that involves different technologies (eg. Java
              > > programming, C programming, C#, etc.).
              > >
              > > Each of the team members has a "specialty" and is reluctant to work on
              > > another technology ...
              > >
              > > We could distribute the tasks to everybody based on the skills but most of
              > > the time the work effort is not the same for each technology: eg. during one
              > > iteration, there might be a lot of work in Java, little in C, and next
              > > iteration vice versa.
              > >
              > > Do you have any recommendation to deal with this kind of situation ?
              > >
              > > Regards,
              > > Pascal
              > >
              > >
              >
              >
              >
              > --
              > Xavier Quesada Allue
              > Visual Management Blog
              > http://www.xqa.com.ar/visualmanagement
              >
            • Paul Oldfield
              (responding to Pascal) ... What George (Dinwiddie) said. And then... What might work is to give them a challenge, as a team. Say, for each team member to
              Message 6 of 12 , Jul 29, 2009
                (responding to Pascal)
                >
                > ...Each of the team members has a "specialty" and is reluctant
                > to work on another technology ...

                What George (Dinwiddie) said. And then...

                What might work is to give them a challenge, as a team. Say,
                for each team member to have worked on a target number (percentage
                may be better - harder to 'game' but more work to track) of
                tasks in each language. If the entire team meets their target
                then they get some reward. Of course, the main part of the reward
                is the respect and recognition they get for meeting the challenge...

                ...but a suitable token of appreciation always helps.

                For a bit of added fun, you could track progress toward the target
                weekly, using a "Big Visible Chart". I suggest set the end date several months away, and for 3 languages (assuming equal spread)
                have targets of a minimum 20% in each language.

                Paul Oldfield
                Capgemini
              • Pascal Maugeri
                Thanks for your answers! It is very very interesting. Unfortunately I could not manage, for this sprint, to have team members working on different tasks than
                Message 7 of 12 , Aug 6 1:18 AM
                  Thanks for your answers! It is very very interesting.

                  Unfortunately I could not manage, for this sprint, to have team members working on different tasks than their "specialities" :-/

                  But at least we have everybody with the same level of work effort. This is an acceptable situation for now but I agree with you this has to be improved.

                  My plan is to start smoothly in next sprints to do "cross assignations" of simple tasks (eg. Java specialist do a simple task of C implementation and vice versa), as I believe we can't change 1-year habits in a single overnight.

                  Cheers
                  Pascal


                  On Wed, Jul 29, 2009 at 9:03 AM, Paul Oldfield <PaulOldfield1@...> wrote:
                   

                  (responding to Pascal)
                  >
                  > ...Each of the team members has a "specialty" and is reluctant


                  > to work on another technology ...

                  What George (Dinwiddie) said. And then...

                  What might work is to give them a challenge, as a team. Say,
                  for each team member to have worked on a target number (percentage
                  may be better - harder to 'game' but more work to track) of
                  tasks in each language. If the entire team meets their target
                  then they get some reward. Of course, the main part of the reward
                  is the respect and recognition they get for meeting the challenge...

                  ...but a suitable token of appreciation always helps.

                  For a bit of added fun, you could track progress toward the target
                  weekly, using a "Big Visible Chart". I suggest set the end date several months away, and for 3 languages (assuming equal spread)
                  have targets of a minimum 20% in each language.

                  Paul Oldfield
                  Capgemini


                • victor oliveira
                  Pascal, just a warning here; maybe I got it wrong, but you used assignations on your e-mail. The team must own the tasks and they should decide how to do them.
                  Message 8 of 12 , Aug 6 7:15 AM
                    Pascal,

                       just a warning here; maybe I got it wrong, but you used assignations on your e-mail. The team must own the tasks and they should decide how to do them. So there is no assignation. In this sense, the whole team is assigned a bunch of items.
                       One thing that could get them thinking more on "crossing" is to suggest that they limit parallelism so that they will forcibly either be idle, or help each other out. In the daily scrum, reinforce that they need to figure out how to help each other...
                       Just saying...

                    Best Regards,
                    Victor Hugo de Oliveira

                    Scrum & Agile Blog
                    http://csvo.wordpress.com

                    Concrete Solutions
                    new edition: http://www.concretesolutions.com.br/index_eng/



                    On Thu, Aug 6, 2009 at 5:18 AM, Pascal Maugeri <pascal.maugeri@...> wrote:
                     

                    Thanks for your answers! It is very very interesting.

                    Unfortunately I could not manage, for this sprint, to have team members working on different tasks than their "specialities" :-/

                    But at least we have everybody with the same level of work effort. This is an acceptable situation for now but I agree with you this has to be improved.

                    My plan is to start smoothly in next sprints to do "cross assignations" of simple tasks (eg. Java specialist do a simple task of C implementation and vice versa), as I believe we can't change 1-year habits in a single overnight.

                    Cheers
                    Pascal




                    On Wed, Jul 29, 2009 at 9:03 AM, Paul Oldfield <PaulOldfield1@...> wrote:
                     

                    (responding to Pascal)
                    >
                    > ...Each of the team members has a "specialty" and is reluctant


                    > to work on another technology ...

                    What George (Dinwiddie) said. And then...

                    What might work is to give them a challenge, as a team. Say,
                    for each team member to have worked on a target number (percentage
                    may be better - harder to 'game' but more work to track) of
                    tasks in each language. If the entire team meets their target
                    then they get some reward. Of course, the main part of the reward
                    is the respect and recognition they get for meeting the challenge...

                    ...but a suitable token of appreciation always helps.

                    For a bit of added fun, you could track progress toward the target
                    weekly, using a "Big Visible Chart". I suggest set the end date several months away, and for 3 languages (assuming equal spread)
                    have targets of a minimum 20% in each language.

                    Paul Oldfield
                    Capgemini





                    --

                  • George Dinwiddie
                    ... Can you enlist the team s help in exploring and solving this problem? It sounds like you re taking ownership of it, which reduces the team s ownership. -
                    Message 9 of 12 , Aug 6 7:16 AM
                      Pascal Maugeri wrote:
                      > My plan is to start smoothly in next sprints to do "cross assignations"
                      > of simple tasks (eg. Java specialist do a simple task of C
                      > implementation and vice versa)

                      Can you enlist the team's help in exploring and solving this problem?
                      It sounds like you're taking ownership of it, which reduces the team's
                      ownership.

                      - George

                      --
                      ----------------------------------------------------------------------
                      * George Dinwiddie * http://blog.gdinwiddie.com
                      Software Development http://www.idiacomputing.com
                      Consultant and Coach http://www.agilemaryland.org
                      ----------------------------------------------------------------------
                    • Pascal Maugeri
                      Sorry I did not mean I assigned the tasks to team members, I asked everybody to accept all the tasks of the sprint backlog before starting the sprint and
                      Message 10 of 12 , Aug 6 9:22 AM

                        Sorry I did not mean "I" assigned the tasks to team members, I asked everybody to accept all the tasks of the sprint backlog before starting the sprint and make sure everybody was having an equal work effort.

                        I know this is not "scrum" compliant but as I said, my workmates have been used to work that way for almost a year. I exposed the problem an I saw it was not easy to change :-)

                        My plan for the next sprint is inviting the team to start to "diversify" accepting simple tasks of technology they don't (yet) master. Do you think it is fair? And I have started myself to get familiar with tech I don't know well...

                        Pascal  

                        On Aug 6, 2009 4:34 PM, "victor oliveira" <victor.oliveira@...> wrote:

                         

                        Pascal,


                           just a warning here; maybe I got it wrong, but you used assignations on your e-mail. The team must own the tasks and they should decide how to do them. So there is no assignation. In this sense, the whole team is assigned a bunch of items.
                           One thing that could get them thinking more on "crossing" is to suggest that they limit parallelism so that they will forcibly either be idle, or help each other out. In the daily scrum, reinforce that they need to figure out how to help each other...
                           Just saying...

                        Best Regards,
                        Victor Hugo de Oliveira

                        Scrum & Agile Blog
                        http://csvo.wordpress.com

                        Concrete Solutions
                        new edition: http://www.concretesolutions.com.br/index_eng/

                        On Thu, Aug 6, 2009 at 5:18 AM, Pascal Maugeri <pascal.maugeri@...> wrote: > >   > > Thanks ...

                      • victor oliveira
                        Pascal, yours may be a good suggestion and work well for them. Just to add to this, raise to them your concerns on the whole team concept, and let them
                        Message 11 of 12 , Aug 6 11:35 AM
                          Pascal,

                             yours may be a good suggestion and work well for them. Just to add to this, raise to them your concerns on the "whole team" concept, and let them suggest as well how to work better together. It may surprise you, and have a bonus of giving them the ownership of the improvement and the work.

                          Best Regards,
                          Victor Hugo de Oliveira

                          Scrum & Agile Blog
                          http://csvo.wordpress.com

                          Concrete Solutions
                          new edition: http://www.concretesolutions.com.br/index_eng/

                          On Thu, Aug 6, 2009 at 1:22 PM, Pascal Maugeri <pascal.maugeri@...> wrote:
                           

                          Sorry I did not mean "I" assigned the tasks to team members, I asked everybody to accept all the tasks of the sprint backlog before starting the sprint and make sure everybody was having an equal work effort.

                          I know this is not "scrum" compliant but as I said, my workmates have been used to work that way for almost a year. I exposed the problem an I saw it was not easy to change :-)

                          My plan for the next sprint is inviting the team to start to "diversify" accepting simple tasks of technology they don't (yet) master. Do you think it is fair? And I have started myself to get familiar with tech I don't know well...

                          Pascal  

                          On Aug 6, 2009 4:34 PM, "victor oliveira" <victor.oliveira@...> wrote:

                           

                          Pascal,

                             just a warning here; maybe I got it wrong, but you used assignations on your e-mail. The team must own the tasks and they should decide how to do them. So there is no assignation. In this sense, the whole team is assigned a bunch of items.
                             One thing that could get them thinking more on "crossing" is to suggest that they limit parallelism so that they will forcibly either be idle, or help each other out. In the daily scrum, reinforce that they need to figure out how to help each other...
                             Just saying...

                          Best Regards,
                          Victor Hugo de Oliveira

                          Scrum & Agile Blog
                          http://csvo.wordpress.com

                          Concrete Solutions
                          new edition: http://www.concretesolutions.com.br/index_eng/

                          On Thu, Aug 6, 2009 at 5:18 AM, Pascal Maugeri <pascal.maugeri@...> wrote: > >   > > Thanks ...




                          --

                        • sschuermann303
                          Sorry to tell you that this might not work ... The team manges to do that not you. There is the prime directive that helps you with that. Secondly you just get
                          Message 12 of 12 , Aug 7 4:46 PM
                            Sorry to tell you that this might not work

                            > Unfortunately I could not manage, for this sprint, to have team members
                            > working on different tasks than their "specialities" :-/

                            The team manges to do that not you. There is the prime directive that helps you with that. Secondly you just get one or two tasks into the "in progress state", this might get the thing solved.

                            >
                            > My plan is to start smoothly in next sprints to do "cross assignations" of
                            > simple tasks (eg. Java specialist do a simple task of C implementation and
                            > vice versa), as I believe we can't change 1-year habits in a single
                            > overnight.

                            Lots of writing about you, I, Me. It's about what this team does and think. Better just apply the rule that a minimum set of tasks get into progress and people will work on stuff as teams.
                            Your timeline is correct anyways. As soon as people find out how much faster things really get done, they will do pairing anyways.


                            Sebastian


                            --- In scrumdevelopment@yahoogroups.com, Pascal Maugeri <pascal.maugeri@...> wrote:
                            >
                            > Thanks for your answers! It is very very interesting.
                            >

                            >
                            > But at least we have everybody with the same level of work effort. This is
                            > an acceptable situation for now but I agree with you this has to be
                            > improved.
                            >
                            > My plan is to start smoothly in next sprints to do "cross assignations" of
                            > simple tasks (eg. Java specialist do a simple task of C implementation and
                            > vice versa), as I believe we can't change 1-year habits in a single
                            > overnight.
                            >
                            > Cheers
                            > Pascal
                            >
                            >
                            > On Wed, Jul 29, 2009 at 9:03 AM, Paul Oldfield <PaulOldfield1@...>wrote:
                            >
                            > >
                            > >
                            > > (responding to Pascal)
                            > > >
                            > > > ...Each of the team members has a "specialty" and is reluctant
                            > >
                            > > > to work on another technology ...
                            > >
                            > > What George (Dinwiddie) said. And then...
                            > >
                            > > What might work is to give them a challenge, as a team. Say,
                            > > for each team member to have worked on a target number (percentage
                            > > may be better - harder to 'game' but more work to track) of
                            > > tasks in each language. If the entire team meets their target
                            > > then they get some reward. Of course, the main part of the reward
                            > > is the respect and recognition they get for meeting the challenge...
                            > >
                            > > ...but a suitable token of appreciation always helps.
                            > >
                            > > For a bit of added fun, you could track progress toward the target
                            > > weekly, using a "Big Visible Chart". I suggest set the end date several
                            > > months away, and for 3 languages (assuming equal spread)
                            > > have targets of a minimum 20% in each language.
                            > >
                            > > Paul Oldfield
                            > > Capgemini
                            > >
                            > >
                            > >
                            >
                          Your message has been successfully submitted and would be delivered to recipients shortly.