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

Re: [scrumdevelopment] Re: Estimating When Several Platforms Are Involved

Expand Messages
  • Phil Shrimpton
    Hi, ... 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
    Message 1 of 24 , Mar 1, 2008
    • 0 Attachment
      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
    • 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 2 of 24 , Mar 1, 2008
      • 0 Attachment
        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 3 of 24 , Mar 3, 2008
        • 0 Attachment
          --- 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 4 of 24 , Mar 3, 2008
          • 0 Attachment
            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 5 of 24 , Mar 3, 2008
            • 0 Attachment
              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 6 of 24 , Mar 3, 2008
              • 0 Attachment
                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 7 of 24 , Mar 3, 2008
                • 0 Attachment

                  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 8 of 24 , Mar 3, 2008
                  • 0 Attachment
                    --- 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 9 of 24 , Mar 3, 2008
                    • 0 Attachment
                      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 10 of 24 , Mar 4, 2008
                      • 0 Attachment
                        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 11 of 24 , Mar 4, 2008
                        • 0 Attachment
                          --- 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 12 of 24 , Mar 4, 2008
                          • 0 Attachment
                            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 13 of 24 , Mar 5, 2008
                            • 0 Attachment
                              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.