Categories

Tools

Open Source and Agile – oil and water?

My $DEITY, BarCamps are fun! I spent a great Sunday in Oxford, together with a bunch of fellow Apache-ans and my new colleague: the venue exceeded my expectations by far, with loads of informative content, great fun and amazing views of Oxford during the post-lunch walkabout.

I took the liberty to set up a session to talk about Open Source and Agility, which was actually a lame excuse to drag Marco to the stage and see if we could make sense of what seems to be a conundrum where Agilists and Open Source developers share the same values of openness, transparency and technical merit, yet we don’t seem to be able to come up with a way of working together (as in running Open Source communities with Agile practices, or opening up Agile teams to Open Development processes).

I used to blame Agilists for that, as their strong position on classical unities seems to be one of the major blockers: as long as the team has to be co-located, there goes your clash with any Open Source development model. Co-location has also been a major pet peeve of yours truly, as I believe it’s a model that doesn’t scale and is not fit to today’s work environments who are clearly moving towards asynchronous and disperse teamwork. Thanks Marco for reminding me how I was just being the classical fool that looks at the finger pointing to the moon. In Marco’s words:

I see little value in mapping exercises (being it mapping XP or Scrum practices to CMMi or Open Development or whatnot). I see value in discussing commonalities and differences in values and principles and drive everything else from there.

Or, to put it differently, there is little point in arguing practices and processes, which should always be means to an end. He conceded that I’m actually in good company, though, as a large majority of Agile/XP die-hards have long since been sticking to practices for the sake of practices (“no pair, no party”, anyone?), ignoring the tenets of Shuhari, where practices are considered drills you should adopt and rehearse so that you can pick, choose and evolve on what works best for you. With this in mind, it might be a good time to see what are the commonalities in the “ends” and if there are incompatible differences.

Marco points out how the biggest problem might be the lack of a customer to satisfy in Open Source communities, something I could subscribe to but only if I’m allowed to note how there are usually many customers around a successful Open Source project, with every member of the community reporting to a different patron – herself included – with different needs and different priorities. The standard Open Development response to what could potentially be a serious stopgap in terms of different interests acting in the same project and pushing in different directions is clear, though: on one hand, do-ocracy and his French-speaking twin JFDI does the trick, and on the other keeping discussions and basing decisions solely on technical matters help tremendously as well. At the end of the day, this means that the customer is there – it just happens to coincide with the community as a whole.

Is that enough? Not sure, but I subscribe to what Ross Gardler writes on slide 26 of his thorough Agile and Open Development wrap-up. There just has to be a way to make Agile and Open Development sing in harmony: Agile has enormous potential to deliver, and Open Development can provide amazing peer review and long-term sustainability. Losing either would be just foolish: as long as there is room for middle-ground, openness and flexibility, I’m sure we can make it happen. More to come.

Gianugo, we are in front of two successful development models. Open source development evolved as it is today without a strict use of pairing, co-location and sometimes without a clear definition of customer. This doesn’t mean that open source teams aren’t communicating, rapidly responding to change or lacking a continuous code reviewing process. Open source development evolved to fill these gaps with specific tools and practices. Similarly Agile solved typical corporate problems using a set of accepted practices.

An example. It doesn’t make sense to me to try to pair (by the XP book) with a remote developer full time (with what we have today). I’m using a practice evolved for co-location for a distributed context. What it makes sense is to screenshare on demand a few times a day. Is this better than pairing? No. Is this a compromise that works with limitations? Yes. At the same time, it doesn’t make sense to have 10 call conferences a day within the same company when we can stay all in the same room.

The good thing is that for problems that open source solved like distributed teams, Agile can borrow practices and vice-versa. So Agile and open source development are two different and successful processes with evident areas of overlap. So yes, horse shit with cow manure definitely is a great fertilizer!