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

27702Re: Estimating When Several Platforms Are Involved

Expand Messages
  • woynam
    Mar 3, 2008
    • 0 Attachment
      --- In scrumdevelopment@yahoogroups.com, Phil Shrimpton <phil@...> wrote:
      >
      > Hi,
      >
      > > In situations like the one you describe the team coach, or scrum
      master
      > > needs to encourage those who believe they are 'done' (they are not
      done,
      > > in fact as no one is done until the story is done) to find ways of
      > > 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
      ways
      > > that team members can better understand each others' work so they are
      > > able to step in and support as required.
      >
      > This is what I am having problems with. Our systems are made up of
      three distinct technology platforms, and when hiring staff we have
      gone for quality over quantity, so all members of the team have
      between 8 and 12 years + of experience of their respective 'technologies'.
      >
      > The team has been working together for a number of years and each
      person does have a good understanding (and respect) of what is
      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".
      >
      > 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? 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
      productive group.

      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.

      >
      > 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.
      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"?

      >
      > Phil
      >
    • Show all 24 messages in this topic