When compared with the waterfall model Scrum is obviously much more dynamic and flexible. From an open source perspective Scrum has definite advantages over cowboy-style development:
- Open source and Scrum are based on a similar set of principles (early and often, transparency, openness)
- Scrum maps closely to commonly-used practices in open source like the creation of milestone versions.
- Scrum Teams are typically small. The core-developer teams of open source projects are typically small.
- The usage of Scrum for open source projects would introduce much-needed consistency, terminology, and a well-defined but light-weight structure.
- Scrum Teams are self-managing and self-led. Core-developer teams in open source projects are self-managing and self-led.
- The Scrum methodology does not need large up-front efforts before development starts.
However, from an open source perspective, the Scrum methodology presents some problems. These problems stem from assumptions that Scrum makes about the nature of the team and the nature of the stake-holders. Most, but not all, of these assumptions are valid for the non-open-source projects that use Scrum today.
The Scrum methodology prescribes that Sprint lengths should be 2-6 weeks. This is based on an assumption that the Scrum Team is a full-time team. This is fine for open source projects that have full-time committers and commercial open source projects but might not be effective for open source projects with small teams or solo developers. I propose that Open Scrum allow the Sprint lengths to be a little more flexible.
The Scrum methodology prescribes that Scrum Team should be physically located close to each other, ideally in the same room with no cubicles or partitions. This is fine for some commercial open source projects but is not possible for the majority of open source projects. Collaboration tools such as instant messaging (Yahoo, Jabber etc) or voice over IP (Skype etc) need to be used effectively in the absence of face-to-face communication.
The Scrum methodology does not include the notion of a community. The community could simply be classified as a stake-holder in the Scrum model however there are problems with this approach. A significant factor when dealing with community participation is that community members cannot be scheduled. As a result it is not realistic to expect the community to participate in the process the way that Scrum describes it. In addition the Scrum methodology assumes that the software has a set of stake-holders that are engaged throughout the entire release whereas in reality an open source project has participants that are often engaged for much shorter periods (days or weeks).
Due to the openness and transparency of open source projects it is possible for the community to act during a Sprint as stake-holders, customers, and an Extended Scrum Team. That is to say that acceptance testing can take place in parallel to development if the community is sufficiently engaged and enabled.
No Hardening Phase or Acceptance Testing
The Scrum methodology assumes (as do most software development methodologies) that the software can be completed prior to the customer or consumer using it. The iterative and empirical nature of Scrum is a significant improvement over the rigid and deterministic waterfall methodology however the Scrum methodology aims to deliver 'complete' features at the end of each Sprint. Scrum does not describe how to react to feedback from the customer/consumer once they have possession of the software. It does not describe how to combine acceptance testing with subsequent Sprints. Henrik Kniberg, in a practical guide titled 'Scrum and XP From the Trenches' describes a couple of different approaches to this that work in non-open source environments. The critical difference for open source projects is that there is no single customer or stake-holder and it is not possible to schedule or time-constrain acceptance testing. The 'openness' principle of open source accepts and encourages this feedback at all times however without visibility into the use cases of the community it is difficult to translate this feedback into 'acceptance' as in many cases it is a lack of feedback that signals acceptance (see Lack of Positive Feedback above).
Scrum uses the term 'Product Backlog' to describe the features of the software that have yet to be implemented. This term is apt in a traditional scenario but the word 'product' is less desirable from an open source perspective. The word 'product' is sometimes used in contrast to 'software' to imply a deliverable that is complete with training, marketing, support etc. The word 'product' implies something more than a library, or function, or utility. In most cases the output of open source projects does not, and has is not intended to, include these things that 'product' is used to describe. I think that the term 'Feature Backlog' is more accurate and descriptive than 'Product Backlog' in the context of an open source project.