Team Solar System

Content is sourced from https://github.com/robertfmurdock/team-solar-system/Proposal.md

Pull requests, edits, and feedback are welcome.

The Big Idea

To create stable, fluid teams.

By “stable”, we mean teams that will

• Survive the end of a project
• Have a plurality of old team members when new team members are added

By “fluid”, we mean teams that have

• periodically will add new team members to grow the size of the team
• predictable swapping of an existing team member for a new one, where the existing team member moves to another team

By “predictable”, we mean rotation that

• Happens at a regular rate
• Is transparent and visible on a calendar
• Is trustworthy (not always invalidated by “special circumstances”)

Why do we want teams that are stable?

Building team culture takes a lot of energy. Even when team members have similar values, forming a new team from members that do not have prior working relationships can be an expensive and stressful activity. When teams are formed specifically for projects, they may not last long enough to even exit this “storming” phase.

Therefore, we want to create teams that can pay down most of that cost early in their lifespan, then bring projects to these teams; thus minimizing the friction of building a new team and letting the team itself develop its culture past these initial “growing pains.”

We think that this can create deeper team relationships, allow more opportunities for on-the-job mentoring, and let teams consider process experiments over a longer term.

Then… why do we want to rotate members through teams? Why is fluidity desirable?

While having a stable team culture is very valuable, we want to avoid having a stagnant team. An important part of any culture is being able to teach and test its values on new members. While we want the rate of personnel change on a team to be limited, we want the team to be well-practiced at adoption.

Process Modules

There are a number of related processes that we believe will allow us to create teams with the desired properties.

• “Bring Work to the Team”
• “Smart, Multi-Project Teams”
• “Team Mitosis”
• “Cohesive Teams”
• “Continuous Change”

The following sections will describe these processes in more detail.

Bring Work To The Team

This is the practice of establishing a team independent of a project. When a project ends, a new project will be needed to fill the void. Teams are not created in order to fulfill a project and do not disband when a project ends. The principal benefit of this process is team stability.

Smart, Multi-Project Teams

This is the practice of allowing a team to work on more than one project, and manage how the work is distributed among its members. This has a number of benefits, including:

• Giving team members more opportunities to work on different kinds of projects
• Smaller projects benefit from access to the experience of more team members
• Teams adopt more responsibility for managing when each team member works on each project

Team Mitosis

This is a process to enable team growth. Over time, a team adds members and projects until it hits a size where it can divide into two teams. Because project work will usually not become available at the same schedule as team members are added, a team will likely want a “skunkwork” project or two to work on while the team has more members then paying work. This may be thought of as a “distributed bench” - rather then having an idle team called the “bench”, each team grows extra capacity.

Cohesive Teams

This is a guideline to help ensure that teams do not grow to unwieldy sizes, nor shrink to a point that makes them inflexible. In order to support the team properties we desire and the processes that support then, we recommend a minimum team size of two pair (four people), and a maximum team size of six pair (twelve people). Any smaller then four and swapping a team member with one from another team becomes a fairly radical change. Twelve people is likely the absolute maximum number of people a team architecture discussion can support. These limits are recommendations, and can be flexed according to needs in context.

Continuous Change

This is a principle that a team needs to vary its composition with regularity in order to stay fresh. A healthy team is able to add team members without compromising its integrity. A healthy team is also able to adjust as team members leave. Of course, there are limits to how much of a team can change within a time period without negatively affecting the dynamic. We’ll probably want to put a metric together that highlights these change boundaries, possibly one that acknowledges that growth is less costly then reduction.

Illustrations

For the sake of illustration, let us think of projects as sized in this way:

• A major project takes 5-8 devs, or 3-4 pair

• A minor project takes 3-4 devs, or 2 pair

• A micro project takes 1-2 devs, or 1 pair

Teams need the ability to grow and shrink in size in order to facilitate organizational change. That said, a normal sized team might be 4 pairs large. A team with four pairs can take on:

• One major project
• Two minor projects
• One minor project and a few micro projects

To Do:

• illustration showing how managing the team to project relationship can work over 12 months
• illustration highlighting company growth rate and how it is distributed over many teams over time
• illustration detailing options for dealing with on-site work
• illustration detailing mega projects that require multiple teams