Tuesday, August 7, 2007

Starting groups

My workplace moved to Agile development methodologies more than a year ago now, though it hardly seems that long. One of the techniques that was used in a few situations was to form a group and then allow the group to create the parameters, purpose and direction for the group.

This idea works well when used in the appropriate situation, but I think it had a less-than-optimal effect in some cases I was involved in. I'll describe those situations, propose an alternative group-start and finally end with where the "self-determining group" technique should be used.

The first time I encountered this technique was in the early introduction stages of Agile methods at our company. Some of the meetings were held using this technique to get the group to direct the presenter to the items that the group needed more information about. This did not work for two main reasons:

1) The audience was mainly people who knew nothing of agile methods, so had a poor understanding of the technique. Not knowing how to use the technique made things awkward.

2) The purpose of the meeting was deliver information to a group that is used to logic and structure (software developers). Going into the meeting, they all knew that they would be getting more information. Being asked to discover what the information was without knowing what it was seemed redundant.

Together the impasse is clear - the attendees were obliged to attend a presentation but were confronted with an unfamiliar process. I think such a meeting would work better a year later - the patterns are comfortably familiar.

The second time I encountered this technique was in the formation of an Agile "group". In this case, the technique was applied pretty successfully, but looking back I do not believe that it is the most efficient way to proceed. In the first meeting, this group had a purpose and dove into that head-long. By the second meeting, a split in the purpose became apparent. This was handled in an open fashion, quickly addressing the difference and the group moved on with an adjusted purpose. I think that the initial problems came partly from the fact that the group wasn't entirely self-selected. That is, some members were asked to attend instead of choosing to attend. The other reason for the slow start is that it seemed to take several meetings to work out all the details of what needed to be done.

What I hypothesized this was that a middle ground is needed to make things more efficient. The concept that the group needs to be self-determining is essential, so nothing should interfere with that. The only place left is in the initial group setup. Instead of proposing a group, organizing a meeting and then having the group decide everything from there, I think the initial proposal should include a sample framework. This would give more clarity to the purpose of the group and possibly save time if the group likes the initial ideas straight-away. If not, the group proceeds as before. I'll give a high-level example and a more concrete example.

The high level example is the idea of democracy. Some would like all decisions to be determined by vote, much like the earliest democratic ideals. Each citizen would have a vote and all decision would be taken based on voting results. Operating a modern democracy in this manner would be difficult because of the overhead. Instead, representative democracy allows representatives to work at some proposals and refine them before bringing them before the people. The one-vote-per-topic idea is like the self-organizing groups.

More concretely, let us say I'd like to start an Agile book club. The self determining method would see me send out a message saying "Agile book club is starting. First meeting Monday." The group would meet and begin the proposals for what the book club is about. Using the "proposed structure" method, I'd send out a message saying "Agile book club. Initial idea: Critique of sci-fi/fantasy books during weekly round table meeting. Please bring your proposals and ideas to the meeting Monday." This message conveys more information than the first, although it may bias what people think the purpose is. However I submit that if the attendees are comfortable in the Agile process, this would not prevent them from bringing their own proposals.

I think that the "proposed structure" methodology would work good in transition from a traditional work environment to an Agile one. With enough experience, the "self determining" method would work well, but until some additional skills are learned and techniques refined, it could be slower. The idea would be to encourage dialog and participation, but the mere lack of structure may turn many off. You need people there before you can accomplish anything.

If you've made it this far, you may have noticed how loosely tied this all is. I'll try and refine this idea in subsequent posts, but I apologize for my late-night incoherency. I did, however, feel it necessary to record the outline of the idea anyway.

No comments: