Building a well-functioning software delivery team is complicated. There are many factors to consider. Current team (if any), needed skills, available people, company politics etc.
There are some fundamentals that often (but not always) seem to work.
My fundamental principles for teams
- Static
- Cross-functional
- 5-9 people
- Co-located
- Dedicated team members (belong to only one team)
I find these principles to be a useful basis for discussion, when helping managers configure their teams.
The principles are goals, and one must realize that all cannot be achieved all of the time, nor instantly.
Static teams
It is valuable to keep the members of the team in the same team for a long period of time. Team formation takes time. People get to know eachother over time and learn how to collaborate more efficiently over time. See Tuckman’s stages of group development at Wikipedia.
This can be difficult to achieve, because the world changes all the time. People join and quit the company. Guys go on paternity leave. Teams need added skills and grow. Some other principle needs to be satisfied, etc.
Cross-functional teams
Things tend to go much faster, and be a lot more fun and challenging if there are people with different skill-sets in the same team.
Ofcourse, not all teams need the same roles. For instance, a team that builds web services may not need a graphical designer.
This principle also affects what types of work a team can do. If a team is not cross-functional, they tend to need to hand-over work to another team before the work is done. (Hint: When you hear the word “hand-over” or similar, what they are really saying is “waste”.)
A cross-functional team has a better chance at building something from start to finish, or “from wheat to bread” as the saying goes here in Sweden.
Team size: 5-9 people
A team size of 7 -+ 2 has long been considered optimal among agile practioners. One explanation for this is that when a team grows, the number of communication paths grow (n(n-1)/2). Basically, it becomes too time consuming to talk to everyone. I have verified this myself in real life. Also, I have broken this principle many times.
Once, I had a team of around 7 people and was ordered to increase our capacity. We started recruiting and ended up with around 22 people some months later. Along the way, I asked the growing team if they wished to split into seperate teams because I could see that Daily Scrum was becoming quite painful. They didn’t want to split. They wanted to learn more from the “old guys” first. Eventually, we split up into 3 teams, when everyone was ready for the change, and it was a very positive change, but the learning had also been great.
Co-located
Teams should sit together, in the same room, obviously in the same city and country. I know, there are teams and organizations that manage to have productive teams that collaborate using only a bunch of electronic aids like chat, video calls etc. However, it is a lot harder and easy is good. If a team member gets stuck on something, it is a lot easier to simply stand up and say “Hey, can I get some help here please?” than to schedule a video conference with some person in another time zone…
I have broken this principle many times aswell. Sometimes you cannot find the right skills where your current team is located. Sometimes company strategy and politics force you to have team members in another location.
Team members belong to only ONE team
Maybe this goes without saying for many of you, but it really helps if team members don’t have something else pulling their attention. Working 50% on Team A, 40% on Team B and 30% on Team C doesn’t work. See! The math doesn’t even add up!
Working on the top priority Story becomes really hard when there are 3 top priority storys. Also, the other team members can never count on when they have access to the 50%-guy. That sucks.
Have I seen this priciple broken aswell? Sure. Sometimes you have this HERO that possess skills needed by multiple teams. This is a problem. Sometimes the hero doesn’t see it, but often it is a person that could really use some slack. Also, the “truck factor” needs to be considered in these cases. Perhaps the hero can share knowledge and train others to do the job in other teams. Perhaps someone new needs to be recruited.
Closing thoughts
I was going to write about the importance of a good team name, but I will save that thought for another time. Thanks for reading and please give me feedback on these 5 team principles!
Good thoughts. But the problem is that just following these 5 rules doesn’t make the team effective. Moreover this group of co-located individuals may not be a real “team” at all. This makes me think that there should be something else even more important for team formation.
@Konstantin: You are correct. This does not cover everything, or every possible situation. What other things have you observed as being important for building a well-functioning software delivery team?
I mean, I believe the above-mentioned principles are very important and can be viewed as basic or hygienic. They are definitely the pre-requisites for team formation. But then to make an effective team we need to give them a goal, motivation, identity, autonomy and other soft things like that to unite them and drive to goal achievement. And I must confess I saw not so many really good teams in my life 🙂 What do you think about that?