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

158762Re: [XP] Agile development with many projects and one team

Expand Messages
  • David Allsopp
    Aug 22, 2013
    • 0 Attachment
      All,

      This is very interesting and resonates with me, as much of my work has been from research funding.

      In this context, some of the industrial assumptions, like "Finishing early is good" are invalid, as projects are typically of fixed duration.
      Research projects rarely 'finish' - they merely run out of time and money.
      Your 'customer' is not the one paying the bills. You may not have any customer at all, in the sense of someone who can provide requirements. Value is not generally measured in terms of revenue, RoI, etc.

      This is why I would like to see people being more explicit about their context, e.g.
      Are you developing a product? For a mass market or a niche market?
      Or are you developing in-house software? Is it user-centric UI stuff, or backend systems?
      Are you doing contract development? Is it commercial or research? Is it fixed-goal or fixed-duration? Are you embedded with the customer, or at 'home base'?

      Without this context, it is extremely difficult to understand where people are coming from, and why they hold certain views or use certain practices.

      Regards,

      David.



      ________________________________
      From: Fran Fabrizio <fran.fabrizio@...>
      To: extremeprogramming <extremeprogramming@yahoogroups.com>
      Sent: Wednesday, 21 August 2013, 23:09
      Subject: Re: [XP] Agile development with many projects and one team


      On Wed, Aug 21, 2013 at 4:47 PM, Steven Gordon <sgordonphd@...> wrote:

      > Fran,
      >
      > This smells more like a business problem that a methodology or software
      > development problem.
      >

      Certainly (as my last reply hopefully shows) the problem is bigger than a
      dev problem, but I do think that the current and historical approach to the
      dev has contributed to the problem, and hopefully can have a role in
      addressing it moving forward.


      > Is it really best to fragment the company's capabilities on so many
      > parallel projects?  Wouldn't concentrating the capabilities on getting
      > fewer projects completely done and earning revenue, and then coming back to
      > the other projects be more profitable?
      >

      Yes.  This model would have a hard time flying in the corporate world, that
      much is certain.

      Higher ed research centers are a different universe.  :-)  Win a grant ->
      build a team and consider each grant in isolation from one another is
      generally actually a decent approach (with the somewhat unfortunate side
      effect that many grants don't get renewed, so people are out of a job when
      it ends).  In some sense, our problem is that we're actually unusually
      successful in what we do - we have a phenomenal grant renewal rate relative
      to peers and federal research as a whole - so the projects never die.  :-)
      We just keep piling on new ones.


      > Even if these projects are for clients, you will not get them done faster
      > by spreading your capabilities so thinly.  Prioritizing gets some projects
      > done sooner and none any later than doing them all at the same time.  Draw
      > them out on graph paper, and you will see this is the case.  When you
      > factor in context-switching time, even the last projects done in priority
      > order get done earlier than when they are all worked on in parallel.
      >

      Interesting point. We work in terms of research grants (which are generally
      no more granular than "we'll do X in year one, Y in year two, etc..." for a
      typical 5 year grant.)  The challenge is that even though logically some
      are higher priority than others, there are entire teams of researchers that
      would be stuck waiting if we decided we weren't going to work on their
      project for say, 6 months, and we're obligated to our funding sources to be
      making more or less consistent progress over the life of the grant.  Once
      the clock starts ticking on one of them, you can't really say "well, we'll
      get to it next year" - you can hedge a little bit (try to front-load some
      of the non-IT portions of the work, etc...) but eventually you need to get
      working on each.  And I simplified it in my earlier post - we actually have
      20+ grants all active right now which all include dev deliverables.


      > I would ask how many of these projects are new development vs. mostly
      > maintenance? This is a factor in how you might go about organizing.
      >

      All feature new development regularly (that's how you keep the grant
      machine rolling - "renew our grant and we'll add features X,Y and Z over
      the next 5 years").  The older projects also require a lot of maintenance
      of code implemented long ago.  The main difference is that in a young
      project, you're likely building everything up at the same time (web UI,
      data processing pipelines, metadata tools) whereas on a more mature project
      you may be able to be more focused on just one or two areas of the product
      where you choose to make refinements.

      -Fran


      [Non-text portions of this message have been removed]



      ------------------------------------

      To Post a message, send it to:  extremeprogramming@...

      To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe@...

      ad-free courtesy of objectmentor.comYahoo! Groups Links



      [Non-text portions of this message have been removed]
    • Show all 9 messages in this topic