27846RE: [scrumdevelopment] Re: Estimating When Several Platforms Are Involved
- Mar 5 3:15 PMIsn'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.
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:
> >> 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
> >> 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
> 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.
Listen now! New music from the Rogue Traders.
- << Previous post in topic