Re: [scrumdevelopment] Manage the Distributed Open Source Projects with Scrum
- 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.--
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.AlanOn Wed, Nov 10, 2010 at 6:14 PM, Laurent Bossavit <laurent@...> wrote:
Hi Alan,That's understating how the situation differs from your usual
> 2. The lack of financial incentive.
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
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:So that seems to be a definitional argument. "Open Source is an X,
> Open Source is not a project management framework or process. It is
> not comparable to Scrum but orthogonal to it.
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
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
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".