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

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

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


      > Phil

      Listen now! New music from the Rogue Traders.
    • Show all 24 messages in this topic