Small Stable Teams
Research has shown that smaller, stable teams with the same team members outperform other configurations. As team size grows, communication paths grow at the rate of [n*(n-1)]/2, where n is the number of team members. This gives rise to:
Brooks’ Law: Adding people to a late project makes it later.
- Constantly training new teams and new team members is expensive and unproductive
- Any given team is always lacking some particular expertise
- There’s a lack of institutional memory; no growth in domain expertise in the team
- No team knowledge of historical bugs and releases (and you’re constantly re-discovering issues)
- Organizational/tribal memory increases and is more resilient to individuals leaving
- Higher performing teams
- Increased team trust
- Improved turnover rate
- Lower training costs (stable teams retain domain and tech expertise)
One study (online at https://www.rallydev.com/finally-get-real-data-about-benefits-adopting-agile?nid=6201, registration required) from the vendor Rally found that dedicating team members to one team doubles productivity. Keeping a team together over the long term shows a 60% gain.
Psychologically, people working in a smaller group setting tend to be more open, transparent, and trusting than those working in a large group. Teams with about 10 members tend to sub-divide into smaller teams which have fewer communications paths.
- 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, and at every reorg (-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 the team can focus on and take ownership or responsibility for developing.
- Ensure you can give the team an area that has no or very few dependencies on others for delivering working software.
- Ensure the team has had some training on the GROWs Method™ and is ready to get started.
- Ensure each member of the team is fully aware of the build and delivery process (see TracerBullets)
- Connect the team to the business area and people who rely on the capabilities the team will be delivering
- Have the business area people take a little time to explain what they do and their reliance on software and additional capabilities they need
- Ensure the team has an opportunity to develop team norms such as TeamWideInterruption and discuss how they would like to organize tasks and deliver work
- 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.
- This is your first ContinuousReview session. Work on candor and frank honesty about the items that were and were not successful and commit to trying specific things to implement a cycle of continuous learning and improvement.
What Does it Look like?
A small team is something less than ten maximum, with an optimal size of perhaps closer to seven people. A stable team retains the same members over the life of the project work, and beyond. The team probably knows each other’s lives outside of work, families, etc., and have lunch together. They’re more than “just” co-workers.
Small stable teams have the following characteristics
- Small: 5-9 members. Beyond this, teams tend to sub-divide into two smaller groups
- Bounded: everyone knows who is on the team, and who isn’t
- Interdependent: members need to combine efforts to achieve a common purpose
- Shared history: members know each other, and have worked together
- Focused: There’s well-known, compelling work goal
- Cross functional: the team has the skills to solve the problem on which they’re working
- Self organizing: the team organizes itself around how best to solve the work they’ve been asked to complete
- 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 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)(Visualize Progress) Next→