Work in Small, Stable Teams
Research shows that smaller, stable teams that maintain the same team members outperform other configurations. These teams create the necessary foundation for a learning organization.
- Confusion from constantly reforming new teams and changing team members
- Any given team always lacks some particular expertise
- Lack of institutional memory
- No growth in domain expertise in the team
- No team knowledge of historical bugs and releases
- The team constantly rediscovers issues
- Organizational/tribal memory increases and is more resilient to individuals leaving
- Higher performing teams
- Increased team trust
- Reduced turnover rate
- Lower training costs (stable teams retain domain and tech expertise)
- Teams continue to exist after product / project work. New work gets routed to the team (100 pts)
- Teams experience slow turn over (<10% per year), supporting learning and trust (50pts)
- Teams change more than 10% per year (-50pts)
- Teams change at the end of every project/major product delivery (-100pts)
- Teams change randomly, at odd times, based on some emergency, and again at every reorganization (-500pts)
✓ Critical ❑ Helpful ❑ Experimental
Steps to first adopt this practice:
- If your organization hasn’t yet adopted a small team approach, start with one team:
- Find an area or product the team can take ownership and responsibility for developing
- Ensure you can give the team an area that has no or very few dependencies on others for delivering working software
- Focus on the initial enabling team conditions (see below for explanations):
- Real Team
- Compelling Purpose
- Right People
- Organizational Support; the hardware, tools, and environment needed by the team
- Ensure the team has an opportunity to develop team agreements such as TeamWideInteruption and that they can discuss how they would like to organize tasks and deliver work
- Use RemoveProxiesToPeople to connect the team with those who use the delivered features
- Ask the team to start breaking down work into small components that can be delivered relatively quickly (a couple days to less than a week) and begin working on delivering these business capabilities.
- Monitor the team’s progress using MeasureActualDelivery.
- Monitor the team’s process by visiting the TeamSync. Remember your presence may influence the team’s behavior due to the Observation Bias (also knows as the Hawthorne Effect).
- What do you notice about the progress and process?
- What surprises you?
- Did you get the enabling conditions close to correct?
- What might you change before bad habits and dysfunction become habitual?
- Consider using a third party (another manager, team lead, external coach…) to get impartial/unbiased feedback from the team on how they think things are going.
What Does it Look like?
You can increase the the probability of success by paying attention to the team enabling conditions. Research shows that small stable teams have higher productivity.
This results from more openness, transparency and trust compared to larger groups.
When teams get around 10 members they tend to subdivide. Keep the team size to 4-9 members. When possible, 4-6 members can provide more productivity than larger numbers.
Stable does not mean unchanging. The productivity tends to peak around three years then declines as the team becomes set in their ways and insular. After a while, plan to slowly change the team membership. This will introduce new ideas and fresh perspectives.
Complex systems are sensitive to initial conditions; therefore you need to pay attention to team setup and the initial start.
I propose that 60 percent of the difference in how well a team eventually performs is determined by the quality of the prework the team leader does. Thirty percent is determined by how the initial launch of the team goes. And only 10 percent is determined by what the leader does after the team is already underway with its work.—J. Richard Hackman
Create a Real Team. Real teams are bounded. Members know who is on the team, and who isn’t. Their work is interdependent. They all must succeed for any of them to succeed. The team membership is stable.
The team needs a Compelling Purpose. Their reason for existing must be clear, challenging, and consequential.
The team needs the right people comprising its membership. This includes their ability to complete the necessary tasks, the ability to work together, and complementary training and experience.
The team needs clear Agreements for conduct. While the team creates its TeamAgreements, you might want to ensure the agreements cover topics such as behavior, dealing with impediments, how to view the work, and how to improve their performance. To repeat, the team creates its agreements. Telling smart people how to behave and what to do creates resentment and is counter-productive.
Teams need Organizational Support. This includes information, the necessary technical tools, continuing education, and recognition and rewards.
Finally, teams can use competent team focused coaching. Coaching should focus on the team not individuals and improving task completion. Coaching has most impact when the team is formed and when major events such as milestones or major disruptions occur.
- Pulling developers from one team to work on another on a regular basis
- Treating programmers like Carbon Based Programming Units that can be deployed on any project
- Large teams of dozens or hundreds of people
- No one on this team was on this team last year
How To Fail Spectacularly
- Small teams that are dissolved regularly
- Breaking up successful teams to scale their success
- Shuffling people around teams to balance headcount
←Prev (30 Minute Thinking Appointment)(Measure Actual Delivery) Next→