The success or failure of any project is dependent on the team working on it, and no two team members or teams are the same — nor should they be! Each has their own unique skillsets that should be utilized where & when appropriate. Generally, agile development methods favor teams without fixed roles, because the team members are able to take those skillsets and apply them to many different types of projects and roles. There’s no silver bullet structuring method for development teams that will blast you to tip top efficiency, but there are some pretty damn good methods for getting there and getting stuff done.
Keep Teams Small
A 2005 study by QSM shows that smaller teams are more efficient than larger teams. Larger teams face problems with communication, organization, workflow. So naturally more people, more problems — you can connect the dots. When everyone on a project needs to coordinate and communicate with other team members to get a job done, the overhead cost rises nearly square of the number of people on that team. Small teams, on the other hand, are easily structured, restructured, and able to work more independently with the ability to coordinate their efforts.
We can all learn something from Bezos’ idea of a decentralized, streamlined team strategy, where small groups have the ability to innovate and test their ideas independently. He calls it a “two-pizza team”: If you can’t feed a team with two pizzas, it’s too big! Therefore, this limits a team to 5-7 people who can focus on a project, or iteration. A ‘two pizza team’ might look like this:
- 1 Designer,
- 1-2 front-end devs,
- 1-2 back-end devs,
- 1 QA expert, and
- 1 product manager.
This is called a ‘whole team’; a team like this can shepherd nearly any functionality from start to finish because they can interact more closely and deliver value without external dependencies. If you have a large team, examine the effectiveness, can you break it down into smaller, independent teams?
Keeping teams agile means avoiding knowledge silos. This tends to happen in larger companies where they are able to hire a lot of specialists, but it’s possible in any sized company or team. Employees that specialize are fine, but the problem with silos comes when teams or team members work on one feature only, and everyone else is left out of the loop. What happens when members of that team are no longer working on that feature, is that introducing new developers to the project is challenging because they have no working knowledge of that code area. It’s important to structure or ‘de-structure’, rather, in order to avoid expertism.
Atomic Object discovered a way to combat ‘expertism’ by implementing a feature lead, who is responsible for seeing a feature through start to finish. Anyone can be a feature lead, and the strategy works on a rotating schedule where employees are free agents and pair with a different feature lead every day. Once that feature is finished, that feature lead will go back to being a ‘free agent’. This is a great method to look to for structure: it allows teams flexibility, and utilizes everyone’s skills across multiple features and iterations. Pair programming will deliver similar results as well, as long as you rotate pairs frequently. Plus, you avoid that pesky silo problem.
Small teams should rarely work on the same part of an application at the same time, it’s wasteful in terms of employee time. The idea is to organize your team around needs per project. Typically organizing larger teams into a collection of smaller ones allows each team to work on a portion independently, and this speeds up the process and quality. Ryan Abel from Atomic Object used a great metaphor, we’ll paraphrase:
Say you’re cooking Thanksgiving dinner with four people. It makes no sense for all four people to work on the potatoes at one time. If that was the case, every finished meal component would be ready at a different time, and the meal would not come together cohesively. Assigning independent cooking roles for apple pie, turkey, mashed potatoes, and green beans on the other hand, works well. Everyone works together, yet has the ability to move forward without being slowed down by someone else’s work pattern. Break your team up accordingly, because apple pie and mashed potatoes don’t need four hands. When structuring your small teams, here’s some questions you can ask to validate efficient team structure:
- Can your teams be fed with two pizzas?
- Does the structure minimize communication?
- Does the structure encourage collaboration?
- Does the structure play up individual strengths, and minimize weaknesses? (The goal is a structure that creates teams that are better than the sum of all its parts)
- Are your teams working around features, able to deliver end-to-end?
After answering these questions you should have a better idea about the efficiency of your team structure. Tweaks might need to be made continuously to get the right fit, and understand that needs change over time, but that flexibility and responsiveness is what Agile development is all about!
Development teams are like snowflakes, and there’s no one ‘right way’ to structure a team. It has been proven time and time again that small teams are more efficient, and not to fear — even if you’re operating with large teams, those can be broken down into subteams. Set small teams up in such a way that contributes a ‘whole’ set of skills to a project, and you’re on the right track to optimal efficiency.