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

Estimating When Several Platforms Are Involved

Expand Messages
  • xtcsonik
    Warning! I m fairly new to agile practices so forgive any dumb questions. We have several complex systems that interface with on many other platforms.
    Message 1 of 24 , Feb 27, 2008
      Warning! I'm fairly new to agile practices so forgive any "dumb"
      questions.

      We have several complex systems that interface with on many other
      platforms. Pretty much all our projects require a development effort
      on the front-end web application, the integration middleware server, a
      database effort, perhaps a web service change etc.

      When estimating the product backlog, if one user story requires changes
      in all these systems, how do I derive a decent estimate? If its a
      minor change in the front-end web application (3 ideal hours), but a
      major change in the middleware layer (50 ideal hours), do I take the
      critical path approach and use the highest estimate, average the two,
      or some other approach?

      Should these estimation meetings be split into one meeting per
      platform? If so, doesn't it lose the cross-functional team dynamic?
    • Wolfgang Schulze Zachau
      Your user stories are supposed to cover all work that is required to get the story DONE. This is completely independent of the platform and the type of work.
      Message 2 of 24 , Feb 27, 2008
        Your user stories are supposed to cover all work that is required to get the story DONE. This is completely independent of the platform and the type of work.
        In other words, if you have a story that needs 3 hours work on the front-end, 50 hours on the middleware, 0 hours in the database and 2 hours for user documentation, then the total amount of effort is 55 hours.
        Now, you are not supposed to estimate user stories in hours (for all sorts of reasons), but in story points. And your teams are supposed to be cross-functional, so that one team can complete such a user story without external resources (otherwise all your estimates go completely out the window).
        And if you read this answer carefully, you will answers for your other questions in here, too.
         

        Regards,

        Wolfgang

         


        From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of xtcsonik
        Sent: 27 February 2008 15:52
        To: scrumdevelopment@yahoogroups.com
        Subject: [scrumdevelopment] Estimating When Several Platforms Are Involved

        Warning! I'm fairly new to agile practices so forgive any "dumb"
        questions.

        We have several complex systems that interface with on many other
        platforms. Pretty much all our projects require a development effort
        on the front-end web application, the integration middleware server, a
        database effort, perhaps a web service change etc.

        When estimating the product backlog, if one user story requires changes
        in all these systems, how do I derive a decent estimate? If its a
        minor change in the front-end web application (3 ideal hours), but a
        major change in the middleware layer (50 ideal hours), do I take the
        critical path approach and use the highest estimate, average the two,
        or some other approach?

        Should these estimation meetings be split into one meeting per
        platform? If so, doesn't it lose the cross-functional team dynamic?

      • xtcsonik
        So if I wanted to do this using a planning poker approach, and the 2 members who are web developers say its 1 story point, and the 3 integration developers
        Message 3 of 24 , Feb 27, 2008
          So if I wanted to do this using a "planning poker" approach, and the 2
          members who are web developers say its 1 story point, and the 3
          integration developers say its 21 story points, does the entire team
          have to come to a consensus before we can say that story has been
          estimated although the web developers known nothing about how the
          integration server works?

          I understand if one web developer says its 1 and the other web
          developer says its 10, then we can discuss and refine the estimate.
          How does this discussion proceed in a cross-functional team?
        • Mark Saffell
          I don t know what you are talking about all I do is is plan the project work some tasks and update managers. Mybe I m not even using scrum`, but this is the
          Message 4 of 24 , Feb 27, 2008
            I don't know what you are talking about all I do is is plan the project work some tasks and update managers. Mybe I'm not even using scrum`, but this is the only place I get great advice.
            What I wrote on the white board:
            A.     Vision / Scope
            B.     Recommended Requirement: Gathering Practices
            C.     General questions for interviews
            D.     Regulatory requirements techniques
            E.      Critical Success Factor: For successful requirements gathering
            Explained “down & dirty” the project and a brief example of how I run projects. I did not inform them that I was using scrum.
            -Mark A Saffell

            xtcsonik <xtcsonik@...> wrote:
            So if I wanted to do this using a "planning poker" approach, and the 2
            members who are web developers say its 1 story point, and the 3
            integration developers say its 21 story points, does the entire team
            have to come to a consensus before we can say that story has been
            estimated although the web developers known nothing about how the
            integration server works?

            I understand if one web developer says its 1 and the other web
            developer says its 10, then we can discuss and refine the estimate.
            How does this discussion proceed in a cross-functional team?



            Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now.

          • Tobias Mayer
            xtcsonik, Your questions are not dumb at all but very valid. It is an exteremely difficult transition you are making from a functionally divided group of
            Message 5 of 24 , Feb 27, 2008
              xtcsonik,

              Your questions are not dumb at all but very valid. It is an exteremely
              difficult transition you are making from a functionally divided group of
              people to an Agile cross-functional team, and the difficulties you are
              facing are very common.

              Your thoughts are running along the right track. Yes, the whole team is
              supposed to arrive at consensus. This is tough when the team members
              have no understanding of what other team members do. In this early
              stage of Agile adoption I'd advise you to worry less about accurate
              estimates and use the meeting, and the widely different estimates to
              open up dialog between team members. What we want to achieve in this
              meeting is a common understanding of the complexity of each story, so we
              can begin to work in a collaborative way to solve the problem, helping
              each other and picking up new skills on the way.

              Ask if the web developers understand why the integration developers
              believe the number is so high. Have the latter try to explain, in
              common terms, not jargon, why it is difficult. Who knows, perhaps the
              web developers will have insights into the problem. Likewise, have the
              web developers explain why the think it is easy. Introduce the testing
              aspect (often overlooked). How will the team test the web development?
              Does that increase the score? And so on.

              The estimation process is much more about sharing knowledge and
              listening than it is about getting "the right number" (you never will
              anyway). Use this opportunity to coach the team into "group think",
              rather than just focusing on their own narrow domain. It is likely the
              latter approach that has made software the mess it is today.

              I hope this helps in some way.

              Tobias


              --- In scrumdevelopment@yahoogroups.com, "xtcsonik" <xtcsonik@...>
              wrote:
              >
              > So if I wanted to do this using a "planning poker" approach, and the 2
              > members who are web developers say its 1 story point, and the 3
              > integration developers say its 21 story points, does the entire team
              > have to come to a consensus before we can say that story has been
              > estimated although the web developers known nothing about how the
              > integration server works?
              >
              > I understand if one web developer says its 1 and the other web
              > developer says its 10, then we can discuss and refine the estimate.
              > How does this discussion proceed in a cross-functional team?
              >
            • Phil Shrimpton
              ... We have a similar situation. Whilst we are fairly comfortable of coming up with an overall estimate for the story, it starts to become unstuck when
              Message 6 of 24 , Feb 28, 2008
                xtcsonik wrote:
                > We have several complex systems that interface with on many other
                > platforms. Pretty much all our projects require a development effort
                > on the front-end web application, the integration middleware server, a
                > database effort, perhaps a web service change etc.
                >
                > When estimating the product backlog, if one user story requires changes
                > in all these systems, how do I derive a decent estimate? If its a
                > minor change in the front-end web application (3 ideal hours), but a
                > major change in the middleware layer (50 ideal hours), do I take the
                > critical path approach and use the highest estimate, average the two,
                > or some other approach?
                We have a similar situation. Whilst we are fairly comfortable of coming
                up with an overall 'estimate' for the story, it starts to become unstuck
                when working out the stories for the 'next iteration'.

                For example the team can do 40 story points in the next iteration, and
                the next 4 stories in the PB are 10 points each, so it may seam like Job
                done, but that does not take into account the specific areas of work.
                So in the above example, it might be that 75% of the work required is on
                the 'middleware' of the system, so it means the 'middleware' developers
                have to work evenings and weekends to get finished, whilst the 'front
                end' developers and database people are sitting around twiddling their
                thumbs.

                I am sure this situation is very common, but can't really find any
                information about how to handle it.

                Phil
              • Tobias Mayer
                H Phil, 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
                Message 7 of 24 , Feb 28, 2008
                  H Phil,

                  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. Eventually you will have a
                  cross-functional team: a team of domain-experts with a wide view of the
                  system and the ability to support each other.

                  An earlier response of mine to this thread describes some ways that can
                  begin to happen in the Estimation meetings.

                  Regards,
                  Tobias


                  --- In scrumdevelopment@yahoogroups.com, Phil Shrimpton <phil@...>
                  wrote:
                  >
                  > xtcsonik wrote:
                  > > We have several complex systems that interface with on many other
                  > > platforms. Pretty much all our projects require a development
                  effort
                  > > on the front-end web application, the integration middleware server,
                  a
                  > > database effort, perhaps a web service change etc.
                  > >
                  > > When estimating the product backlog, if one user story requires
                  changes
                  > > in all these systems, how do I derive a decent estimate? If its a
                  > > minor change in the front-end web application (3 ideal hours), but a
                  > > major change in the middleware layer (50 ideal hours), do I take the
                  > > critical path approach and use the highest estimate, average the
                  two,
                  > > or some other approach?
                  > We have a similar situation. Whilst we are fairly comfortable of
                  coming
                  > up with an overall 'estimate' for the story, it starts to become
                  unstuck
                  > when working out the stories for the 'next iteration'.
                  >
                  > For example the team can do 40 story points in the next iteration, and
                  > the next 4 stories in the PB are 10 points each, so it may seam like
                  Job
                  > done, but that does not take into account the specific areas of work.
                  > So in the above example, it might be that 75% of the work required is
                  on
                  > the 'middleware' of the system, so it means the 'middleware'
                  developers
                  > have to work evenings and weekends to get finished, whilst the 'front
                  > end' developers and database people are sitting around twiddling their
                  > thumbs.
                  >
                  > I am sure this situation is very common, but can't really find any
                  > information about how to handle it.
                  >
                  > Phil
                  >
                • woynam
                  Well, the ultimate goal would be to get the team cross-trained, so that the web developers could pick up some middleware tasks. This is the only solution that
                  Message 8 of 24 , Feb 28, 2008
                    Well, the ultimate goal would be to get the team cross-trained, so
                    that the web developers could pick up some middleware tasks. This is
                    the only solution that will solve the problem long term.

                    Until that point, you'll have to look beyond story points, as all
                    points are not created equal. At the sprint planning meeting, you'll
                    select a candidate set of stories that meet the velocity requirements,
                    and then the team will break them down into tasks, and estimate the
                    tasks in days or hours. If any tier has too much work, one or more of
                    the features will have to be substituted with a different feature from
                    the backlog, and the process repeated.

                    In a nutshell, you'll have to try to find a set of features that
                    balance the work between the tiers. Our matrix organization deals with
                    this all the time. In the worst case scenario, a story will have to be
                    split into smaller parts, which may mean it's not deployable for two
                    or more sprints. This is the unfortunate result of skill specialization.

                    Mark

                    --- In scrumdevelopment@yahoogroups.com, Phil Shrimpton <phil@...> wrote:
                    >
                    > xtcsonik wrote:
                    > > We have several complex systems that interface with on many other
                    > > platforms. Pretty much all our projects require a development effort
                    > > on the front-end web application, the integration middleware
                    server, a
                    > > database effort, perhaps a web service change etc.
                    > >
                    > > When estimating the product backlog, if one user story requires
                    changes
                    > > in all these systems, how do I derive a decent estimate? If its a
                    > > minor change in the front-end web application (3 ideal hours), but a
                    > > major change in the middleware layer (50 ideal hours), do I take the
                    > > critical path approach and use the highest estimate, average the two,
                    > > or some other approach?
                    > We have a similar situation. Whilst we are fairly comfortable of coming
                    > up with an overall 'estimate' for the story, it starts to become
                    unstuck
                    > when working out the stories for the 'next iteration'.
                    >
                    > For example the team can do 40 story points in the next iteration, and
                    > the next 4 stories in the PB are 10 points each, so it may seam like
                    Job
                    > done, but that does not take into account the specific areas of work.
                    > So in the above example, it might be that 75% of the work required
                    is on
                    > the 'middleware' of the system, so it means the 'middleware' developers
                    > have to work evenings and weekends to get finished, whilst the 'front
                    > end' developers and database people are sitting around twiddling their
                    > thumbs.
                    >
                    > I am sure this situation is very common, but can't really find any
                    > information about how to handle it.
                    >
                    > Phil
                    >
                  • xtcsonik
                    We re in a pickle then because we actually hire external consultants to work on the middle integration layer. I don t know how I could possibly implement this
                    Message 9 of 24 , Feb 28, 2008
                      We're in a pickle then because we actually hire external consultants
                      to work on the middle integration layer. I don't know how I could
                      possibly implement this having [vendor middleware server] consultants
                      coming in and leaving as experts in web development and Oracle. I'm
                      not saying it would be a bad thing, but a hard bit to sell to management.

                      I'm surprised this isn't a more common issue with large IT
                      environments. Is it possible that scrum / agile is not a good fit for
                      this type of environment?

                      I figured all the huge companies that are supposedly using scrum would
                      have a similar environment with disparate systems working together.
                      Or is this a fallacy and its really more along the lines that only
                      non-mission critical applications are using scrum? So an internal
                      development team for some "support app" (hr, payroll, t & e) is using
                      scrum while major systems use something else? Any ideas?
                    • Tobias Mayer
                      The focus would rather be the other way round. Have your own guys begin to learn the middleware code. Dividing a system into layers, rather than slices is
                      Message 10 of 24 , Feb 28, 2008
                        The focus would rather be the other way round. Have your own guys begin
                        to learn the middleware code. Dividing a system into layers, rather
                        than slices is prone to all kinds of integration problems later on. The
                        more you can begin to move the team towards an integrated system view
                        the better off you will be. I have worked with mixed teams of
                        consultants and employees. Scrum can work in such contexts, but I
                        recognize it seems very tough right now in your situation. Perhaps your
                        organization needs to consider bringing in a coach to help guide the
                        effort. You're certainly in the right place to find one.

                        Tobias


                        --- In scrumdevelopment@yahoogroups.com, "xtcsonik" <xtcsonik@...>
                        wrote:
                        >
                        > We're in a pickle then because we actually hire external consultants
                        > to work on the middle integration layer. I don't know how I could
                        > possibly implement this having [vendor middleware server] consultants
                        > coming in and leaving as experts in web development and Oracle. I'm
                        > not saying it would be a bad thing, but a hard bit to sell to
                        management.
                        >
                        > I'm surprised this isn't a more common issue with large IT
                        > environments. Is it possible that scrum / agile is not a good fit for
                        > this type of environment?
                        >
                        > I figured all the huge companies that are supposedly using scrum would
                        > have a similar environment with disparate systems working together.
                        > Or is this a fallacy and its really more along the lines that only
                        > non-mission critical applications are using scrum? So an internal
                        > development team for some "support app" (hr, payroll, t & e) is using
                        > scrum while major systems use something else? Any ideas?
                        >
                      • woynam
                        ... management. ... No, Scrum is a perfect fit. You haven t even *started* your first iteration, and already the process is helping you identify a big
                        Message 11 of 24 , Feb 28, 2008
                          --- In scrumdevelopment@yahoogroups.com, "xtcsonik" <xtcsonik@...> wrote:
                          >
                          > We're in a pickle then because we actually hire external consultants
                          > to work on the middle integration layer. I don't know how I could
                          > possibly implement this having [vendor middleware server] consultants
                          > coming in and leaving as experts in web development and Oracle. I'm
                          > not saying it would be a bad thing, but a hard bit to sell to
                          management.
                          >
                          > I'm surprised this isn't a more common issue with large IT
                          > environments. Is it possible that scrum / agile is not a good fit for
                          > this type of environment?

                          No, Scrum is a perfect fit. You haven't even *started* your first
                          iteration, and already the process is helping you identify a big
                          impediment. Isn't that a great way to start? :-)

                          Seriously, Scrum is a big spotlight. It shines the light on all the
                          organization's practices that result in sub-optimal outcomes. Hiring
                          middleware specialists that are unwilling or unable to cross-train to
                          help *you*, the customer, seems to be a mistake. What is you could
                          turn back the clock and hire a firm that would do the middleware work,
                          and also pick up any other development as necessary to help your
                          organization succeed. Wouldn't this be better?

                          Selecting a different process isn't going to help solve the problem.

                          >
                          > I figured all the huge companies that are supposedly using scrum would
                          > have a similar environment with disparate systems working together.
                          > Or is this a fallacy and its really more along the lines that only
                          > non-mission critical applications are using scrum? So an internal
                          > development team for some "support app" (hr, payroll, t & e) is using
                          > scrum while major systems use something else? Any ideas?

                          We've been using Scrum for 7+ years at the world's largest options
                          exchange. Our trading and backoffice systems run the business. They're
                          certainly mission critical. They also interfaces with numerous
                          disparate systems.

                          We've kept our traditional hierarchical organization structure (w/
                          ~140 staff), organized along architectural boundaries, and still
                          managed to get the software out the door. Is it optimal? No, I don't
                          think so. I've been pushing for more cross training for years, and
                          while we've made a lot of progress, we still have a way to go.

                          Ultimately, it's all about cooperation between the groups, and finding
                          the right balance of features/stories that allow each team to get job
                          done. It helps that we've been migrating to a common service-oriented
                          platform over the past 10 years. While staff may work in different
                          areas, they utilize the same middleware and application server.

                          I'll be presenting an overview of our flavor of "Enterprise" Scrum at
                          the Chicago Scrum Gathering in April.

                          Mark

                          >
                        • 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 12 of 24 , Mar 1, 2008
                            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 13 of 24 , Mar 1, 2008
                              Hi Phil,

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

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

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

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

                              Tobias


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

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

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

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

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

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

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

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

                                  > Does the team do test-first development?

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

                                  > Does the team use pair-programming?

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

                                  > How long are your iterations?

                                  4 weeks.

                                  > Are you the Scrum Master?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

                                    > It sounds like the organization has encouraged specialization,

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

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

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

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

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

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

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

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

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


                                      Regards
                                      Dmitry

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

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

                                        Ken

                                         


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

                                         

                                        Phil,

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

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

                                        Regards
                                        Dmitry

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

                                          Mark


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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

                                                Mark

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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





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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

                                                    Mark

                                                    >
                                                    > Phil
                                                    >




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