Agile software development is a team sport. I see so many issues when working with software teams that I have also come across in a sports team context. Teams are collections of people and to get a collection of individuals motivated and organised to achieve a common goal is not easy. I am convinced there is much we can learn from the sporting arena to help us perform better as software teams.
This is the first in a series of posts exploring concepts like:
- Individual efficiency vs group efficiency
- Long lived teams v fluid team membership
- Learning/ knowing your system/ formation.
- Clarity of roles & responsibilities.
- Culture of continuous improvement
- Use of metrics to inform decisions
- Use of a coach
- Not using one size fits all management approaches
Post : Individual v team efficiency
A lot of what is important for the success of sports teams is also valuable for software teams. We create teams with a view to the Team achieving more together than the individuals would on their own or because the task/ deadline before us is unachievable without extra man power.
Example: Cristiano Ronaldo is arguably the best footballer on the planet, however on his own he cannot achieve anything, he needs to operate within a team structure.
Often organisations are trying to deliver projects to crazy deadlines which mean they need the extra manpower a team structure can provide. They cannot rely on the superstar, the Ronaldo, to do it on their own. For star players and gifted individuals, sometimes this means sacrifice. A sacrifice to how they would normally do things. A compromise of their individual efficiency for the sake of the team efficiency.
An example of this that we might be familiar with in software teams, might be where a team debates whether to break a large user story into multiple small stories. The star developer feels he can be individually more efficient by tackling the big story on his own in one go. However by breaking the work into smaller chunks the team gains a lot:
- ability to show incremental delivery
- ability to spread the knowledge throughout the team
- pride that the whole team can contribute rather than just one superstar
- future reduction of key man dependency
- shared knowledge of the system
- early identification of risk/ complexity.
Often, using agile means sacrifice for the expert individual but it results in a stronger team, the herd is only as fast as its slowest member, not its fastest. This can cause conflict in some cases with the star player finding it difficult to sacrifice or to spend time coaching others to an enhanced level. The bottom line though, is that organisations need to have multiple, reliable delivery teams rather than a handful of exceptional individuals. This doesn't mean we don't want to have exceptional individuals in our companies or teams but ideally these should compliment outstanding delivery teams, not prop up poorly functioning teams.