Agile is a team game

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. One example is the concept of Individual efficiency vs group efficiency.

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: Amazing footballers like Lionel Messi, Cristiano Ronaldo, Diego Maradona could not  achieve anything on their own, they need to operate within a team structure to achieve any great success


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. 

Important! 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 :)

Comments

Post a Comment

Popular posts from this blog

Things to consider when you want to change from Scrum to Kanban

Image
Scrum or Kanban? A common problem with agile teams is whether they should choose Scrum or Kanban as their primary methodology. Scrum is the usual starting point for most teams and the current market forerunner when it comes to selecting your agile weapon of choice. According to the 13th State of  Agile report 54% or teams surveyed claim they are using Scrum, with a further 10% claiming they do a Scrum/ XP hybrid. Kanban trails behind at 5% with Scrum-ban hybrid adding a further 8% "Scrum doesn't work for us!" I often hear teams saying that scrum doesn't work for them. When I ask "why?" I usually hear the following: We can't finish anything in a 2 week sprint There are too many meetings Our list of priorities keeps changing We can't plan for 2 weeks.  Our product owner keeps changing his/her mind They often feel like Kanban is a silver bullet because: It doesn't ask you to finish anything in 2 weeks It doesn't im...
Read more

Expanded EPIC boards

Image
What's the problem? As scrum teams, we always look to the Product Owner as the fountain of all knowledge and requirements with respect to our supply of work. Yet, I've found that often the big ideas or concepts for projects are so light on detail that POs are desperately in need of a way to translate the high level idea into a backlog of stories to get the dev team up and running We've all been part of projects where the BAs and POs lock themselves away for a few weeks with a high level understanding of a project and come back with a list of user stories for the dev team to work on. By the time the devs see the requirements, its hard to see the wood for the trees. We get bogged down in the details, the stories are sliced poorly & are not delivering vertical slices of functionality. Often there's no wiggle room. Its all MMF. We cant cut anything out. Additionally, defining an entire release worth of stories in advance which, ultimately, require change or m...
Read more

Moving beyond tasks

Image
One of the most common agile anti-patterns I witness is a compulsion towards breaking user stories into tasks. Tasks take focus away from stories The problem with tasks is that they take the focus away from user stories. Teams that focus on completing tasks risk losing sight of the real value which lies in the stories. They are often unable to see the wood for the trees. How often have you seen sprints that are? •             On day 9 of 10, but <30% of story points are complete •             On day 5 of 10, but <10% of story points are complete •             On day 9 of 10, with 90% of tasks complete, but still <30% of story points complete I firmly believe this is a by-product of too much focus on tasks and not enough focus on stories. Tasks themselves add little or no value on the...
Read more