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

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

Expand Messages
  • Phil Shrimpton
    Mar 4, 2008
    • 0 Attachment

      >>> 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 :-)

    • Show all 24 messages in this topic