Small, Stable, Dedicated, Cross-Functional Teams
Often times the overall pattern for work assignment goes something like this:
Oh hey, we have this new project coming in. Who’s gonna do it this time?
Sounds familiar?
Even more so: a lot of agencies are physically organized by department. UX, design, development are sitting in separate groups all day long. Which means that efficient project related communicating can become pretty hard.
So, what might be a better approach here? You guessed it: having small, stable, dedicated, cross-functional teams. Don’t shuffle people around like they were some kind of plug-and-play devices.
But Why?
Why Small? And What Is Small?
The Scrum Guide suggests to have a team of three to nine members.
Scrum GuideFewer than three Development Team members decrease interaction and results in smaller productivity gains. Smaller Development Teams may encounter skill constraints during the Sprint […]. Having more than nine members requires too much coordination.
Additionally in 1970 Hackman and Vidmar came to the conclusion that the optimal team size is 4.6 people (good luck with that), while other research points more towards a solid six. Like always: it depends.
No matter what, you should be familiar with the effects that team size has on productivity. And while we’re at it: if you had a late project that made you consider adding more people in order to meet the deadline, have a look at Brooks’s law
Why Stable?
A pretty valuable thing to know about teams is what Bruce Tuckman has to say about the stages every team goes through. Here they are:
- Forming — The team comes together, gets to know each other, explores the customer goals and possible solutions. Everybody is on their best behavior.
- Storming — Conflicting opinions arise, team hierarchies are shaped, people get to know each other better. Including the tempers and rough edges. This can be a bumpy ride.
- Norming — The team grew together and is able to focus on the objective rather than social issues.
- Performing — The team has established a shared heart beat. They know their strengths and weaknesses and how to use them to achieve their shared goal.
The time it takes a team to go thorough each of these stages and if they fall back from time to time depends on the people and the circumstances.
Each time you fiddle around with the team structure, you start at square one. That can result in a pretty inefficient way of working. Each time you throw people on new teams you throw away a lot of shared understanding, mutual respect and ultimately: productivity.
Why Dedicated?
Research has it: Multitasking is a myth. We can’t do it. Nobody can.
And yet we try it over and over again. It’s pretty common for people to work on more than one project at a time. They all need to get finished and are equally important. So the natural thing to do is to work on them all at once. It’s important to show the client that we’re busy doing the work. No big deal. Right?
Meet Gerald M. Weinberg — he came up with this thought-provoking table:
| No. Simultaneous Projects | Percent of Time on Project | Loss to Context Switching |
|---|---|---|
| 1 | 100% | 0% |
| 2 | 40% | 20% |
| 3 | 20% | 40% |
| 4 | 10% | 60% |
| 5 | 5% | 75% |
Whoops. If that were even remotely true, it would mean that we waste a lot of time that could be spent building things and creating value instead.
When we put a couple of projects on a timeline this is what happens…
Based on Scrum Pitfalls Part I
Juggling multiple projects in parallel creates a lot of context switching for everyone. A better strategy is to focus on what’s really (business) valuable — as in reducing scope — and do one project at a time.
When looking at the bigger picture it’s clearly faster to have a team working on multiple projects sequentially instead of in parallel.
Do you work that way?
Why Cross-Functional?
Remember Swarming? How would you do that if you had a team of specialists that don’t know much about each others craft? Would be pretty hard, right?
There is a lot of value in having a team that has T-shaped people on it. That means they have a basic understanding on different skills, but are specialized in a certain field of expertise. T-shaped people can learn from and support each other.
This leads us to another important aspect of cross-functional teams: they can’t have external dependencies to get the job done. Having some magic expert being responsible for an aspect that the team doesn’t have control over is asking for trouble. What if the external dependency wasn’t available when needed? The team would have to wait for her or would be on its own. A much better approach is to invite the external specialist over and transfer the knowledge into the team (to a point).
Working as a cross-functional team includes cross-domain support by the way. Why shouldn’t a designer or a tester actively support the development team? This obviously means investing a bit of time to get them up to speed. But once the knowledge transfer is in place, the momentum the team can develop will be beyond the stars.
A word on one developer „teams“. I’ve seen a lot of projects explode or take forever that had only one developer. This might be an approach for very small projects with limited complexity. But even then there is a huge risk involved. What risk you say? Remember Swarming? :)