27702Re: Estimating When Several Platforms Are Involved
- Mar 3, 2008--- In firstname.lastname@example.org, Phil Shrimpton <phil@...> wrote:
> > In situations like the one you describe the team coach, or scrum
> > needs to encourage those who believe they are 'done' (they are notdone,
> > in fact as no one is done until the story is done) to find ways ofways
> > 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
> > that team members can better understand each others' work so they arethree distinct technology platforms, and when hiring staff we have
> > able to step in and support as required.
> This is what I am having problems with. Our systems are made up of
gone for quality over quantity, so all members of the team have
between 8 and 12 years + of experience of their respective 'technologies'.
>person does have a good understanding (and respect) of what is
> The team has been working together for a number of years and each
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".
>there is enough work in each of their areas to keep them busy 'full
> The make up of the team is such that over the lifetime of a project
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
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
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.
>general team of less experienced developers who are used to doing a
> I can certainly see how the cross-functional could work with a more
'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"?
- << Previous post in topic Next post in topic >>