Supporting Teams through the 4 Stages

There are many different models of team development, but we have all probably come across Tuckman's "Forming, Storming, Norming, and Performing" approach. Recognizing that teams have a dynamic that changes and adapts as the team builds experience with projects and with each other is important for the project manager to realize. And as a group facilitator we can support the team and work with the process, rather than try to push a team when it isn't ready.

Forming

In the forming stage the team is being orientated to the task. Team members look to understand the task and how the group experience will be used to accomplish the task. It is important at this stage to set the team ground rules, so people can start to develop some structure that will support stability and security down the road. As well, this is the stage where teams are trying to build the shared mental model of the business and technical domain of the problem. Support by bringing in experienced business and technical resources to kickstart the process through workshops.

Storming

This is a phase of all teams; some teams move through it quickly and some stay stuck in the quagmire for a long time. It is a time where there is heightened conflict between team members. It is characterized by a lack of unity, and key issues may polarize the team. And the team does not benefit from the security of strong interpersonal relationships that come later as the team gels. Support the team during this phase by over-communicating. Isolating issues from the personalities, and fostering a senses of accomplishment by mitigating and solving these problems starts to build the collective sense of accomplishment. Sharing in the early successes, however small, will start to build a feeling of unity. Understand that teams will go through this phase, and productivity may naturally suffer. Don't ask too much from the team at this point, and allow for a ramp-up of task velocity or capacity to do work in the early stages of the project.

Norming

Here is where the team really starts to develop of group cohesion. There is a more open exchange of relevant interpretations. This boosts creativity through the inclusion of differing opinions, and the team starts to really generate results. For the project manager, your role evolves from moderator to team facilitator. Drawing from and standardizing on developing processes, and working to remove and isolate the team from remaining roadblocks will allow the team to get down to effective task development.

Performing

By now the team has developed strong functional role-relatededness. The team becomes a problem solving instrument. Roles are clearly defined and enhance the task activities. The group is effectively providing feedback and adapting learning to improve the performance of the team. Support the team by providing mechanisms for mutual performance monitoring (feedback sessions, project retrospective checkpoints). As well, the team can become effective champions of what works and what doesn't work in the organization and should be given the task of sharing the lessons learned and best practices with the rest of the organization, and provide peer reviews of other teams that may be earlier in the team life cycle.

I am always interested in hearing what others have done to work with the natural evolution of new teams.

Lessons from an inexperienced Agile Team

Silva and her team tested the idea that the best way to learn Agile methods is putting it in practice in some active project. They uncovered some important lessons that can be drawn on if you find yourself introducing Agile to an inexperienced team.

The team ran into a lack of proper infrastructure. It takes time to setup the team space, meeting rooms, desks and IT equipment, and ideally development hardware, software and physical and logical environments. Plan early iterations or time prior to the project kickoff to set up some of these basics so the team can hit the ground running.

Often teams have little knowledge in the agile development methodology. This can lead to mistaken planning at first and inefficient team processes throughout the project. As well this can be compounded by lack of familiarity in the used technology on the project. This leads to inaccurate task size and effort estimation and sequencing. Teams may need to focus early iteration on training and ramping up the team, or bringing experts to seed the team. The technical skills of the team must be evaluated before planning the project.

During the project the team may run into issues with the high level of dependency among functionalities. This is a symptom of failing to design upfront functionalities that have tight cohesion internally, and are loosely coupled from other functionalities. Where this is not possible, functionalities need to be isolated using stub code or mock interfaces to allow development to continue in parallel.

Communication is key during an agile project, and inneffective communication will be compounded through lack of regular face-to-face meetings. Teams need to get into the habit of meeting daily in the scrums, and with the key clients at iteration kickoff and checkpoint meetings.

Finally, distractions were caused by team members have responsibilities on other project. Full time allocation to agile projects is a best practice. While this is not always possible, it should be a goal for the key developers and testers.


____________________

Reference: Silva, Liana, Santana, Célio, Rocha, Fernando, et al. Applying XP to an Agile–Inexperienced Software Development Team 2008

Collaboration and Diversity

Teams “tend to perform better when members exchange knowledge freely among themselves and outsiders." (Hyashi, 2004) Diversity among team members leads to better performance because of the range of viewpoints and experience of the different individuals.

The importance of information exchange on teams and the importance of diversity was highlighted by Cummings (2004). Diversity comes from geographic locations, functional assignments, reporting managers, and business units.

Diversity has its drawbacks, and these need to be managed to mitigate the impact on the team. Geographic dispersion can greatly complicate team communication and work coordination (Hyashi, 2004).

Project Managers need to be explicit about the importance of knowledge sharing. What are some ways to improve collaboration and sharing? Here is a brief list of the highlights:

• Cross-functional workshops and requirement/development sessions
• Hold “Knowledge fairs” or information sharing sessions. Have key knowledge holders run a "brown-bag" lunch seminars
• Tie sharing of information to the team and the rest of the organization to performance evaluations based on how well team members exchange knowledge
• Ideally co-location of the team, or regular face-to-face checkpoints to build trust and connections
• Use of team collaboration tools such as shared databases, email, instant messaging, conference calls, web meetings to breakdown the geographic barriers
• Building corporate knowledge assets such as wikis, centrally stored lessons learned, guides, best practices, templates

How else can we support diversity on our teams, and knowledge sharing inter-team and within the organization?

______________________________________________
Hayashi, A. (2004). Building better teams. MIT Sloan Management Review, 45(2), 5.

Cummings, J. N. (2004). Work groups, structural diversity, and knowledge sharing in a global organization. Management Science, 50(3), 352.