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

Re: [scrumdevelopment] Scrum and structural unemployment

Expand Messages
  • Steven Gordon
    I meant RAISING the lottery number (lowering the risk).
    Message 1 of 5 , Aug 29, 2005
    • 0 Attachment
      I meant RAISING the "lottery number" (lowering the risk).

      On 8/29/05, Steven Gordon <sgordonphd@...> wrote:
      > Jim,
      >
      > This is where the XP practice of pair programming really helps. The
      > developer without a specific skill pair programs with a programmer
      > with that skill, thus:
      > - being productive, at least in improving quality.
      > - lowering the "lottery number" of the team.
      > - learning a new skill that makes them more valuable to the team in the future.
      >
      > ("lottery number" = the number of people on the team who could leave
      > due to winning the lottery without crippling the team.)
      >
      > You do not necessarily have to be as extreme in the pair programming
      > practice as an XP team to get some benefit from tactical pairing when
      > somebody is idle.
      >
      > Steven Gordon
      >
      > On 8/29/05, Jim Cloughley <jcloughley@...> wrote:
      > >
      > >
      > > From an economic sense, structural unemployment "involves a mismatch between
      > > the workers looking for jobs and the vacancies available". For instance, in
      > > the US, there is an excess supply of IT workers with a lack of supply of
      > > nurses. However, it is not easy to re-train IT workers to become nurses –
      > > at least short-term.
      > >
      > >
      > >
      > > It seems natural that any team of developers will have specialized skills
      > > (database/SQL strengths, server-side strengths, client-side strengths). In
      > > any one sprint, you may find that the backlog is skewed towards a set of
      > > skills that not everyone has. From my experience, this seems normal.
      > > Ideally, every developer has every skill you'd ever need to call upon and
      > > any developer could be uniformly applied to any set of work. Yet I expect
      > > this occurs in rare situations if at all.
      > >
      > >
      > >
      > > Strictly speaking this gap is not really structural unemployment as the
      > > developers can pick up the skills necessary to follow the work. However, my
      > > goal is to keep everyone busy on meaningful work related to the current
      > > sprint.
      > >
      > >
      > >
      > > I always seem to have 1 or two people potentially idle because there are no
      > > items in the sprint backlog specifically for the area of code they are
      > > responsible for. Please also note that I've only just shown up here and I
      > > didn't structure the group this way.
      > >
      > >
      > >
      > > Some strategies I have applied so far are:
      > >
      > >
      > > Re-train: have developers work on backlog items although they may work at a
      > > slower pace because they aren't familiar with the code nor the language it's
      > > written in
      > > Add items to the sprint specific to the skills these people have*
      > > Work on non-functional tasks related to the sprint
      > > Work on research on future sprints (risky items we need to assess now in
      > > order to commit the work to a future sprint)
      > > A new separate project that is in their area of expertise
      > >
      > >
      > >
      > > * is this best server the Product Owner?
      > >
      > >
      > >
      > > Can anyone share their experiences related to staffing a sprint and this
      > > description of "structural unemployment"? I'd like to know what others have
      > > done to fully staff a sprint and continuously do so.
      > >
      > >
      > >
      > > Jim
      >
    Your message has been successfully submitted and would be delivered to recipients shortly.