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

Re: [scrumdevelopment] Manage the Distributed Open Source Projects with Scrum

Expand Messages
  • Dave Rooney
    Hello Alan, The Eclipse project (http://www.eclipse.org/ ) is an excellent example of a highly distributed open source ecosystem that uses an agile approach
    Message 1 of 17 , Nov 19, 2010
      Hello Alan,

      The Eclipse project (http://www.eclipse.org/ ) is an excellent example of a highly distributed open source 'ecosystem' that uses an agile approach to delivery.  Each June they release a number of projects in a 'train', the last one consisting of 39 projects, 33 MLOC and 490 committers (http://www.eclipse.org/org/press-release/20100623_heliosrelease.php ).

      Over the years they experimented with a number of approaches before settling on 6-week iterations (8 weeks in the summer), each of which delivered a 'milestone'.  That may not be "by the book" Scrum, but it was the result of numerous inspect and adapt cycles.  They tried 3 and 4 week iterations at one point (possibly 2 as well, but I'll have to check), but the overhead of managing them was deemed too high given the highly distributed nature of the project development groups.  Each project that contributes to a train is managed independently, but has certain criteria that must be met for inclusion.  In general, the quality of the product is excellent (though not 'perfect'!).

      You're correct in that a large proportion of the Eclipse developers are full-time employees who are being paid while they work on the project, though there is a not insignificant number of contributers who work on a volunteer basis.  The Eclipse Foundation employs a number of people who manage the overall process, including people whose sole job is to manage the legal aspects (http://www.eclipse.org/legal/ ), ensuring that the open source licensing model is adhered to.

      I also agree with your last sentence, and this is a classic case where years of experience with delivering a large product has allowed the 'ecosystem' to evolve around what works for them.  In the end, the overall goal of the Eclipse Foundation isn't to be doing Scrum well, but rather to ship a high quality free tool every June.
      --
      Dave Rooney
      Westboro Systems
      Web: http://www.WestboroSystems.com
      Blog: http://practicalagility.blogspot.com
      Twitter: daverooneyca



      On 19/11/2010 12:55 AM, Alan Dayley wrote:
      Hi Laurent.

      The cadence of a volunteer team working an Open Source project could be the same as any other distributed team.  Daily Scrum, Scrum Review, Retrospective, Planning and Sprints could be the same.  The Open Source nature does not dictate that it cannot be so.  The volunteer nature may prevent such a tight cadence.

      What if they have "daily scrum" once a week and sprints last for two months, with review, planning and so on in that cadence?  Such would not be "Scrum by the book" because the separation of time between events is too long.  But the team may get great benefit from showing dedication to the project and each other in such a way, as well as increased communication and incentive to get things done on time.

      The "spare time" nature of volunteer work may prevent daily dedication to the team, that is true.  But that is a problem of time availability and not a mandate of an Open Source project.

      You are right that there is a great deal to be learned from how Open Source projects work that can be applied to distributed employed teams.  Teams working Open Source projects, for example, obviously know how to communicate well with the tools of the Internet.  And they are well versed in the use of automated build and test (For example: http://build.rockbox.org/ and http://build.rockbox.org/dev.cgi).  And if you study them you will find that many are employing the principles of Agile to great benefit, even if their process may not fit a specific framework.

      And all of this is NOT to say that an Open Source project should or should not nor can or cannot use Scrum.  It's up to the team and their ability to solve their impediments to their goal.

      Alan

      On Wed, Nov 10, 2010 at 6:14 PM, Laurent Bossavit <laurent@...> wrote:

      Hi Alan, 



      > 2. The lack of financial incentive.

      That's understating how the situation differs from your usual
      corporate project. It's not just not getting paid, it's also working
      from home, on your own time, for different motivations ("learning" or
      "good standing in the OSS community" vs "doing your job as a
      professional").

      The sense of time, the cadence, is entirely different. As Charles
      observed, there's no Daily Scrum - there's no daily anything because
      it's not the kind of work where there is daily anything. There's no
      task board because there's no physical shared space; instead, *the
      work itself* serves as a virtual shared space. You focus on the source
      control stream, maybe on the issues list. There's no "pigs" and
      "chickens" - the OSS culture typically doesn't recognize people other
      than contributors. There's no product owner - the very notion of
      "ownership" plays out totally differently.

      >From your earlier:


      > Open Source is not a project management framework or process. It is
      > not comparable to Scrum but orthogonal to it.

      So that seems to be a definitional argument. "Open Source is an X,
      whereas Scrum is a Y, therefore Z." We could volley back and forth on
      the definitions without ever reaching agreement. I could counter
      "Scrum isn't a project management framework either", and so on. Not
      productive.

      The interesting question is, "under constraint X, what reasons do we
      have to believe that practice/tactic Y achieves benefit Z ?" So that
      we could look at the OP's actual situation, ask them what kind of
      results/benefits they want, and make a reasoned argument for this or
      that tactic giving them a good shot at those benefits, within the
      context of a broader strategy.

      Offhand, I have a sense that when you're organizing a volunteer
      community working on their own time, distributed geographically, with
      no resources or management support for meeting in the flesh, the
      overall Scrum strategy of "inspect and adapt" makes all kinds of sense
      but the specific practices we know and love (Product Backlog, Sprint,
      Task Board, Scrum Master, Sprint Meetings, Daily Scrum) at best get
      transformed so much they're no longer recognizable as the original
      ones. (Where the situation resembles the corporate situation enough,
      e.g. Eclipse, you can get something to work that still looks
      recognizably like an Agile process, see Erich Gamma's keynote on the
      Eclipse process.)

      But, as it turns out, there's a bunch of smart people who have thought
      long and hard about the specific tactics (in the context of an overall
      strategy) for making a project work in this kind of situation. These
      people are the OSS community. It's well worth looking at what they've
      come up with, rather than dismissing it all as "orthogonal to Scrum"
      because "they have to be managed anyway".

      Cheers,

      Laurent Bossavit
      laurent@...




    Your message has been successfully submitted and would be delivered to recipients shortly.