In my last post, Open Space (OST) and Open Source(OSS), I’ve highlighted some core fundamentals (values) of OST and OSS. After reading it, you might be thinking, boy, I really want my software project to be built on these fundamentals. Agile Software Development is really a step in this direction. A lot of people including myself have talked/presented about OSS and Agile. There are lots of similarities between them.

When Deb and I were organizing the first Agile Coach Camp conference, we invited John Engle to facilitate the open space. During our discussion about theme and target audience, we were explaining John how Agile works and he was surprised how fundamentally (at the values level), both Agile and OST were similar.

At the Agile 2008 Conference in Toronto, Dennis Byrne and I facilitated a panel on Agile and Open Source. It was a slight twist on this topic. Our panel was proposed under the “Questioning Agile” stage. Our panel was titled “Successful open source projects with little or no Agile”. We were really questioning if Agile is the only way to build software? Agile Software methods like Scrum and XP are getting more and more bloated. Checklists and templates have emerged. God knows what all crazy stuff folks have come up with in the name of Agile. But one thing that no one talks about really, came out of the panel. While there is some amount of volunteerism built into Agile, it has a long way to go compared to OSS or OST. Agile projects can be structured around Volunteerism and my belief is it’s really going to help.

In some organizations I’ve worked, we have had good success with corporate sourcing model. Once various project teams get into the rhythm and start building their products, the next issue they hit is to collaborate with other teams across the organization. I call this, the teams are being good tribesman. But now they need to be good citizens also. In corporate sourcing model, the core team acts as committers on the project, while anyone in the company can suggest features or contribute code patches. Volunteerism comes in because people have freedom to work on other projects that really interests them. In companies like Google, its a little more structures. They have the 80-20 rule. Where in your 20% time you can work on stuff you like. Another way to encourage volunteerism.

A lot of companies have a big problem, because they have some existing projects and they have some new projects. Most developers want to work on new, green field projects. Rarely anyone wants to maintain existing projects. But those projects are very critical to the company and the company cannot move all developers on new projects. What do you do in this situation? Morale of tea members maintaining existing projects is really low. But they do have some spare time and tons of idea which can really help new product development. The way I have seen some companies solve this problem is, they either set up a rotation program where team members from maintenance projects can choose which project they want to work for on a rotation basis. In some other companies, I have see, team members are allowed to contribute code patches or suggest new features to the new projects in their spare time.

There are various ways to encourage volunteerism in your organization. Not just at project level, but in other ares as well. If someone is interested in marketing or sales or training or recruitment, companies can use their valuable contributions. In most cases this creates a win-win situation. This also helps folks to shape their career and become all rounded individuals. More the number of roles a person can play, that much more valuable they become to the organization. So remember, volunteerism in very important not just in your project but also at your organization level.

Both, Open Space Technology (OST)* and Open Source Software (OSS) are structured around volunteerism (.i.e people are the center of the universe). They really encourage people to step up and help. Volunteerism applies at many levels.
In OSS,

• you can author a piece of software and put it out to help others OR
• you can join an existing project and contribute to it.
• you can use the software and give feedback to the authors. Filling in a bug report or requesting an enhancement is a great way to participate in this movement. There are million ways to contribute to OSS, you can write some user document for the project or give a demo to your local user group.

Similarly in OST, you can propose a topic and be a facilitator or participate in a topic proposed by someone else or blog about your thoughts.

With Volunteerism comes responsibilities and rights. You have the right to participate and contribute. If you don’t like the direction in which its going, you have the right to leave or spawn off something that is how you would like it. This very behavior leads to exploration and discovery. Hence leads to innovation. While the participants have all these rights, they are generally good citizens and are very responsible & self-disciplined. You can really see a touch of craftsmanship in their work.

In my experience both these approaches are amazing at how they can involve/engage people. In OST we say,

“Who ever comes it the right people and whatever happens is the best that can happen”.

This holds true for OSS projects as well. You can’t really force somebody to contribute. Based on my experience the core for both is passionate people.

From the outside, both OST and OSS looks very chaotic in nature. One has to act, sense and respond. When someone throws open a piece of software, they have no idea how it would evolve or even if it will interest anyone. They have to act first by putting it out there. After that based on the feedback from the community (sense), the author/s have to respond. Project which are able to do this, see a big user community around it and hence innovation. Same holds good for OST topics.

Even though we try to put some (very limited) structure around them, both OST and OSS by nature are very self-organizing, self-emerging and self-adjusting or self-correcting. They also have a self-filtering nature. Its easy to leave non-passionate and undisciplined people behind. Nor are these hero-centric systems. Also the moment we try to put too much structure or process around them, they tend to break down. They don’t necessarily fail, but evolve into something very different in nature and the kind of people around it. In OST we say,

“It starts when it starts, it ends when it ends”.

Topics in OST and features in OSS evolve over a period of time. One thing influences another and another influences some third thing. This very nature makes it very adaptive. Adaptive systems are here to stay, rigid systems will soon be extinct.

* Don’t get confused with the word Technology in OST. In this context Technology means tool. Its really a meeting/conference format.

At the Agile Coach Camp, John Engle, the Open Space Facilitator, introduced us to Sticky Walls. If you are running a large open space event or in your office you want a large area to stick stuff up, sticky walls can be ideal.

Basically its a large 5′ x 12′ sticky cloth on which you can stick anything without any glue.
 

The beauty of this cloth is, its really light weight, which means you can take it anywhere. It can be easily put up on a wall or door or where ever you want without now you having to worry about spoiling the paint. The sticky wall also comes with an adhesive spray, which can be used to create and replenish your Sticky Wall. 

If you want to buy them or for more info visit : http://ica-usa.org/store/products.htm