Summary: Forming, Storming, Norming, and Performing. No, they are not a law firm, but the stages of team development proposed by Bruce Tuckman in 1965. I wish I had known about this model much earlier in my career. If you haven't encountered it before and want to help your requirements team, read on.
Part of the challenge of requirements work is transforming a diverse group of stakeholders into a productive and efficient team. Tuckman proposed a staged model of team development that has stood the test of time. Understanding this model can improve the quality of stakeholder communication and lessen the time spent developing an effective team.
In brief, the team development stages are:
- the team is meeting and greeting
- everyone is polite
- some stakeholders are excited
- there is no obvious conflict
- nothing important is decided
- differences surface in viewpoints, priorities, and style
- confusion and disagreements about team objectives, priorities, organization, and
- strategies are obvious
- suspicions and impatience appear about team members and the project
- misunderstandings are frequent
- there is little progress
- common understanding and respect begins
- criticism is expressed thoughtfully and constructively
- consensus forms on work rules, goals, boundaries, roles, and strategy
- improved listening and open sharing
- a foundation for cooperation is created
- cooperative relationships are established
- the focus is on major issues and important tasks
- team pride increases
- work is getting done
- substantial progress is made
This model certainly describes my experience with teams of diverse stakeholders. For example, from personal mistakes, I now understand that it matters a great deal when proposals are introduced to the team. The team may reject a proposal, for example about work product development strategies, introduced in the Forming stage before context and trust have been established. Rejection often includes wasteful discussions filled with misunderstandings. If the same proposal is introduced in the Norming stage, the team may accept it with little discussion.
Effective communication requires that the receiver be ready for the message. Now I know that warm bodies in a room is not a sufficient indicator of readiness to receive.
The relative calm of the forming stage provides the team leader with an opportunity to define expectations and behavioral ground rules that can help the team negotiate the remaining stages. An expectation is that the team will learn a great deal during requirements development. The team will never know less than it does at the beginning. Admitting that requirements development is a journey out of ignorance by means of an exercise in group learning helps the team deal with the doubts of development.
You may find it effective to charge each stakeholder with two major responsibilities: to learn and to teach. Stakeholders must not only learn about requirements, but about each others viewpoints, priorities, and styles. This learning needs active listening and suppression of quick judgments.
The teaching responsibility entails sharing experience and expertise to enable other team members to understand some of the reasons behind suggestions made by the member who is teaching. Without minimal teaching, suggestions become commandments and the expert must always be right. Without teaching, there is little room for discussion on many issues and when needed, negotiated compromise is difficult since no side can understand the reasoning of the other. Team acceptance of their learning and teaching responsibilities smoothes the transition through Storming and Norming.
A variant of the Tuckman model is Forming, Storming, Ignoring, and Pretending. During these stages:
1. Forming – [Same as Tuchman model]
2. Storming – Uncovers or should uncover major conflicts in goals, priorities, or strategy among critical stakeholders
3. Ignoring – Fails to either resolve the conflicts or halt the project
4. Pretending – Follows the protocols of requirements development with little hope of project success