Team norming and chartering
Posted by Martin van Vliet in the late afternoon: March 15th, 2008
Staffing a new project is always a challenge. Juggling availability, experience and personal preferences, the proper mix of people has to be found that can make the project successful. Once this has happened, the project can get going and the newly formed group is expected to get on with the business of creating software.
One thing that is often forgotten is that the "project team" really isn't a team at all yet -- they are a group of people who have been put together to accomplish a goal. Chances are that at least some of the people have not worked together before and that there is no common ground for them to become a team. According to Bruce Tuckman, their evolution as a team can be divided into four stages:
- Forming
- Storming
- Norming
- Performing
Forming
When a team first gets together, it enters the forming stage. Team members are usually on their best behavior, working mostly independently. The team members get to know each other and learn about the project goals and issues.
Storming
In this stage the team members open up to each other and confront each other's ideas and perspectives.
In some cases this phase can be resolved quickly, depending on the maturity of some team members. Immature team members will begin acting out to demonstrate how much they know and convince others that their ideas are correct. This phase is necessary to the growth of the team, but can be unpleasant to members of the team who are averse to conflict.
Norming
When a team enters the norming state, team members adjust their behavior to each other and agree on how to work together.
Performing
Some teams will reach the performing stage at which point the team is able to function as a unit and finds ways to get the job done smoothly and effectively without inappropriate conflict or the need for external supervision. Team members have become interdependent.
Team norming and chartering
To assist in the norming stage, it helps to conduct a facilitated norming session with the entire team. In this meeting, the team performs two activities. The first, team norming, serves to establish working agreements that enable the team to work together. Rules, values and professional behavior fall under this heading. Team chartering, the second activity, deals with shared methods and tools. The resulting agreements should be prominently posted (on the wall or a Wiki) and be visible to everyone. These agreements provide the basis for effective team work and can be referred to in the case of disagreements.
As an example, here are some agreements the team came up with when we held a team norming session at one of our project:s:
Norming example
Core Hours
- Everybody should be present from 9h30 - 16h00
Technical Discussions
- Important discussions should be in core hours, to prevent absentees.
- Results from the discussions should be on the wiki.
- White boards sesssions should be documented on the wiki.
- The format used for this should be: Problem, Rational, Solution, Other discarded options.
- Absentees should:
- Trust the rest of the team.
- Reopen the discussion (after reading all documentation) if they strongly believe a mistake has been made, with a representative of the group that had the original discussion.
- Whiteboard discussions should be on skype (with the offshore team) when possible.
Cell phones
- Cell phones are on during working hours
- Personal calls are taken outside of the team area
Chartering example
Code Quality
- Everybody should check the code quality when they check in code (use CCs maven reports).
- Everybody can suggest changes to quality standards.
- We strive to prevent technical debt.
- Discuss refactorings with as many people as appropriate (could be just pair).
- Try to include refactorings in the User Story.
- Balance refactoring with adding new functionality.
- Javadoc: We follow the company checkstyle standard.
- We have a standard header, which contains a copyright notice.
Quality targets
- Test coverage: 90% overall. UI code should be tested by other means (logic should be unittested).
- We strive to get the number of checkstyle violations as low as possible.
Continuous Integration
- We try to check in at least once every day
- If the build breaks, we fix it as soon as possible
Conclusion
In my experience, team norming and chartering helps to give a newly-formed team some common ground from which to start. Open discussion of the practices and processes used to develop software ensure that everyone has a chance to contribute. The results from such a session can be referred to in case of disagreements and when new people join the team.
Archives
Training
- Workshop Agile Management
Custom made, in-company
Xebia Sites
Categories
- Java (279)
- Agile (109)
- General (50)
- Testing (42)
- Performance (42)
- Hibernate (36)
- Scrum (33)
- Podcast (31)
- Architecture (31)
- Spring (28)
- SOA (24)
- Maven (22)
- Project Management (22)
- Flex (17)
- JPA (17)
- Eclipse (15)
- Quality Assurance (14)
- Middleware (19)
- Frameworks (13)