27751Re: Estimating When Several Platforms Are Involved
- Mar 3, 2008Hey, I hear that have toilet paper available this week!!! Hurry, we
need to get some before they run out! :-)
--- In email@example.com, "Ken Schwaber"
> Well done. Think of waterfall as being similar in concept to the old
> central planning of the economy. Think of Scrum as similar to a marketPlatforms Are
> From: firstname.lastname@example.org
> [mailto:email@example.com] On Behalf Of Dmitry Beransky
> Sent: Monday, March 03, 2008 5:01 PM
> To: firstname.lastname@example.org
> Subject: Re: [scrumdevelopment] Re: Estimating When Several
> Involvedpeoples' work
> 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?
> 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
> > >> is not going to affect productivity and costs. The UI guys aresome of
> > >> the best I have ever worked with and I have a lot of respectfor them,
> > >> but I probably would not let them anywhere near the backendcode, and
> > >> even if I did it would take them 10 times longer than the 'backendbut if the
> > >> 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,
> > non-backend guys were to do it and it takes them 10 times longer,thats
> > from 25% of a sprint, to 2.5 sprints! Secondly, the 'real' backend
> > would need to spend time training and mentoring the 'new guys' aswell as
> > code reviews and rework, so will be spending less time doing whatthey are
> > doing.twice
> > > The next time
> > > their needed, perhaps it'll only take 3 times as long, and then
> > > as long.equivalent of
> > It would, eventually, maybe over the course of years, even the best
> > developer can't go from zero experience of something to the
> 8much more
> > 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
> > > productive group.at the
> > This is where I start to struggle. We have a very productive group
> > moment, to bring everyones skill set in 'other' technologies up to thehave a
> > level as every one elses will take years, and in the meantime will
> > massive impact on productivity.over).
> > > 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
> > 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
> Itshad to do
> > not really caused too much of a problem up till now, but we have
> > 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
> > not as bad as it sounds, the 'worst' its has been is having to push a
> > of stories down the backlog, and promoting one or two, but in most
> > 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
> > >> with a diverse technology mix is what I am struggling with.experienced.
> > >
> > > 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
> > I agree, but we don't take on people with 8-12 years experience in
> > particular skill set to spend a few years learning a completelydifferent
> > one from scratch, might as well hire some junior developers.skill set,
> > > 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
> > the company that wants to use the developers to work on stuff they
> > skills and experience to do.
> > > Is
> > > there a reward for learning new skills, or more likely, is there
> > > that they'll be called on the carpet for "taking so long"?done on my
> > 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
> > house and I have a 'team' in to do it. That 'team' consists ofqualified
> > plumbers, electricians, plasterers etc, each doing there 'own work'. Iplasterer
> > see the electrician doing a bit of plumbing one week, and the
> > fitting a few lights the next. They are a self organizing team. If theplumber
> > plasterer can get on with one task because he is waiting for the
> toa great
> > 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
> > deal different to our team setup, and I am sure we are not uniquein this.
> > Phil
- << Previous post in topic Next post in topic >>