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

27751Re: Estimating When Several Platforms Are Involved

Expand Messages
  • woynam
    Mar 3, 2008
    • 0 Attachment
      Hey, I hear that have toilet paper available this week!!! Hurry, we
      need to get some before they run out! :-)


      --- In scrumdevelopment@yahoogroups.com, "Ken Schwaber"
      <ken.schwaber@...> wrote:
      >
      > Well done. Think of waterfall as being similar in concept to the old
      USSR
      > central planning of the economy. Think of Scrum as similar to a market
      > economy.
      >
      > Ken
      >
      >
      >
      > _____
      >
      > From: scrumdevelopment@yahoogroups.com
      > [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Dmitry Beransky
      > Sent: Monday, March 03, 2008 5:01 PM
      > To: scrumdevelopment@yahoogroups.com
      > Subject: Re: [scrumdevelopment] Re: Estimating When Several
      Platforms Are
      > Involved
      >
      >
      >
      > Phil,
      >
      > 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?
      >
      > Regards
      > Dmitry
      >
      > 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
      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
      > > >> 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,
      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! 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.
      > >
      > > > 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.
      > >
      > > > 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
      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.
      > >
      > > > 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.
      > >
      > > > 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.
      > >
      > > > 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.
      > >
      > > Phil
      > >
      >
    • Show all 24 messages in this topic