Home > Open source, Openstack, Ubuntu > Agile vs. Open

Agile vs. Open

January 21, 2011 Leave a comment Go to comments

I’ve been asked multiple times why open source project management does not fully adopt agile methodologies, which are so great. Or what are the main differences between the two.

Agile is good for you

So first of all, I’d like to say that I think Agile methodologies are great. Their primary value to me is to allow software development groups to handle their stakeholders requirements in a sane way. By involving developers more in the center of game, they contribute to use Autonomy (one of the three main intrinsic motivators that Dan Pink mentions in his book Drive) as a way to maximize a development team productivity.

Agile vs. Open

That said, applying pure Agile methods doesn’t really work well for open source project management. Some great concepts can be reused, like frequent time-based releases, peer review, or test-driven development. But most of the group tools assume a local, relatively small team. Doing a morning stand-up meeting with a team of 60 in widely different timezones is a bit difficult. It also assumes that project management has some direct control over the developers (they can pick in the backlog, but not outside), while there is no such thing in an open development project.

The goals are also different. The main goal of Agile in my opinion is to maximize a development team productivity. Optimizing the team velocity so that the most can be achieved by a given-size team. The main goal of Open source project management is not to maximize productivity. It’s to maximize contributions. Produce the most, with the largest group of people possible.

That’s why open source project management is all about setting the framework and the rules of play (what can get in trunk and how), and about trying to keep track of what is being done (to minimize confusion and friction between groups of developers). That’s why our release cycles are slightly longer than Agile sprints, to have a cadence that is more inclusive of development styles, and to enforce time to focus, as a group, on QA before a release.

Agile devs in Open source

It’s difficult for Agile developers to abandon their nice tools and adopt seemingly-more-confusing open source bazaar ways. But in the end, I think open source is more empowering, by addressing the two other Dan Pink types of intrinsic motivators, Purpose and Mastery. Working on an open source project and contributing to the world’s amount of public knowledge obviously gives an individual a sense of purpose to his work, but even more important is mastery.

Each developer in an open source project actually represents himself. With all proceedings and production being public, in the end his personal name is attached to it. He builds mastery and influence over the project by his own actions, not by the name of the company that pays his bills. Of course his employer has requirements and usually pays him to work on something specific, but the developer acts as the gateway to get his employer’s requirements into the open source project. That way of handling stakeholders requirements places individual developers at the very center of the game, even more than Agile does. You end up with the highest number of highly-motivated individuals, which in turn leads to lots of stuff getting done.

Agile subteams

Finally, nothing prevents an open source project to have Agile development subgroups contributing to it. These subgroups can have user stories, planning poker, feature backlogs, pair programming and stand-up meetings. There are multiple challenges though. Aligning agile sprints with the open source project’s common development schedule is tricky. The Agile work schedule needs to be adapted to make room for generic open source project tasks like random code reviews or pre-release QA. Some other group may end up implementing a feature from your internal backlog, and communicating the backlog outside the group can be bothersome and challenging.

I’d like to find ways, though. What do you think ? Can Agile and Open live in harmony ? Should they try ?

Categories: Open source, Openstack, Ubuntu
  1. January 21, 2011 at 11:30

    Hi Thierry,

    they could, when the contributors and team members are equal.
    Means, when they can work fulltime on a project.

    Especially when you want to use management frameworks like SCRUM.

    Regards,

    \sh

  2. Tom Marble
    January 21, 2011 at 16:00

    Thierry:

    I tend to differ from @sadig in that my experience
    in using strict Scrum for a commercial, Enterprise
    product development team of 500+ developers in
    every major time zone highlights the differences
    between closed an open.

    The promise of Scrum is to provide a dashboard
    in full acknowledgment that software development
    time estimates often wrong. The regular review cycles
    and re-prioritizations do, indeed, help get an
    understanding of team velocity. And this process
    can help product owner’s make important prioritization
    because they cannot, in fact, have it all.

    However there are several underlying assumptions
    that make the model fragile:
    – Team composition rarely changes
    – Developer skills stay fairly constant
    – Complexity (i.e. deep technical knowledge required for) backlog
    items stays fairly constant
    – The backlog prioritization is immune to “gaming” by
    “super” product owners.
    – Key stakeholders (developers, owners, scrum masters, usability
    experts, publications, Q/A) communicate as if they were
    co-located in the same room.
    – Maintenance of previous releases and bug support
    is handled by other teams (or is predictable)

    And even at this Scrum does not provide engineering
    management with guidance on how to manage velocity.
    Ultimately you hire developers because what you really
    want to do is to increase project velocity. Accountability
    for velocity starts at top engineering management, but
    Scrum doesn’t give her tools to translate burn-down
    charts to personnel coaching/changes.

    I agree that open development should reuse the great
    concepts you mention (time based releases, peer review, TDD).
    Beyond these a successful open development process needs to coordinate
    efforts in full acknowledgment that the community is
    comprised of many multi-talented, geographically
    and cultural diverse contributors. In other words we
    need an agile process that is analogous to addressing
    the Peter Deutsch Fallacies of Distributed Computing.

    In summary I don’t think that *closed* and Scrum live in harmony.
    What makes *open* strong is transparency and agile attempts
    to bring transparency to project management. Open needs
    to embrace it’s own transparency and harness community diversity.

    –Tom

  3. Bruno Girin
    January 21, 2011 at 20:31

    I totally agree with you: Agile and Open are based on different principles so don’t naturally fit together. Jonathan Rasmusson agrees with you in his excellent Agile Samurai book (http://www.pragprog.com/titles/jtrap/the-agile-samurai) by pointing out that agile works best with a small co-located team, which obviously is not the way open source typically works.

    One way to make it work would be to have small co-located agile teams. Each team would work in their own branch and would merge each feature back to trunk, or submit it as a patch, once it’s finished (rather than deploy in production). To simplify communication with the rest of the project, they should use the project’s bug/feature tracking system as their backlog, each entry in it that is assigned to the agile team becomes an individual user story. That way the agile team’s backlog is not internal, everybody has visibility on it and there is no need to spend time communicating it outside of the team.

    From the agile team’s point of view, it will work better if the project has a stable release cycle that is a multiple of the team’s sprint. E.g. if the team works in 1-month sprints on a project that has a 6-month release cycle, it means that they group their sprints in blocks of 6 and in each block, the first 3 sprints are dedicated to major features while the last 3 are dedicated to small changes and bug fixes. It’s all about taking into account their environment (aka their neighbourhood as Rasmusson calls it): in a traditional environment, it would be external teams such as technical writers, infrastructure, etc; while in an OSS project, it would be the wider project.

    Having said this, I think there are more similarities between Agile and the Open bazaar than between Agile and the traditional cathedral-like waterfall so it should be possible to make it work.

  4. April 25, 2013 at 16:16

    Hi Thierry,
    What you are describing is what we are doing in XLcloud (www.xlcloud.org). Well, more or less.
    Because we have nine teams in different locations, and some are working with Agile methodology (some full with a high level expertise, some light…) and others not.
    And our project is open source. So we are contributing or on the way to contribute to some open source projects such as OpenStack (which is an important component in our project).
    We use tools such as Jira in a Sprint-oriented process to help us track what we do in an open source philosophy.
    In the end that all works quite well and we enhance the process along the time. I would like to say that we take the best of those both ways to work.
    Regards.

  1. April 2, 2011 at 17:19
  2. November 12, 2013 at 04:47

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s