Group Dynamics and the Agile Structure

Thanks to a tweet by Scott Hanselman today, I was reminded of how group dynamics can and do affect teams working in an Agile environment.

As I mentioned in an earlier blog post, I am going to be spending some time this year speaking about software development processes in general and agile in particular this year (I am really hoping that my TechEd talk gets approved this year, but so far it’s still in a proposed state, which doesn’t bode well). Much of my talks will focus on the Microsoft Solutions Framework (MSF) and the Microsoft Operations Framework (MOF). Before you can deep dive into any these topics however, there needs to be a higher-level understanding of how these processes fit into overall group dynamics and visa-versa.

Group Dynamics and their Agile Implications

When thinking about Agile software development, remember that one of the core values (first one listed on the manifesto as a matter of fact) is to value people and interaction over process and technology. This could well be one of the reasons that so many notable people talk about Agile not being viable for inexperienced developers. (I wrote a little about this in an earlier blog post as well – by the way I received notice from Visual Studio Magazine that they are going to publish my comments in the March Issue) In order for teams to work well together, they really do need to go through the various phases of team organization. If you subscribe to the theories of Bruce Tuckman (I am specifically referring to an article that was posted in the Spring of 2001) you know that these phases are:

Forming

When teams are in the forming stage, they are basically getting to know one another and are pretty much unproductive. In Agile methodologies (specifically thinking about MSF for Agile here) this usually coincides with the Envisioning phase of the project, so not only do you have team members getting to know one another and jockeying for their spot in the pecking order, you also have everyone trying to figure out just exactly what it is that they are building. The interesting thing (and if you read Tuckman’s article, I think he states it pretty well) here is that this phase isn’t really the chaotic phase. I know from personal experience that when a team is in this phase, it requires both strong leadership and an ability to not get bogged down in details for each of the team members. In my opinion, this is the hardest phase to get through, and I believe is one of the main reasons that Agile is seen as for “experienced” developers.

Storming

When teams enter the storming phase, they pretty much know what they are going to build but haven’t quite decided on how to build it yet. This is the phase where team members really start to challenge each other and where the team leader needs to start letting the team find their own way. Some teams never make it out of this phase (which is why many software development projects fail). In the MSF model, this phase usually occurs during the latter part of the planning stage in into the developing phase. In order to be successful here, team members need to understand how their individual strengths and weaknesses can work together to form a cohesive unit. In my experience this is where teams will experience the most chaos and will suffer the most.

Norming

In this phase teams start building trust and start basically getting the job done that needs to get done. When teams enter this phase, they are “good to go” and more readily accept change. One other very interesting dynamic in this phase is that team members start to become interdependent (and if you aren’t careful, codependent in that team members can start to rely on the unhealthy habits exhibited by some) . In the MSF model, this occurs usually in the latter part of the Developing phase and somewhat into the stabilizing phase. (To be clear, some teams never make it to the Norming stage, but the project goes on – there is no direct relationship between the team phase structure and the process phases). Generally speaking, I’ve found that teams in this phase exhibit the, “We don’t have time for the bullcrap” mentality and tend to take on more challenges. This is probably the most productive phase of all, and is the hardest phase to maintain.

Performing

In this phase, the team is self-sufficient and requires little if no supervision. As long as they have defined goals and objectives, the team can continue to function well in this phase. An interesting dynamic here is that new releases of previous products that have been built by the team can be entirely accomplished while the team is in this phase, meaning that the MSF Envisioning and Planning phases become almost invisible. The problem that starts to occur here though is the “normal” dissident and tension that is felt while the team is in the Norming phase (the challenging of ideas) tends to drop off, which means that products built by teams in this phase may not be as complete or revolutionary.

Applying the Phases

If you subscribe to my theory that all teams must go through the above phases, and if you can separate out the actual software development problem from the group dynamic problem, you can see that a team doesn’t necessarily have to be in one of the latter phases in order to be successful with Agile. A true software development leader should be able to focus on the people first and guide them through their “discovery” while making the process of software development almost invisible. I truly believe that even junior developers can be successful with Agile methodologies if the above is taken into account.