Agile India.

Programming is “the action or process of writing computer programs”.

Programming by definition encompasses analysis, design , coding, testing, debugging, profiling and a whole lot of other activities. Beware Coding is NOT Programming. Depending on which school of thought you belong to, you will define the relationship and boundaries between these various activities.

For Example:

• In a waterfall world, each activity is a phase and you want a clear sign-off between each phases. Also these phases are sequential by nature with very limited or no feedback. Hence you are expected to have the full design in place before you can code. Else, what do you code?
• In RUP (so-called Iterative and Incremental model) even though it follows a spiral model with some feedback cycle every 3 months or so, one is expected to have the overall architecture of the project and a documented design (in UML notation) of the subset of use cases planned for the current spiral ready before the construction (coding) phase.
• In the unconventional model (where we don’t have process & tool servants and team members can do what they think is most appropriate in the given context), we fail to understand these sequential, rigid processes. We have burnt our fingers way too many times trying to retrofit ourselves into this sequential, well-defined process boundaries guarded by process police. So we have given up the hope that we’ll ever be as smart as the rest of the “coding community” and have chosen a different route.

So how do we design systems then?

• Some of us start with a test (not all, but just one) to understand/clarify what we are trying to build.
• While others might write some prototype code (read it as throw away code) to understand what needs to be build.
• Some teams also start by building a paper prototype (low-fidelity prototype) of what they plan to build and jump straight to the keyboard to validate their thought process (at least once very few hours).
• Yet some others use plain old index cards to model the system and start writing a test to put their thoughts in an assertive medium.

This is just the tip of the iceberg. There are a million ways people program systems. We seem to use a lot of these practices in conjunction (because they are not mutually exclusive practices and can actually be done in parallel).

People who are successful in this model have recognized that they are dealing with a complex adaptive system (CAS) and not a complicated system, where you can define rigid boundaries and be successful. In a CAS, there are multiple ways to do something and if someone makes a claim that you always have to do X before Y, we can sense the desire of putting rigid constraints which by nature are fragile. This is the same reason why there is no such thing called Best Practices in our dictionary. Instead we keep an eye on emerging patterns. If we want to see a particular pattern impact the system, we introduce attractors. But if we don’t want a pattern to impact our system we disrupt that pattern. (rip-off from Dave Snowden, creator of the Cynefin model and leading figures in Knowledge Management Community)

The open source community in general, is yet another classic example which fits into the unconventional category. I’ve never been on an open source project where we had a design phase. People live and breath evolutionary design. At best you might have a simple wiki defining some guidelines.

Anyway, I’m not saying that upfront design is bad. All I’m saying is don’t tell me that one always has to design first. In CAS, you tend to “Probe-Sense-Respond” and not “Analyze-Respond”. In software a lot of times “Action precedes Clarity”.

Today I’ve decied to leave an old friend behind. I really cannot keep up with SF’s speed any more. Its time to move on. I’m slowly going to move all my open source projects to Google Code or GITHub.

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.