Agile and Open Source: Unrelated or Kissing Cousins?

From The Agile Management Blog, via Brandon:

Hence, the purpose of tracking customer-valued work (using a product like Team System) and reporting on it transparently for everyone to see, is to provide an opportunity for open objective discussion about problems and the policies that may be causing them. Surprising large amounts of waste are caused by policies. The case study from XIT Sustained Engineering showed that almost 60% of capacity was being wasted through policies that were within the power of management to change.

I’ve been thinking increasingly about how Agile Software Development and Open Source Development are, if at all, related. One of them doesn’t necessarily require the other, and they’re not wholly compatible. In fact, many aspects of each contradict each other. In large part, this is because the two development practices are founded on different concerns:

• Agile Development starts with the idea that the people and organization you have is flawed and far from perfect. Your people are not rock-stars and your organization is “political” (see above). Good enough, rapid, and changing due to feedback are key concepts.
• Open Source Development starts with the idea that your people are good and organization will emerge as needed. Transparency, meritocracy, and free to redistribute are key concepts.

Troubles with Transparency

Certainly, transparency is a key concept in Agile, but it organizations don’t seem ready to fully take on transparency. Failure is still seen as a bad thing instead of a good thing. I’m not casting out transparency from Agile, I’m just saying it’s the most problematic aspect of actually implementing it in closed source shops.

The open source world won’t tolerate an opaque process. More importantly, there are no bonuses or politics to worry about. If some process is stupid or someone is a numb-skull, they’ll be called out.

Corporate Sandals

Indeed, this is a weird difference between the two: Agile can be very embracing of people, no matter what their skill level is. Paired programming is the ultimate expression of this thinking: you have to think that programmers are, by their nature, fixable to accept paired programming. Otherwise, if you one of the pair members is goof, they’ll forever be a time suck on the smarter member of the pair. Instead, the thinking is that the smarter member will help “fix” the dunderhead.

Open source development isn’t quite a favorable: you have to prove yourself before you’re allowed to commit code. There is less of a “as long as I learn I will make mistakes” ethos. Which is fine and, indeed, helpful in most cases.

Geo-located

The hugest difference that I wrestle with is the question of collocating the team. Agile, of course, goes for the One Big Room theory which states that having all the team members in one room is the biggest benefit. Cockburn, as usual, has done a great job in revealing the true thinking behind the One Big Room concept: it isn’t a truth so much as a tactic.

That is, goodness doesn’t come from having everyone in One Big Room, instead it’s a way of fixing common problems in software development. If you don’t have those problems — unclear communication, unrealistic deadlines, changing requirements, dispassionate team members, etc. — you may not need to put everyone in One Big Room.

Which is where open source is: there is no room, except the IRC room. The question, though, is: would open source development be better if everyone was in One Big Room, or worse? Or the same?

Other Differences

There are several other differences, but those are the two that stand out in my mind time and time again: self-selecting meritocracies and One Big Room. I come from the commercial software world, so my views of open source development are often anecdotal and apocryphal. As such, I’d love to hear from people who know more. What do you think?

Technorati Tags: agile, opensource, peopleware, programming