There are few sports where the team is more important than in soccer. Unlike other team sports such as basketball, baseball, or even hockey, soccer relies on all eleven players to work in unison to achieve their ultimate goal.
Watching the World Cup the past few weeks has shown us the importance of team structure, training, work ethic, and strategy. Some countries that relied too heavily on one player who didn’t perform (Portugal) or that didn’t properly evaluate how their players would work together (Cameroon) are out. Other countries, like Germany and Costa Rica, made long runs in the tournament because they assembled players who quickly jelled into a cohesive unit that is greater than the sum of its parts.
You can learn a surprising amount about how to assemble and maintain a great agile team from the World Cup.
Much was made of the United States leaving longtime soccer hero Landon Donovan off the World Cup roster. Questions remain regarding whether he fully bought into coach Jurgen Klinsmann’s system or whether he would have been able to consistently contribute as much as other team members.
When assembling a team, you need everyone to be on the same page. If a developer isn’t in tune with stakeholders’ expectations or doesn’t fully grasp the business implications of his work, he can drag down the performance of the entire team.
Select team members not for their past work, but for their ability to handle the task at hand. This might mean bringing in developers who are new but have desirable skills or experience in similar business scenarios.
You also need developers to jell culturally, both with the team and the business. You want a team that’s more like Columbia, dancing together in celebration of goals, than Ghana, where players attacked coaches and were dismissed from the tournament.
It’s hard to gain the stakeholders’ trust if you can’t relate on a cultural and business level. Working closely with business and IT stakeholders, preferably on site, improves communication and collaboration. Working in close proximity fosters an understanding and connection outside of just coding. This drives the relationship between the team and the business and creates opportunities to deliver added value.
Getting Up to Speed
While some team members have played with or against each other before, the final roster selection comes only weeks before the start of the World Cup. There’s not much time to become acquainted with one another and form a cohesive, productive unit. But the team must quickly find its rhythm or it will fail after just three games.
An agile team must also be able to quickly find its rhythm. When the team reaches peak velocity, it has achieved a flow that makes the amount of work it can accomplish predictable and drives high confidence levels. Teams strive to reach their rhythm quickly because there are deadlines to meet and any delay means potential loss of revenue, customer loyalty, or even people’s jobs. Early sprints should see team velocity improve, and peak velocity should be achieved ideally in three sprints.
While this ramp up to peak velocity may seem aggressive, it is achievable if the right team is assembled. Typically, team assembly is based on the technical capabilities of individuals. At my company, we take a different approach to team assembly that has repeatedly let us ramp up to peak velocity typically within three two-week sprints.
Catalyst IT Services uses a big data approach to team assembly, similar to the approach taken by Billy Beane and the Oakland Athletics illustrated in the book and movie Moneyball. By applying big data to the hiring and team assembly processes, we are able to evaluate very large numbers of individuals and dramatically reduce subjectivity. The evaluation process collects a large amount of data on developers, including background, metadata, public data, and more.
Thousands of variables are collected during this process and are compared with success and outcome metrics. These include velocity, defect rates, rates of ramp-up, and variations in throughput to predict success. By matching and teaming developers based on objective data, you can optimize team performance from the very first sprint.
The World Cup is all about consistency. Once teams have ramped up to peak performance, they must maintain that highest level of play for an entire month. Even the slightest dip in output or a lack of focus can eliminate them from the tournament.
Just look at Mexico’s eight-minute breakdown against The Netherlands. Mexico stuck to its game plan and played a brilliant game for eighty-eight minutes. But they team couldn’t sustain this level of play, made several strategic and tactical errors, and conceded two goals in eight minutes, losing the game 2-1.
For agile teams, the Agile Manifesto defines consistency as “sustainable development. The sponsors, developers and users should be able to maintain a constant pace indefinitely.”
The energy and effort that goes into each sprint should be well established and predictable, and each team member should be contributing. Consistency allows projects to be delivered on time and in scope, without having to go into “stoppage time.”
Measurement throughout the project will help achieve this. Establish metrics and report on them for every sprint. If results are not as expected, you can make changes before the project is derailed and delivery delayed. For example, it may benefit the team and improve velocity if defects are addressed the day they are discovered; or perhaps team members are operating in isolation. In some cases, as with World Cup teams, the starting team members may even need to be changed. The important aspect to remember is that metrics should be established and measured to ensure expectations of quality are being met and a usable product is consistently being delivered.
Any good World Cup side is led by a coach who sets a clear strategic and tactical game plan and then steps back and allows the carefully selected players to execute on the field given the dynamics of the evolving game.
Likewise, successful agile teams rely on a key sponsor, often an IT or line-of-business owner, to establish and communicate both the business and technical goals of the project. This game plan helps agile teams better understand how end-users will interact with the finished product and provides direction for “done” criteria.
And, just as the game plan changes based on your opponent in the World Cup, so too does your game plan change with each sprint. Team members should know user stories that are to be addressed in each sprint and be able to deliver consistent points sprint after sprint. The coach should still be part of the project but should empower team members with the autonomy to direct the project as needed, as long as the end product meets quality, value, and time benchmarks.
What other parallels can you draw between the World Cup and agile development?