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

Re: Estimating When Several Platforms Are Involved

Expand Messages
  • Tobias Mayer
    Hi Phil, Before I offer any further suggestions it would be good to know a little more context. Are the team co-located in a single shared workspace? (If not,
    Message 1 of 24 , Mar 1, 2008
      Hi Phil,

      Before I offer any further suggestions it would be good to know a little
      more context.

      Are the team co-located in a single shared workspace?
      (If not, what is the workplace configuration)
      Does the team do test-first development?
      Does the team use pair-programming?
      How long are your iterations?
      Are you the Scrum Master?

      One thing that comes to mind is a CSP application I read yesterday. The
      applicant talked about how difficult it was to find good testers in his
      part of the world. They eventually gave up and decided the developers
      would have to do their own testing. The was resistance; none of the
      developers had testing experience, and they felt it was below them (an
      odd software myth) but once they realized that without doing it the
      product would suck, they started in. Eventually not only were they
      doing well with it but actually came to enjoy it -- they saw it as a new
      challenge. The point is people sometimes don't know what they'll enjoy
      or be good at until they have the opportuity to find out. Perhaps
      Oracle guy has hidden artistic talents.

      Anyway, a little more context would help people on this list offer more
      ideas. Thanks.

      Tobias


      --- In scrumdevelopment@yahoogroups.com, Phil Shrimpton <phil@...>
      wrote:
      >
      > Hi,
      >
      > > In situations like the one you describe the team coach, or scrum
      master
      > > needs to encourage those who believe they are 'done' (they are not
      done,
      > > in fact as no one is done until the story is done) to find ways of
      > > supporting the ones who still have work. This could be in pairing,
      > > writing customer acceptance tests, or simply acting as team gophers.
      > > They do whatever it takes. In the longer term you'll want to find
      ways
      > > that team members can better understand each others' work so they
      are
      > > able to step in and support as required.
      >
      > This is what I am having problems with. Our systems are made up of
      three distinct technology platforms, and when hiring staff we have gone
      for quality over quantity, so all members of the team have between 8 and
      12 years + of experience of their respective 'technologies'.
      >
      > The team has been working together for a number of years and each
      person does have a good understanding (and respect) of what is involved
      it the others work. What I can't see happening is saying to my
      (expensive) Oracle DBA of 12 years, "There is not enough Oracle work for
      you this sprint, but Fred is struggling to get all the Icon sets done,
      can you help him draw some pictures", or saying to our experienced UI
      people "There are no screens to do, but Billy needs some help creating a
      distributed message queue with shared cache".
      >
      > The make up of the team is such that over the lifetime of a project
      there is enough work in each of their areas to keep them busy 'full
      time', I just can't see how getting people to do 'other peoples' work is
      not going to affect productivity and costs. The UI guys are some of the
      best I have ever worked with and I have a lot of respect for them, but I
      probably would not let them anywhere near the backend code, and even if
      I did it would take them 10 times longer than the 'backend developers'.
      >
      > I can certainly see how the cross-functional could work with a more
      general team of less experienced developers who are used to doing a 'bit
      of everything', its working with a team of experts on a project with a
      diverse technology mix is what I am struggling with.
      >
      > Phil
      >
    • woynam
      ... master ... done, ... ways ... three distinct technology platforms, and when hiring staff we have gone for quality over quantity, so all members of the team
      Message 2 of 24 , Mar 3, 2008
        --- In scrumdevelopment@yahoogroups.com, Phil Shrimpton <phil@...> wrote:
        >
        > Hi,
        >
        > > In situations like the one you describe the team coach, or scrum
        master
        > > needs to encourage those who believe they are 'done' (they are not
        done,
        > > in fact as no one is done until the story is done) to find ways of
        > > supporting the ones who still have work. This could be in pairing,
        > > writing customer acceptance tests, or simply acting as team gophers.
        > > They do whatever it takes. In the longer term you'll want to find
        ways
        > > that team members can better understand each others' work so they are
        > > able to step in and support as required.
        >
        > This is what I am having problems with. Our systems are made up of
        three distinct technology platforms, and when hiring staff we have
        gone for quality over quantity, so all members of the team have
        between 8 and 12 years + of experience of their respective 'technologies'.
        >
        > The team has been working together for a number of years and each
        person does have a good understanding (and respect) of what is
        involved it the others work. What I can't see happening is saying to
        my (expensive) Oracle DBA of 12 years, "There is not enough Oracle
        work for you this sprint, but Fred is struggling to get all the Icon
        sets done, can you help him draw some pictures", or saying to our
        experienced UI people "There are no screens to do, but Billy needs
        some help creating a distributed message queue with shared cache".
        >
        > The make up of the team is such that over the lifetime of a project
        there is enough work in each of their areas to keep them busy 'full
        time', I just can't see how getting people to do 'other peoples' work
        is not going to affect productivity and costs. The UI guys are some of
        the best I have ever worked with and I have a lot of respect for them,
        but I probably would not let them anywhere near the backend code, and
        even if I did it would take them 10 times longer than the 'backend
        developers'.

        Well, the first time they might take 10 times longer. However, isn't
        this better than having nobody work on the backend code? The next time
        their needed, perhaps it'll only take 3 times as long, and then twice
        as long. How is this any different than having a junior developer in
        the backend group? If people are willing to step up and help out,
        they're going to need training, which will take time. Yes, it may be
        less productive initially, but in the long run you'll have a much more
        productive group.

        The key, though, is that it's not "other people's work". It's the
        *team's* work. If you can't get over this hurdle, then you'll never
        experience the full benefit of agile development.

        >
        > I can certainly see how the cross-functional could work with a more
        general team of less experienced developers who are used to doing a
        'bit of everything', its working with a team of experts on a project
        with a diverse technology mix is what I am struggling with.

        I don't see your point. A more experienced developer should have no
        problem picking up new skills. That's how they got to be experienced.
        It sounds like the organization has encouraged specialization, so it's
        no surprise that developers may not want to expand their skillset. Is
        there a reward for learning new skills, or more likely, is there risk
        that they'll be called on the carpet for "taking so long"?

        >
        > Phil
        >
      • Phil Shrimpton
        Tobias ... Yes, we all sit around the same group of desks. ... Absolutely. Been doing XP for a good number of years, with good success. Wanted to bring the
        Message 3 of 24 , Mar 3, 2008
          Tobias

          > Before I offer any further suggestions it would be good to know a little
          > more context.
          >
          > Are the team co-located in a single shared workspace?

          Yes, we all sit around the same group of desks.

          > Does the team do test-first development?

          Absolutely. Been doing 'XP' for a good number of years, with good success. Wanted to bring the success we were having at a development level to a 'project' level, and SCRUM seemed the natural option.

          > Does the team use pair-programming?

          No. Does not work for us, although it is very common for 2 or more of us to be working on the same feature/code and that involves almost constant conversation and pointing out mistakes/additions etc. Its like pair programming, but everyone has their own workstation.

          > How long are your iterations?

          4 weeks.

          > Are you the Scrum Master?

          No, but I am working closely with the SM on 'SCRUM adoption and adaption' matters.

          > The point is people sometimes don't know what they'll enjoy
          > or be good at until they have the opportuity to find out. Perhaps
          > Oracle guy has hidden artistic talents.

          Maybe he has, maybe he hasn't, but he is an Oracle guy with 12+ years experience and a salary to match, we don't want him colouring in pictures, we want doing the Oracle stuff :-)

          Phil
        • Phil Shrimpton
          Hi, ... Not really. Firstly, it is going to mess up the estimates, the real backend guys might of estimated the work for a story at 5 days, but if the
          Message 4 of 24 , Mar 3, 2008
            Hi,

            >> The make up of the team is such that over the lifetime of a project
            >> there is enough work in each of their areas to keep them busy 'full
            >> time', I just can't see how getting people to do 'other peoples' work
            >> is not going to affect productivity and costs. The UI guys are some of
            >> the best I have ever worked with and I have a lot of respect for them,
            >> but I probably would not let them anywhere near the backend code, and
            >> even if I did it would take them 10 times longer than the 'backend
            >> developers'.
            >
            > Well, the first time they might take 10 times longer. However, isn't
            > this better than having nobody work on the backend code?

            Not really. Firstly, it is going to mess up the estimates, the 'real' backend guys might of estimated the work for a story at 5 days, but if the non-backend guys were to do it and it takes them 10 times longer, thats gone from 25% of a sprint, to 2.5 sprints! Secondly, the 'real' backend guys would need to spend time training and mentoring the 'new guys' as well as code reviews and rework, so will be spending less time doing what they are doing.

            > The next time
            > their needed, perhaps it'll only take 3 times as long, and then twice
            > as long.

            It would, eventually, maybe over the course of years, even the best developer can't go from zero experience of something to the equivalent of 8 years + experience in a few iterations.

            > How is this any different than having a junior developer in
            > the backend group?

            Its not, thats why we don't hire junior developers :-).

            > If people are willing to step up and help out,
            > they're going to need training, which will take time. Yes, it may be
            > less productive initially, but in the long run you'll have a much more
            > productive group.

            This is where I start to struggle. We have a very productive group at the moment, to bring everyones skill set in 'other' technologies up to the same level as every one elses will take years, and in the meantime will have a massive impact on productivity.

            > The key, though, is that it's not "other people's work". It's the
            > *team's* work.

            I 100% agree that the work is the 'teams' work, and every one takes collective responsibility for it as a whole, its just that different people do different bits.

            > If you can't get over this hurdle, then you'll never
            > experience the full benefit of agile development.

            Its not really a hurdle we want to get over (or probably can get over). Its not really caused too much of a problem up till now, but we have had to do 2 to 3 different 'estimates' for each story for each 'skill set' to help sprint planning so as not to have too much/less work for one skill set. Its not as bad as it sounds, the 'worst' its has been is having to push a couple of stories down the backlog, and promoting one or two, but in most cases 90% of the stories we do each sprint is from the 'top of the list'.

            >> I can certainly see how the cross-functional could work with a more
            >> general team of less experienced developers who are used to doing a
            >> 'bit of everything', its working with a team of experts on a project
            >> with a diverse technology mix is what I am struggling with.
            >
            > I don't see your point. A more experienced developer should have no
            > problem picking up new skills. That's how they got to be experienced.

            I agree, but we don't take on people with 8-12 years experience in their particular skill set to spend a few years learning a completely different one from scratch, might as well hire some junior developers.

            > It sounds like the organization has encouraged specialization,

            We have not encouraged it, its been deliberate and very successful.

            > so it's
            > no surprise that developers may not want to expand their skillset.

            Its not really the developers that don't want to expand there skill set, its the company that wants to use the developers to work on stuff they have the skills and experience to do.

            > Is
            > there a reward for learning new skills, or more likely, is there risk
            > that they'll be called on the carpet for "taking so long"?

            Neither, we just want to use everyones skills in the best and most productive way.

            To put it another way, I am currently having some building work done on my house and I have a 'team' in to do it. That 'team' consists of qualified plumbers, electricians, plasterers etc, each doing there 'own work'. I don't see the electrician doing a bit of plumbing one week, and the plasterer fitting a few lights the next. They are a self organizing team. If the plasterer can get on with one task because he is waiting for the plumber to do some work first, he does not do the plumbers work for him, he re-prioritises his 'backlog' and does something else. This is not a great deal different to our team setup, and I am sure we are not unique in this.

            Phil
          • Dmitry Beransky
            Phil, I went back and re-read your original question to make sure I didn t miss anything. I don t think I have, so I have to ask: why are you switching to
            Message 5 of 24 , Mar 3, 2008
              Phil,

              I went back and re-read your original question to make sure I didn't
              miss anything. I don't think I have, so I have to ask: why are you
              switching to Scrum. From your own statements, it seems that the
              current process/environment has been working for your organization
              just fine. You are reasonably happy with it and it seems to be
              producing results. Are you changing to Scrum just for the same of
              change? Because we can give you many reasons and recommendations on
              what to do, but at the end of the day if our recommendations aren't
              fixing concrete problems, your management (and you too) will keep
              dismissing them as unnecessary (and I can't blame them).

              I think it was Karl Marx who defined the revolutionary situation as
              where the ruling class is no longer able to rule in the old way, and
              the exploited are no longer willing to be ruled in the old way.
              Substitute "the ruling class" with "management" and "exploited" with
              developers/engineers, and you get the perfect definition of a
              situation which is be best for introducing Scrum/Agile into a company.
              Are you in that situation?


              Regards
              Dmitry

              On Mon, Mar 3, 2008 at 1:42 PM, Phil Shrimpton <phil@...> wrote:
              >
              >
              >
              >
              > Hi,
              >
              > >> The make up of the team is such that over the lifetime of a project
              > >> there is enough work in each of their areas to keep them busy 'full
              > >> time', I just can't see how getting people to do 'other peoples' work
              > >> is not going to affect productivity and costs. The UI guys are some of
              > >> the best I have ever worked with and I have a lot of respect for them,
              > >> but I probably would not let them anywhere near the backend code, and
              > >> even if I did it would take them 10 times longer than the 'backend
              > >> developers'.
              > >
              > > Well, the first time they might take 10 times longer. However, isn't
              > > this better than having nobody work on the backend code?
              >
              > Not really. Firstly, it is going to mess up the estimates, the 'real'
              > backend guys might of estimated the work for a story at 5 days, but if the
              > non-backend guys were to do it and it takes them 10 times longer, thats gone
              > from 25% of a sprint, to 2.5 sprints! Secondly, the 'real' backend guys
              > would need to spend time training and mentoring the 'new guys' as well as
              > code reviews and rework, so will be spending less time doing what they are
              > doing.
              >
              > > The next time
              > > their needed, perhaps it'll only take 3 times as long, and then twice
              > > as long.
              >
              > It would, eventually, maybe over the course of years, even the best
              > developer can't go from zero experience of something to the equivalent of 8
              > years + experience in a few iterations.
              >
              > > How is this any different than having a junior developer in
              > > the backend group?
              >
              > Its not, thats why we don't hire junior developers :-).
              >
              > > If people are willing to step up and help out,
              > > they're going to need training, which will take time. Yes, it may be
              > > less productive initially, but in the long run you'll have a much more
              > > productive group.
              >
              > This is where I start to struggle. We have a very productive group at the
              > moment, to bring everyones skill set in 'other' technologies up to the same
              > level as every one elses will take years, and in the meantime will have a
              > massive impact on productivity.
              >
              > > The key, though, is that it's not "other people's work". It's the
              > > *team's* work.
              >
              > I 100% agree that the work is the 'teams' work, and every one takes
              > collective responsibility for it as a whole, its just that different people
              > do different bits.
              >
              > > If you can't get over this hurdle, then you'll never
              > > experience the full benefit of agile development.
              >
              > Its not really a hurdle we want to get over (or probably can get over). Its
              > not really caused too much of a problem up till now, but we have had to do 2
              > to 3 different 'estimates' for each story for each 'skill set' to help
              > sprint planning so as not to have too much/less work for one skill set. Its
              > not as bad as it sounds, the 'worst' its has been is having to push a couple
              > of stories down the backlog, and promoting one or two, but in most cases 90%
              > of the stories we do each sprint is from the 'top of the list'.
              >
              > >> I can certainly see how the cross-functional could work with a more
              > >> general team of less experienced developers who are used to doing a
              > >> 'bit of everything', its working with a team of experts on a project
              > >> with a diverse technology mix is what I am struggling with.
              > >
              > > I don't see your point. A more experienced developer should have no
              > > problem picking up new skills. That's how they got to be experienced.
              >
              > I agree, but we don't take on people with 8-12 years experience in their
              > particular skill set to spend a few years learning a completely different
              > one from scratch, might as well hire some junior developers.
              >
              > > It sounds like the organization has encouraged specialization,
              >
              > We have not encouraged it, its been deliberate and very successful.
              >
              > > so it's
              > > no surprise that developers may not want to expand their skillset.
              >
              > Its not really the developers that don't want to expand there skill set, its
              > the company that wants to use the developers to work on stuff they have the
              > skills and experience to do.
              >
              > > Is
              > > there a reward for learning new skills, or more likely, is there risk
              > > that they'll be called on the carpet for "taking so long"?
              >
              > Neither, we just want to use everyones skills in the best and most
              > productive way.
              >
              > To put it another way, I am currently having some building work done on my
              > house and I have a 'team' in to do it. That 'team' consists of qualified
              > plumbers, electricians, plasterers etc, each doing there 'own work'. I don't
              > see the electrician doing a bit of plumbing one week, and the plasterer
              > fitting a few lights the next. They are a self organizing team. If the
              > plasterer can get on with one task because he is waiting for the plumber to
              > do some work first, he does not do the plumbers work for him, he
              > re-prioritises his 'backlog' and does something else. This is not a great
              > deal different to our team setup, and I am sure we are not unique in this.
              >
              > Phil
              >
            • Ken Schwaber
              Well done. Think of waterfall as being similar in concept to the old USSR central planning of the economy. Think of Scrum as similar to a market economy. Ken
              Message 6 of 24 , Mar 3, 2008

                Well done. Think of waterfall as being similar in concept to the old USSR central planning of the economy. Think of Scrum as similar to a market economy.

                Ken

                 


                From: scrumdevelopment@yahoogroups.com [mailto: scrumdevelopment@yahoogroups.com ] On Behalf Of Dmitry Beransky
                Sent: Monday, March 03, 2008 5:01 PM
                To: scrumdevelopment@yahoogroups.com
                Subject: Re: [scrumdevelopment] Re: Estimating When Several Platforms Are Involved

                 

                Phil,

                I went back and re-read your original question to make sure I didn't
                miss anything. I don't think I have, so I have to ask: why are you
                switching to Scrum. From your own statements, it seems that the
                current process/environment has been working for your organization
                just fine. You are reasonably happy with it and it seems to be
                producing results. Are you changing to Scrum just for the same of
                change? Because we can give you many reasons and recommendations on
                what to do, but at the end of the day if our recommendations aren't
                fixing concrete problems, your management (and you too) will keep
                dismissing them as unnecessary (and I can't blame them).

                I think it was Karl Marx who defined the revolutionary situation as
                where the ruling class is no longer able to rule in the old way, and
                the exploited are no longer willing to be ruled in the old way.
                Substitute "the ruling class" with "management" and "exploited" with
                developers/engineer s, and you get the perfect definition of a
                situation which is be best for introducing Scrum/Agile into a company.
                Are you in that situation?

                Regards
                Dmitry

                On Mon, Mar 3, 2008 at 1:42 PM, Phil Shrimpton <phil@shrimpton. co.uk> wrote:

                >
                >
                >
                >
                > Hi,
                >
                > >> The make up of the team is such that over the lifetime of a
                project
                > >> there is enough work in each of their areas to keep them busy
                'full
                > >> time', I just can't see how getting people to do 'other peoples'
                work
                > >> is not going to affect productivity and costs. The UI guys are
                some of
                > >> the best I have ever worked with and I have a lot of respect for
                them,
                > >> but I probably would not let them anywhere near the backend code,
                and
                > >> even if I did it would take them 10 times longer than the
                'backend
                > >> developers'.
                > >
                > > Well, the first time they might take 10 times longer. However, isn't
                > > this better than having nobody work on the backend code?
                >
                > Not really. Firstly, it is going to mess up the estimates, the 'real'
                > backend guys might of estimated the work for a story at 5 days, but if the
                > non-backend guys were to do it and it takes them 10 times longer, thats
                gone
                > from 25% of a sprint, to 2.5 sprints! Secondly, the 'real' backend guys
                > would need to spend time training and mentoring the 'new guys' as well as
                > code reviews and rework, so will be spending less time doing what they are
                > doing.
                >
                > > The next time
                > > their needed, perhaps it'll only take 3 times as long, and then twice
                > > as long.
                >
                > It would, eventually, maybe over the course of years, even the best
                > developer can't go from zero experience of something to the equivalent of
                8
                > years + experience in a few iterations.
                >
                > > How is this any different than having a junior developer in
                > > the backend group?
                >
                > Its not, thats why we don't hire junior developers :-).
                >
                > > If people are willing to step up and help out,
                > > they're going to need training, which will take time. Yes, it may be
                > > less productive initially, but in the long run you'll have a much
                more
                > > productive group.
                >
                > This is where I start to struggle. We have a very productive group at the
                > moment, to bring everyones skill set in 'other' technologies up to the
                same
                > level as every one elses will take years, and in the meantime will have a
                > massive impact on productivity.
                >
                > > The key, though, is that it's not "other people's work".
                It's the
                > > *team's* work.
                >
                > I 100% agree that the work is the 'teams' work, and every one takes
                > collective responsibility for it as a whole, its just that different
                people
                > do different bits.
                >
                > > If you can't get over this hurdle, then you'll never
                > > experience the full benefit of agile development.
                >
                > Its not really a hurdle we want to get over (or probably can get over).
                Its
                > not really caused too much of a problem up till now, but we have had to do
                2
                > to 3 different 'estimates' for each story for each 'skill set' to help
                > sprint planning so as not to have too much/less work for one skill set.
                Its
                > not as bad as it sounds, the 'worst' its has been is having to push a
                couple
                > of stories down the backlog, and promoting one or two, but in most cases
                90%
                > of the stories we do each sprint is from the 'top of the list'.
                >
                > >> I can certainly see how the cross-functional could work with a
                more
                > >> general team of less experienced developers who are used to doing
                a
                > >> 'bit of everything', its working with a team of experts on a
                project
                > >> with a diverse technology mix is what I am struggling with.
                > >
                > > I don't see your point. A more experienced developer should have no
                > > problem picking up new skills. That's how they got to be experienced.
                >
                > I agree, but we don't take on people with 8-12 years experience in their
                > particular skill set to spend a few years learning a completely different
                > one from scratch, might as well hire some junior developers.
                >
                > > It sounds like the organization has encouraged specialization,
                >
                > We have not encouraged it, its been deliberate and very successful.
                >
                > > so it's
                > > no surprise that developers may not want to expand their skillset.
                >
                > Its not really the developers that don't want to expand there skill set,
                its
                > the company that wants to use the developers to work on stuff they have
                the
                > skills and experience to do.
                >
                > > Is
                > > there a reward for learning new skills, or more likely, is there risk
                > > that they'll be called on the carpet for "taking so long"?
                >
                > Neither, we just want to use everyones skills in the best and most
                > productive way.
                >
                > To put it another way, I am currently having some building work done on my
                > house and I have a 'team' in to do it. That 'team' consists of qualified
                > plumbers, electricians, plasterers etc, each doing there 'own work'. I
                don't
                > see the electrician doing a bit of plumbing one week, and the plasterer
                > fitting a few lights the next. They are a self organizing team. If the
                > plasterer can get on with one task because he is waiting for the plumber
                to
                > do some work first, he does not do the plumbers work for him, he
                > re-prioritises his 'backlog' and does something else. This is not a great
                > deal different to our team setup, and I am sure we are not unique in this.
                >
                > Phil
                >

              • woynam
                ... some of ... them, ... So????!!! Estimates are a means to an end. Of course, they re based on the person doing the work. If the newbies are doing the work,
                Message 7 of 24 , Mar 3, 2008
                  --- In scrumdevelopment@yahoogroups.com, Phil Shrimpton <phil@...> wrote:
                  >
                  > Hi,
                  >
                  > >> The make up of the team is such that over the lifetime of a project
                  > >> there is enough work in each of their areas to keep them busy 'full
                  > >> time', I just can't see how getting people to do 'other peoples' work
                  > >> is not going to affect productivity and costs. The UI guys are
                  some of
                  > >> the best I have ever worked with and I have a lot of respect for
                  them,
                  > >> but I probably would not let them anywhere near the backend code, and
                  > >> even if I did it would take them 10 times longer than the 'backend
                  > >> developers'.
                  > >
                  > > Well, the first time they might take 10 times longer. However, isn't
                  > > this better than having nobody work on the backend code?
                  >
                  > Not really. Firstly, it is going to mess up the estimates,

                  So????!!! Estimates are a means to an end. Of course, they're based on
                  the person doing the work. If the newbies are doing the work, of
                  course the estimates will be higher, reflecting the fact that the work
                  *will* take longer.

                  > the 'real' backend guys might of estimated the work for a story at 5
                  days, but if the non-backend guys were to do it and it takes them 10
                  times longer, thats gone from 25% of a sprint, to 2.5 sprints!

                  Yes, and this is reality. If the other team members do the work it
                  probably will take 2.5 times as long.

                  >Secondly, the 'real' backend guys would need to spend time training
                  >and mentoring the 'new guys' as well as code reviews and rework, so
                  >will be spending less time doing what they are doing.

                  Yes, it's a price that you'll have to pay someday if you ever expect
                  to get out of this mess. See, Scrum is a big spotlight. All it's doing
                  is shining a light on your dirty laundry. It doesn't provide any
                  magical answers. Either everyone gets cross-trained now, with its
                  associated cost, or the team will continue to run on fewer cylinders,
                  since there will never be a perfect balance of features that keeps
                  every gainfully employed in their preferred specialty.

                  >
                  > > The next time
                  > > their needed, perhaps it'll only take 3 times as long, and then twice
                  > > as long.
                  >
                  > It would, eventually, maybe over the course of years, even the best
                  developer can't go from zero experience of something to the equivalent
                  of 8 years + experience in a few iterations.

                  Well, they're certainly not going to get there if they don't get
                  started. :-) Besides, nobody ever said they were going to become as
                  knowledgeable as the experts. How long will it take them to become
                  useful? The alternative is to have *nobody* working on the tasks.

                  >
                  > > How is this any different than having a junior developer in
                  > > the backend group?
                  >
                  > Its not, thats why we don't hire junior developers :-).

                  Yup, I thought so. :-) It sounds like the company would rather have an
                  open position go unfilled for years because you can't find a senior
                  developer, when you could have hired a junior person and taught them
                  the skills they need.

                  >
                  > > If people are willing to step up and help out,
                  > > they're going to need training, which will take time. Yes, it may be
                  > > less productive initially, but in the long run you'll have a much more
                  > > productive group.
                  >
                  > This is where I start to struggle. We have a very productive group
                  at the moment, to bring everyones skill set in 'other' technologies up
                  to the same level as every one elses will take years, and in the
                  meantime will have a massive impact on productivity.

                  Again, they don't have to have the same level of skill to be
                  productive. Any task that goes unstarted because the person with the
                  expert skills is unavailable will be better served by having someone
                  minimally capable take a stab at it.

                  >
                  > > The key, though, is that it's not "other people's work". It's the
                  > > *team's* work.
                  >
                  > I 100% agree that the work is the 'teams' work, and every one takes
                  collective responsibility for it as a whole, its just that different
                  people do different bits.

                  In the immortal words of Yoda in "The Empire Strikes Back", this is
                  why you fail. :-)

                  >
                  > > If you can't get over this hurdle, then you'll never
                  > > experience the full benefit of agile development.
                  >
                  > Its not really a hurdle we want to get over (or probably can get
                  over). Its not really caused too much of a problem up till now, but
                  we have had to do 2 to 3 different 'estimates' for each story for each
                  'skill set' to help sprint planning so as not to have too much/less
                  work for one skill set. Its not as bad as it sounds, the 'worst' its
                  has been is having to push a couple of stories down the backlog, and
                  promoting one or two, but in most cases 90% of the stories we do each
                  sprint is from the 'top of the list'.
                  >
                  > >> I can certainly see how the cross-functional could work with a more
                  > >> general team of less experienced developers who are used to doing a
                  > >> 'bit of everything', its working with a team of experts on a project
                  > >> with a diverse technology mix is what I am struggling with.
                  > >
                  > > I don't see your point. A more experienced developer should have no
                  > > problem picking up new skills. That's how they got to be experienced.
                  >
                  > I agree, but we don't take on people with 8-12 years experience in
                  their particular skill set to spend a few years learning a completely
                  different one from scratch, might as well hire some junior developers.
                  >
                  > > It sounds like the organization has encouraged specialization,
                  >
                  > We have not encouraged it, its been deliberate and very successful.
                  >
                  > > so it's
                  > > no surprise that developers may not want to expand their skillset.
                  >
                  > Its not really the developers that don't want to expand there skill
                  set, its the company that wants to use the developers to work on stuff
                  they have the skills and experience to do.

                  Once again, this is where agile development requires a change of
                  mindset. While a group of experts can certainly be productive, as you
                  point out above, a group of cross-trained developers can eventually
                  become more productive, as no task goes wanting for a developer.

                  What happens if one of your experts gets run over by a car? It
                  happened to us a month ago. Ouch. Is there someone to step up? I've
                  always likened the approach to the U.S. Army Special Forces. Everyone
                  has a specialty, but everyone is also cross-trained in 2 other
                  disciplines. If the medic is the first one killed getting off the
                  helicopter, who's going to bandage the wounds?

                  >
                  > > Is
                  > > there a reward for learning new skills, or more likely, is there risk
                  > > that they'll be called on the carpet for "taking so long"?
                  >
                  > Neither, we just want to use everyones skills in the best and most
                  productive way.
                  >
                  > To put it another way, I am currently having some building work done
                  on my house and I have a 'team' in to do it. That 'team' consists of
                  qualified plumbers, electricians, plasterers etc, each doing there
                  'own work'. I don't see the electrician doing a bit of plumbing one
                  week, and the plasterer fitting a few lights the next. They are a self
                  organizing team. If the plasterer can get on with one task because he
                  is waiting for the plumber to do some work first, he does not do the
                  plumbers work for him, he re-prioritises his 'backlog' and does
                  something else. This is not a great deal different to our team setup,
                  and I am sure we are not unique in this.

                  Provided that there's other work they can do. If the plumber is not
                  around, then the drywall person is dead in the water id they have no
                  other work to do, other than finish the wall in front of the plumbing.

                  Personally, I'd rather hire a few jack-of-all trades, and resort to
                  the specialists only when absolutely necessary. A good handyman knows
                  when they're getting in over their heads.

                  I'm sorry I didn't solve your problem. You came looking for answers to
                  your scheduling problem, but you didn't like the answer. I don't
                  believe anyone else will have a solution, either. In a nutshell, an
                  organization that attempt to locally optimize generally fails to
                  optimize the whole. With agile development, we're trying to get
                  completed features out the door so that our customers can get maximum
                  ROI. If features are getting delayed because we'd rather have the team
                  work on other tasks for other features, then that's the business' call.

                  Mark


                  >
                  > Phil
                  >
                • woynam
                  Hey, I hear that have toilet paper available this week!!! Hurry, we need to get some before they run out! :-) ... USSR ... Platforms Are ... peoples work ...
                  Message 8 of 24 , Mar 3, 2008
                    Hey, I hear that have toilet paper available this week!!! Hurry, we
                    need to get some before they run out! :-)


                    --- In scrumdevelopment@yahoogroups.com, "Ken Schwaber"
                    <ken.schwaber@...> wrote:
                    >
                    > Well done. Think of waterfall as being similar in concept to the old
                    USSR
                    > central planning of the economy. Think of Scrum as similar to a market
                    > economy.
                    >
                    > Ken
                    >
                    >
                    >
                    > _____
                    >
                    > From: scrumdevelopment@yahoogroups.com
                    > [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Dmitry Beransky
                    > Sent: Monday, March 03, 2008 5:01 PM
                    > To: scrumdevelopment@yahoogroups.com
                    > Subject: Re: [scrumdevelopment] Re: Estimating When Several
                    Platforms Are
                    > Involved
                    >
                    >
                    >
                    > Phil,
                    >
                    > I went back and re-read your original question to make sure I didn't
                    > miss anything. I don't think I have, so I have to ask: why are you
                    > switching to Scrum. From your own statements, it seems that the
                    > current process/environment has been working for your organization
                    > just fine. You are reasonably happy with it and it seems to be
                    > producing results. Are you changing to Scrum just for the same of
                    > change? Because we can give you many reasons and recommendations on
                    > what to do, but at the end of the day if our recommendations aren't
                    > fixing concrete problems, your management (and you too) will keep
                    > dismissing them as unnecessary (and I can't blame them).
                    >
                    > I think it was Karl Marx who defined the revolutionary situation as
                    > where the ruling class is no longer able to rule in the old way, and
                    > the exploited are no longer willing to be ruled in the old way.
                    > Substitute "the ruling class" with "management" and "exploited" with
                    > developers/engineers, and you get the perfect definition of a
                    > situation which is be best for introducing Scrum/Agile into a company.
                    > Are you in that situation?
                    >
                    > Regards
                    > Dmitry
                    >
                    > On Mon, Mar 3, 2008 at 1:42 PM, Phil Shrimpton <phil@shrimpton.
                    > <mailto:phil%40shrimpton.co.uk> co.uk> wrote:
                    > >
                    > >
                    > >
                    > >
                    > > Hi,
                    > >
                    > > >> The make up of the team is such that over the lifetime of a project
                    > > >> there is enough work in each of their areas to keep them busy 'full
                    > > >> time', I just can't see how getting people to do 'other
                    peoples' work
                    > > >> is not going to affect productivity and costs. The UI guys are
                    some of
                    > > >> the best I have ever worked with and I have a lot of respect
                    for them,
                    > > >> but I probably would not let them anywhere near the backend
                    code, and
                    > > >> even if I did it would take them 10 times longer than the 'backend
                    > > >> developers'.
                    > > >
                    > > > Well, the first time they might take 10 times longer. However, isn't
                    > > > this better than having nobody work on the backend code?
                    > >
                    > > Not really. Firstly, it is going to mess up the estimates, the 'real'
                    > > backend guys might of estimated the work for a story at 5 days,
                    but if the
                    > > non-backend guys were to do it and it takes them 10 times longer,
                    thats
                    > gone
                    > > from 25% of a sprint, to 2.5 sprints! Secondly, the 'real' backend
                    guys
                    > > would need to spend time training and mentoring the 'new guys' as
                    well as
                    > > code reviews and rework, so will be spending less time doing what
                    they are
                    > > doing.
                    > >
                    > > > The next time
                    > > > their needed, perhaps it'll only take 3 times as long, and then
                    twice
                    > > > as long.
                    > >
                    > > It would, eventually, maybe over the course of years, even the best
                    > > developer can't go from zero experience of something to the
                    equivalent of
                    > 8
                    > > years + experience in a few iterations.
                    > >
                    > > > How is this any different than having a junior developer in
                    > > > the backend group?
                    > >
                    > > Its not, thats why we don't hire junior developers :-).
                    > >
                    > > > If people are willing to step up and help out,
                    > > > they're going to need training, which will take time. Yes, it may be
                    > > > less productive initially, but in the long run you'll have a
                    much more
                    > > > productive group.
                    > >
                    > > This is where I start to struggle. We have a very productive group
                    at the
                    > > moment, to bring everyones skill set in 'other' technologies up to the
                    > same
                    > > level as every one elses will take years, and in the meantime will
                    have a
                    > > massive impact on productivity.
                    > >
                    > > > The key, though, is that it's not "other people's work". It's the
                    > > > *team's* work.
                    > >
                    > > I 100% agree that the work is the 'teams' work, and every one takes
                    > > collective responsibility for it as a whole, its just that different
                    > people
                    > > do different bits.
                    > >
                    > > > If you can't get over this hurdle, then you'll never
                    > > > experience the full benefit of agile development.
                    > >
                    > > Its not really a hurdle we want to get over (or probably can get
                    over).
                    > Its
                    > > not really caused too much of a problem up till now, but we have
                    had to do
                    > 2
                    > > to 3 different 'estimates' for each story for each 'skill set' to help
                    > > sprint planning so as not to have too much/less work for one skill
                    set.
                    > Its
                    > > not as bad as it sounds, the 'worst' its has been is having to push a
                    > couple
                    > > of stories down the backlog, and promoting one or two, but in most
                    cases
                    > 90%
                    > > of the stories we do each sprint is from the 'top of the list'.
                    > >
                    > > >> I can certainly see how the cross-functional could work with a more
                    > > >> general team of less experienced developers who are used to doing a
                    > > >> 'bit of everything', its working with a team of experts on a
                    project
                    > > >> with a diverse technology mix is what I am struggling with.
                    > > >
                    > > > I don't see your point. A more experienced developer should have no
                    > > > problem picking up new skills. That's how they got to be
                    experienced.
                    > >
                    > > I agree, but we don't take on people with 8-12 years experience in
                    their
                    > > particular skill set to spend a few years learning a completely
                    different
                    > > one from scratch, might as well hire some junior developers.
                    > >
                    > > > It sounds like the organization has encouraged specialization,
                    > >
                    > > We have not encouraged it, its been deliberate and very successful.
                    > >
                    > > > so it's
                    > > > no surprise that developers may not want to expand their skillset.
                    > >
                    > > Its not really the developers that don't want to expand there
                    skill set,
                    > its
                    > > the company that wants to use the developers to work on stuff they
                    have
                    > the
                    > > skills and experience to do.
                    > >
                    > > > Is
                    > > > there a reward for learning new skills, or more likely, is there
                    risk
                    > > > that they'll be called on the carpet for "taking so long"?
                    > >
                    > > Neither, we just want to use everyones skills in the best and most
                    > > productive way.
                    > >
                    > > To put it another way, I am currently having some building work
                    done on my
                    > > house and I have a 'team' in to do it. That 'team' consists of
                    qualified
                    > > plumbers, electricians, plasterers etc, each doing there 'own work'. I
                    > don't
                    > > see the electrician doing a bit of plumbing one week, and the
                    plasterer
                    > > fitting a few lights the next. They are a self organizing team. If the
                    > > plasterer can get on with one task because he is waiting for the
                    plumber
                    > to
                    > > do some work first, he does not do the plumbers work for him, he
                    > > re-prioritises his 'backlog' and does something else. This is not
                    a great
                    > > deal different to our team setup, and I am sure we are not unique
                    in this.
                    > >
                    > > Phil
                    > >
                    >
                  • Phil Shrimpton
                    Hi, ... Well we are not switching to Scrum, we have (just about) switched already. We are coming to the end of our second project using Scrum, and both have
                    Message 9 of 24 , Mar 4, 2008
                      Hi,

                      > I went back and re-read your original question to make sure I didn't
                      > miss anything. I don't think I have, so I have to ask: why are you
                      > switching to Scrum.

                      Well we are not switching to Scrum, we have (just about) switched already. We are coming to the end of our second project using Scrum, and both have been a great success. They were both quite small projects (around 6 months/8 sprints), but the success convinced us that Scrum is suitable for us for use on larger projects and to roll out across the company.

                      The first project we pretty much made it up as we went along and 'winged it' Scrum wise, but what we did do worked. The project we are coming to the end of we did about 85-90% 'correct scrum', with even better results. Before we start on the next project, we want to get to grips with the couple or three things that make up the 10-15% we did not do, or did not do properly.

                      One of those things was coming up with 'story points' and prioritising the backlog when you have a team of people with different skill sets. When the original poster of this thread stated that he was in a similar situation, I thought I would post a 'I am struggling with this issue as well'.

                      > From your own statements, it seems that the
                      > current process/environment has been working for your organization
                      > just fine. You are reasonably happy with it and it seems to be
                      > producing results. Are you changing to Scrum just for the same of
                      > change?

                      As I said above, the main reason for our process/environment working so well is because of changing to Scrum (and before it 'just' XP), we are just looking for advice and information on that last bit of Scrum we are not doing correctly or at all.

                      > Because we can give you many reasons and recommendations on
                      > what to do, but at the end of the day if our recommendations aren't
                      > fixing concrete problems, your management (and you too) will keep
                      > dismissing them as unnecessary (and I can't blame them).

                      Well the general consensus so far on this thread is to have a cross functional team "or you should not be doing Scrum". I have tried to explain why I think retraining "Developer A", who is highly experience in "Language/Platform/OS A" in "Language/Platform/OS B" to help out "Developer B" one sprint, only to have to retrain "Developer B" in "Language/Platform/OS A" to help out "Developer A" the following sprint will have a massive productivity/cost hit for quite a substantial period. The reaction to that is that it is "the only way". I personally don't think its the "only way", its certainly not the way for us, and I am sure it is not for quite a few other companies either.

                      I see lots of Job adverts from companies saying they do 'Agile' for, say, Java/Unix developers with 5-7 years experience, are they not telling the truth when they say they do 'Agile', or do they spend a lot of time and money retraining the Java/Unix guy in Visual Basic and Windows to help the UI guys out when they have too much on? I would say they have hired the Java/Unix guy to do Java/Unix, not to do Oracle DBA work, or Windows device driver development, as they probably already hired experienced people to do that. Thats all we do, if we need a Java developer, we hire a Java developer, if we need a DBA, we hire a DBA, I am sure we are not alone in this?

                      > I think it was Karl Marx who defined the revolutionary situation as
                      > where the ruling class is no longer able to rule in the old way, and
                      > the exploited are no longer willing to be ruled in the old way.
                      > Substitute "the ruling class" with "management" and "exploited" with
                      > developers/engineers, and you get the perfect definition of a
                      > situation which is be best for introducing Scrum/Agile into a company.
                      > Are you in that situation?

                      In our case the revolution came from the 'workers' (the development team), after having been involved in a couple multi-million pound waterfall failures. "Management" thought they were doing everything correctly and by the book so it must have been the 'workers' fault. The development teams changed they way they worked completely (from waterfall to XP-like, with great success, 'management' was impressed and wanted to applied what the development team had done out side the development team in up the project management change, and Agile/Scrum was the obvious way. And as I said above, it has largely been successful, there is just a few 'bad smells' that need sorting out before we start scaling it up and out.

                      Cheers
                      Phil
                    • woynam
                      ... already. We are coming to the end of our second project using Scrum, and both have been a great success. They were both quite small projects (around 6
                      Message 10 of 24 , Mar 4, 2008
                        --- In scrumdevelopment@yahoogroups.com, Phil Shrimpton <phil@...> wrote:
                        >
                        > Hi,
                        >
                        > > I went back and re-read your original question to make sure I didn't
                        > > miss anything. I don't think I have, so I have to ask: why are you
                        > > switching to Scrum.
                        >
                        > Well we are not switching to Scrum, we have (just about) switched
                        already. We are coming to the end of our second project using Scrum,
                        and both have been a great success. They were both quite small
                        projects (around 6 months/8 sprints), but the success convinced us
                        that Scrum is suitable for us for use on larger projects and to roll
                        out across the company.
                        >
                        > The first project we pretty much made it up as we went along and
                        'winged it' Scrum wise, but what we did do worked. The project we are
                        coming to the end of we did about 85-90% 'correct scrum', with even
                        better results. Before we start on the next project, we want to get
                        to grips with the couple or three things that make up the 10-15% we
                        did not do, or did not do properly.
                        >
                        > One of those things was coming up with 'story points' and
                        prioritising the backlog when you have a team of people with different
                        skill sets. When the original poster of this thread stated that he
                        was in a similar situation, I thought I would post a 'I am struggling
                        with this issue as well'.
                        >
                        > > From your own statements, it seems that the
                        > > current process/environment has been working for your organization
                        > > just fine. You are reasonably happy with it and it seems to be
                        > > producing results. Are you changing to Scrum just for the same of
                        > > change?
                        >
                        > As I said above, the main reason for our process/environment working
                        so well is because of changing to Scrum (and before it 'just' XP), we
                        are just looking for advice and information on that last bit of Scrum
                        we are not doing correctly or at all.
                        >
                        > > Because we can give you many reasons and recommendations on
                        > > what to do, but at the end of the day if our recommendations aren't
                        > > fixing concrete problems, your management (and you too) will keep
                        > > dismissing them as unnecessary (and I can't blame them).
                        >
                        > Well the general consensus so far on this thread is to have a cross
                        functional team "or you should not be doing Scrum". I have tried to
                        explain why I think retraining "Developer A", who is highly experience
                        in "Language/Platform/OS A" in "Language/Platform/OS B" to help out
                        "Developer B" one sprint, only to have to retrain "Developer B" in
                        "Language/Platform/OS A" to help out "Developer A" the following
                        sprint will have a massive productivity/cost hit for quite a
                        substantial period. The reaction to that is that it is "the only
                        way". I personally don't think its the "only way", its certainly not
                        the way for us, and I am sure it is not for quite a few other
                        companies either.

                        I don't think this is a fair summary. You can certainly have a team of
                        specialists working together and doing Scrum correctly. It sounds like
                        this is your current situation.

                        You asked for advice on how you could get the last 10% productivity
                        out of the team. I said that unless the features perfectly line up
                        such that everyone one the team has equal amounts of work, there will
                        always be someone with nothing to do, while at the same time there
                        will be tasks that can't be worked on because the appropriate
                        specialist isn't available. The only solution I see to this problem is
                        cross-training.

                        That said, if you're running at 80+ percent, and the team is happy,
                        and management is happy, and this is your biggest problem, well then
                        "Congratulations!". You appear to have hit a home run in the first
                        inning. I would say that the vast majority of teams don't reach this
                        level this quickly.

                        >
                        > I see lots of Job adverts from companies saying they do 'Agile' for,
                        say, Java/Unix developers with 5-7 years experience, are they not
                        telling the truth when they say they do 'Agile', or do they spend a
                        lot of time and money retraining the Java/Unix guy in Visual Basic and
                        Windows to help the UI guys out when they have too much on? I would
                        say they have hired the Java/Unix guy to do Java/Unix, not to do
                        Oracle DBA work, or Windows device driver development, as they
                        probably already hired experienced people to do that. Thats all we
                        do, if we need a Java developer, we hire a Java developer, if we need
                        a DBA, we hire a DBA, I am sure we are not alone in this?

                        No, you're not alone, but then again, the vast majority of companies
                        do not do agile. Most companies do waterfall, and organize along
                        role-based lines, i.e. analysts, developers, testers, etc. Within
                        development, most are further subdivided by specialty. With this
                        structure comes plenty of hand-offs, plenty of waste, plenty of waiting.

                        To achieve "nirvana", many of us believe that these roles need to be
                        discarded, and the team staffed with generalizing specialists. Again,
                        this does not mean no specialists. It simply means that in a crunch
                        someone can pick up the slack. When combined with pair programming,
                        this ensures that everyone gets a chance to work in all areas of the
                        system, and that the design and code is being continuously reviewed.
                        It's never a bad idea to pair a junior person with a senior person.

                        >
                        > > I think it was Karl Marx who defined the revolutionary situation as
                        > > where the ruling class is no longer able to rule in the old way, and
                        > > the exploited are no longer willing to be ruled in the old way.
                        > > Substitute "the ruling class" with "management" and "exploited" with
                        > > developers/engineers, and you get the perfect definition of a
                        > > situation which is be best for introducing Scrum/Agile into a company.
                        > > Are you in that situation?
                        >
                        > In our case the revolution came from the 'workers' (the development
                        team), after having been involved in a couple multi-million pound
                        waterfall failures. "Management" thought they were doing everything
                        correctly and by the book so it must have been the 'workers' fault.
                        The development teams changed they way they worked completely (from
                        waterfall to XP-like, with great success, 'management' was impressed
                        and wanted to applied what the development team had done out side the
                        development team in up the project management change, and Agile/Scrum
                        was the obvious way. And as I said above, it has largely been
                        successful, there is just a few 'bad smells' that need sorting out
                        before we start scaling it up and out.

                        It's been said many times that Scrum works best in environments that
                        have crashed and burned several times, as you pretty much have nothing
                        to lose. It sounds like you succeeded bigtime. Once again, congrats.

                        Mark

                        >
                        > Cheers
                        > Phil
                        >
                      • Phil Shrimpton
                        Hi, ... Sorry was not clear enough. We do estimates/SPs for the team doing the work for each story, but those estimates assume the people who will do the
                        Message 11 of 24 , Mar 4, 2008
                          Hi,

                          >>> Well, the first time they might take 10 times longer. However, isn't
                          >>> this better than having nobody work on the backend code?
                          >> Not really. Firstly, it is going to mess up the estimates,
                          >
                          > So????!!! Estimates are a means to an end. Of course, they're based on
                          > the person doing the work.

                          Sorry was not clear enough. We do estimates/SPs for the 'team' doing the work for each story, but those estimates assume the people who will do the work are skilled and experienced to do do it, if the work was to be done by the 'unskilled' people, the estimates will be worthless as we would be wrong by an order of magniture. As a team we might be able to do 6-8 stories in a sprint, if we all swapped roles, we would struggle to get one done.

                          > If the newbies are doing the work, of
                          > course the estimates will be higher, reflecting the fact that the work
                          > *will* take longer.
                          >
                          > If the other team members do the work it
                          > probably will take 2.5 times as long.

                          Which is why we want the skilled people to do the work, and not the newbies :-)

                          >> Secondly, the 'real' backend guys would need to spend time training
                          >> and mentoring the 'new guys' as well as code reviews and rework, so
                          >> will be spending less time doing what they are doing.
                          >
                          > Yes, it's a price that you'll have to pay someday if you ever expect
                          > to get out of this mess.

                          I don't think we are in a mess at all. The only really problem we have is how input into the sprint planning process the fact that there is different workloads for different people when we are only meant to be producing a single 'Story Point' number for each story.

                          > Either everyone gets cross-trained now, with its
                          > associated cost, or the team will continue to run on fewer cylinders,
                          > since there will never be a perfect balance of features that keeps
                          > every gainfully employed in their preferred specialty.

                          Thats not quite correct in our case. We have our staffing levels just about right in that over the life time of a project, there is the right amount of work to keep everyone busy full time, but in prioitising stories on 'business value' alone means that some sprints some people are light on work, and the next, they have too much. For the last two projects we have been prioritising stories about 80% on "business value" and about 20% on balancing the workload, which maybe the best way for us, but others might handle it differently.

                          >>> How is this any different than having a junior developer in
                          >>> the backend group?
                          >> Its not, thats why we don't hire junior developers :-).
                          >
                          > Yup, I thought so. :-) It sounds like the company would rather have an
                          > open position go unfilled for years because you can't find a senior
                          > developer, when you could have hired a junior person and taught them
                          > the skills they need.

                          We never have a problem filling senior positions, I think the people who do are trying to hire senior people for junior salaries. I very much agree with Martin Fowler on his "Cheaper Talent Hypothesis" (http://martinfowler.com/bliki/CheaperTalentHypothesis.html)

                          > Any task that goes unstarted because the person with the
                          > expert skills is unavailable will be better served by having someone
                          > minimally capable take a stab at it.

                          The problem here is there is a real danger that 'taking a stab at it' is actually worse than not doing it at all, as the 'expert' will at the very least have to review all the work, and at worse have to redo it as it is total tosh.

                          > Once again, this is where agile development requires a change of
                          > mindset. While a group of experts can certainly be productive, as you
                          > point out above, a group of cross-trained developers can eventually
                          > become more productive, as no task goes wanting for a developer.

                          Its the 'eventually' bit that is the problem. I personally think "eventually" is several project lifetimes.

                          > What happens if one of your experts gets run over by a car? It
                          > happened to us a month ago. Ouch. Is there someone to step up?

                          We have lost 'experts' to serious illness, we re-priortised the PB to take account of this whilst we hired another 'expert', but being 'Agile' allowed us to do this with minimal impact.

                          > I'm sorry I didn't solve your problem. You came looking for answers to
                          > your scheduling problem, but you didn't like the answer.

                          Its not that I don't like the answer, its just it not an answer that will work with us :-)

                          > I don't
                          > believe anyone else will have a solution, either.

                          Maybe, maybe not, but no harm asking :-)

                          Phil
                        • Roy Morien
                          Isn t this all the main purpose of calculating velocity . Doing this in an empirical and adaptive way allows the team to adjust to the overall ability of the
                          Message 12 of 24 , Mar 5, 2008
                            Isn't this all the main purpose of calculating 'velocity'. Doing this in an empirical and adaptive way allows the team to adjust to the overall ability of the team members, taking into account the newbies and the differences in team members' production capacity. It also allows this to be tracked and the (hopefully) inevitable improvement in productivity over time to be factored into the equation.
                             
                            This, of course, is totally ignored in the up-front planned approach. It is one of the failure factors in that approach, because there is no way that the planners can know the team's abilities to produce, up front, and there is no way that this can be factored into a pre-planned activity.
                             
                            Regards,
                            Roy Morien





                            To: scrumdevelopment@yahoogroups.com
                            From: woyna@...
                            Date: Mon, 3 Mar 2008 23:42:41 +0000
                            Subject: [scrumdevelopment] Re: Estimating When Several Platforms Are Involved

                            --- In scrumdevelopment@ yahoogroups. com, Phil Shrimpton <phil@...> wrote:
                            >
                            > Hi,
                            >
                            > >> The make up of the team is such that over the lifetime of a project
                            > >> there is enough work in each of their areas to keep them busy 'full
                            > >> time', I just can't see how getting people to do 'other peoples' work
                            > >> is not going to affect productivity and costs. The UI guys are
                            some of
                            > >> the best I have ever worked with and I have a lot of respect for
                            them,
                            > >> but I probably would not let them anywhere near the backend code, and
                            > >> even if I did it would take them 10 times longer than the 'backend
                            > >> developers'.
                            > >
                            > > Well, the first time they might take 10 times longer. However, isn't
                            > > this better than having nobody work on the backend code?
                            >
                            > Not really. Firstly, it is going to mess up the estimates,

                            So????!!! Estimates are a means to an end. Of course, they're based on
                            the person doing the work. If the newbies are doing the work, of
                            course the estimates will be higher, reflecting the fact that the work
                            *will* take longer.

                            > the 'real' backend guys might of estimated the work for a story at 5
                            days, but if the non-backend guys were to do it and it takes them 10
                            times longer, thats gone from 25% of a sprint, to 2.5 sprints!

                            Yes, and this is reality. If the other team members do the work it
                            probably will take 2.5 times as long.

                            >Secondly, the 'real' backend guys would need to spend time training
                            >and mentoring the 'new guys' as well as code reviews and rework, so
                            >will be spending less time doing what they are doing.

                            Yes, it's a price that you'll have to pay someday if you ever expect
                            to get out of this mess. See, Scrum is a big spotlight. All it's doing
                            is shining a light on your dirty laundry. It doesn't provide any
                            magical answers. Either everyone gets cross-trained now, with its
                            associated cost, or the team will continue to run on fewer cylinders,
                            since there will never be a perfect balance of features that keeps
                            every gainfully employed in their preferred specialty.

                            >
                            > > The next time
                            > > their needed, perhaps it'll only take 3 times as long, and then twice
                            > > as long.
                            >
                            > It would, eventually, maybe over the course of years, even the best
                            developer can't go from zero experience of something to the equivalent
                            of 8 years + experience in a few iterations.

                            Well, they're certainly not going to get there if they don't get
                            started. :-) Besides, nobody ever said they were going to become as
                            knowledgeable as the experts. How long will it take them to become
                            useful? The alternative is to have *nobody* working on the tasks.

                            >
                            > > How is this any different than having a junior developer in
                            > > the backend group?
                            >
                            > Its not, thats why we don't hire junior developers :-).

                            Yup, I thought so. :-) It sounds like the company would rather have an
                            open position go unfilled for years because you can't find a senior
                            developer, when you could have hired a junior person and taught them
                            the skills they need.

                            >
                            > > If people are willing to step up and help out,
                            > > they're going to need training, which will take time. Yes, it may be
                            > > less productive initially, but in the long run you'll have a much more
                            > > productive group.
                            >
                            > This is where I start to struggle. We have a very productive group
                            at the moment, to bring everyones skill set in 'other' technologies up
                            to the same level as every one elses will take years, and in the
                            meantime will have a massive impact on productivity.

                            Again, they don't have to have the same level of skill to be
                            productive. Any task that goes unstarted because the person with the
                            expert skills is unavailable will be better served by having someone
                            minimally capable take a stab at it.

                            >
                            > > The key, though, is that it's not "other people's work". It's the
                            > > *team's* work.
                            >
                            > I 100% agree that the work is the 'teams' work, and every one takes
                            collective responsibility for it as a whole, its just that different
                            people do different bits.

                            In the immortal words of Yoda in "The Empire Strikes Back", this is
                            why you fail. :-)

                            >
                            > > If you can't get over this hurdle, then you'll never
                            > > experience the full benefit of agile development.
                            >
                            > Its not really a hurdle we want to get over (or probably can get
                            over). Its not really caused too much of a problem up till now, but
                            we have had to do 2 to 3 different 'estimates' for each story for each
                            'skill set' to help sprint planning so as not to have too much/less
                            work for one skill set. Its not as bad as it sounds, the 'worst' its
                            has been is having to push a couple of stories down the backlog, and
                            promoting one or two, but in most cases 90% of the stories we do each
                            sprint is from the 'top of the list'.
                            >
                            > >> I can certainly see how the cross-functional could work with a more
                            > >> general team of less experienced developers who are used to doing a
                            > >> 'bit of everything', its working with a team of experts on a project
                            > >> with a diverse technology mix is what I am struggling with.
                            > >
                            > > I don't see your point. A more experienced developer should have no
                            > > problem picking up new skills. That's how they got to be experienced.
                            >
                            > I agree, but we don't take on people with 8-12 years experience in
                            their particular skill set to spend a few years learning a completely
                            different one from scratch, might as well hire some junior developers.
                            >
                            > > It sounds like the organization has encouraged specialization,
                            >
                            > We have not encouraged it, its been deliberate and very successful.
                            >
                            > > so it's
                            > > no surprise that developers may not want to expand their skillset.
                            >
                            > Its not really the developers that don't want to expand there skill
                            set, its the company that wants to use the developers to work on stuff
                            they have the skills and experience to do.

                            Once again, this is where agile development requires a change of
                            mindset. While a group of experts can certainly be productive, as you
                            point out above, a group of cross-trained developers can eventually
                            become more productive, as no task goes wanting for a developer.

                            What happens if one of your experts gets run over by a car? It
                            happened to us a month ago. Ouch. Is there someone to step up? I've
                            always likened the approach to the U.S. Army Special Forces. Everyone
                            has a specialty, but everyone is also cross-trained in 2 other
                            disciplines. If the medic is the first one killed getting off the
                            helicopter, who's going to bandage the wounds?

                            >
                            > > Is
                            > > there a reward for learning new skills, or more likely, is there risk
                            > > that they'll be called on the carpet for "taking so long"?
                            >
                            > Neither, we just want to use everyones skills in the best and most
                            productive way.
                            >
                            > To put it another way, I am currently having some building work done
                            on my house and I have a 'team' in to do it. That 'team' consists of
                            qualified plumbers, electricians, plasterers etc, each doing there
                            'own work'. I don't see the electrician doing a bit of plumbing one
                            week, and the plasterer fitting a few lights the next. They are a self
                            organizing team. If the plasterer can get on with one task because he
                            is waiting for the plumber to do some work first, he does not do the
                            plumbers work for him, he re-prioritises his 'backlog' and does
                            something else. This is not a great deal different to our team setup,
                            and I am sure we are not unique in this.

                            Provided that there's other work they can do. If the plumber is not
                            around, then the drywall person is dead in the water id they have no
                            other work to do, other than finish the wall in front of the plumbing.

                            Personally, I'd rather hire a few jack-of-all trades, and resort to
                            the specialists only when absolutely necessary. A good handyman knows
                            when they're getting in over their heads.

                            I'm sorry I didn't solve your problem. You came looking for answers to
                            your scheduling problem, but you didn't like the answer. I don't
                            believe anyone else will have a solution, either. In a nutshell, an
                            organization that attempt to locally optimize generally fails to
                            optimize the whole. With agile development, we're trying to get
                            completed features out the door so that our customers can get maximum
                            ROI. If features are getting delayed because we'd rather have the team
                            work on other tasks for other features, then that's the business' call.

                            Mark

                            >
                            > Phil
                            >




                            Listen now! New music from the Rogue Traders.
                          Your message has been successfully submitted and would be delivered to recipients shortly.