SCRUM and volunteer developers

SCRUM development process

SCRUM development process

Funambol engineering team uses the SCRUM methodology to develop software. It’s a very interesting method that seems highly compatible with free/libre open source software development habits. It mandates fast release cycles (like the release early/release often mantra), teams that can self-organize. SCRUM also mandates fixed time (2 to 6 weeks) to complete a development cycle (called iteration or sprint). This last part doesn’t seem to be very compatible with contributions by volunteers.

I’ve been looking for other free software projects that use SCRUM internally to understand how they involve external contributors, volunteers, in strictly time constrained release cycles. Pentaho wiki has a very interesting paper on the topic, but I still don’t understand if they have established a process to assign user stories to volunteer contributors.

I wonder if some have tried and failed or nobody has ever tried this at all.





  1. Another problem might be the communication with people who cannot participate in the regular meetings that are part of the SCRUM methodology. At least the goals for the current sprint are now publicly communicated, but external contributors still miss a lot of what goes on in the daily meeting and cannot bring up issues there themselves.

    This is *not* a call for meeting minutes or phone conferences – that would defeat the whole purpose of these brief, informal get-togethers, I suppose. I’m just mentioning it because it would indeed be interesting to find out how this can be combined with an open source project that has external contributors.

  2. That’s correct, another problem to address. There should be a way to bend/adapt the method in order to be compatible with the needs of the free software contributors. We’ll keep experimenting.

    I’m glad you appreciate the publicity of the sprint user stories.

  3. Communication is a key aspect in opensource development. I am not sure it is very tightly related to scrum, but more to how the team is structured (friendship, location, language). But it is definitely true that scrum like the other agile methodologies encourage a lot personal communication. The purist are for real-time, f2f communication, which is something not very applicable in open source.
    For this reason the issue of loosing a lot of such fluid intra-team communication is real. One idea I am playing with is that an open source community of developers is … a communitty… a social community. The idea I am working with is that a social network-like site would tremendously help open source development in general, but open source agile development specifically.

  4. I agree with you Stefano: communication is a key aspect. Email is only one tool, but it’s too asynchronous to replace f2f communication. ‘Modern’ IM are better for two ways conversation. We could use more the Funambol IRC channel on, but that’s not enough either because conversations tend to get lost. I’m experimenting with groups, which are very promising. I’ll write something about this in a few days.