Article: A Group Is Its Own Worst Enemy by Clay Shirky.
Clay is writing about social environments enabled by technology and what we have learned about groups from these environments. He points to several failed online communities as well as research pre-dating the Internet and points out “Three Things to Accept” and “Four Things to Design For”. Both lists are critical for us to map into Agile organizations. I have some thoughts on how to make the mapping to those Three Things to Accept.
Three Things to Accept… in an Agile Organization
1. We cannot completely separate social and technical issues.
In Agile, this is a recognition that having an open team room (and no offices), influences team success… and that team dynamics will influence the use and effectiveness of that team room’s space.
For an Agile organization, your organizational communication mechanisms such as email, telephones, video conferencing all play a role in how effective the Agile community becomes… and that the Agile community in your organization will change the way that technology is used to communicate.
One company I have coached has struggled with developing a strong community of internal Agile practitioners because there is no easy way for them to communicate in a collaborative manner. The corporate policies about networks, hardware, etc. make it very difficult to set something up in an ad hoc manner. Now, however, the needs of the internal Agile community have become strong enough that there is an effort to set up a wiki… but the organization has no idea what kinds of challenges that can open up. What will be the rules for using the wiki? Can people put stuff up that is “off-topic”? What constitutes acceptable material? Will it need moderation?
This relationship between the social aspect and the technological (or media) aspect must be accepted.
2. Members are different than users.
There may be lots of people involved in Agile projects, Agile training, Agile coaching, Agile management etc. in an organization… but not all of those people will be members of your internal agile community. Some of them will do it as their day job. And some will get excited and become leaders of the community. These self-selecting leaders must be nutured and supported.
You can identify these people because they will have ideas, attend lots of meetings, and generally want to be with other people doing agile in the organization. This should not be considered wasteful, but rather a natural extension of people’s desire for community. These people have an important role to play. Therefore a great deal of attention should be paid to giving them access to lots of training, exploratory implementations of Agile, etc.
3. The core group has rights that trump individual rights in some circumstances.
The self-selecting core group has to be protected. This does not mean protecting individual members of the core group. In other words, a member of the core group who for some reason starts to undermine the group or the Agile community should not be protected. Rather, the community needs to be protected, possibly by ejecting a member who is causing problems.
In societies where individual rights are considered the highest priority, this can be difficult. Unfortunately, if you want the community to survive, then you have to have some community rights that are stronger than individual rights. If on the other hand, as an organization, you truly believe that individual rights are most important, then you might not want to bother trying to create an Agile community… since it will fail (read the linked article for details).
Someday I might also write about the “Four Things to Design For” 🙂