An agile development team represents a level of personal interaction and shared responsibility that was not often seen in the world of global enterprises even just a few years ago. With the widespread adoption of agile development principles, teams are trusted and empowered to make decisions that have significant impact on the value and viability of a product or company.

With that level of responsibility resting in a small group, I’m always surprised how relatively little focus there is on optimizing team assembly methods to produce maximum business value. Simply putting a handful of developers together and calling it a “team” doesn’t cut it. There’s a better, more analytical approach to team assembly that results in more cohesive teams, faster ramp-up times to peak velocity, and improved innovation, business outcomes, and value.

Most companies still hire in a traditional, nonanalytical manner. They collect and peruse resumes, assigning random values to aspects like education, coding language proficiency, years of service, past employers, or previous projects. This subjective approach leaves room for personal bias and neglects traits that often point to the full potential of a developer.

A better approach to team assembly uses big data and analytics. I often liken it to the Moneyball approach made famous by Billy Beane and the Oakland Athletics in the book and movie by the same name. By applying big data and analytics to the hiring and team assembly process, you can evaluate a much larger talent pool and dramatically reduce subjectivity.

At my organization, Catalyst, the initial evaluation collects large amounts of data on the applicant pool. This includes data collected by directly interacting with applicants combined with metadata, background information, and publicly available data. We collect this information systematically from a large applicant pool—for example, to hire one hundred fifty people in the next year, we will interact with as many as ten thousand interested applicants.

When people apply for a position, we ask them questions and then collect a host of metadata—all of the information you can imagine collecting as individuals interact with the digital world in which we live. That gives us an extremely large data set that tells us information about each applicant, a small portion of which relates to technical skill and a much larger portion of which relates to how people interact with others and the world around them. We then build models that predict, with high levels of accuracy, who will perform well in which environment and which teams will produce at the highest level.

A key to the ability to predict these results is our voracious collection of outcome data. Success metrics such as velocity, defect rates, rates of ramp-up, variations in throughput, and the standard deviation of productivity on a team allow us to predict which technologists in which combinations will deliver the outcomes we seek.

Obviously, the most significant information about an agile team is the performance of the team as a whole. Nevertheless, although this statement is contrary to many of the stated principles of agile development, we do find that over time we are able to collect relevant data on individual contribution even when controlling for paired programming and other team dynamics, in part because of the ways in which teams in our business break apart and evolve differently over time.

Catalyst uses these models for developers and quality analysts, and increasingly for other forms of analysts. We also collect data on likely career trajectories by our line technical staff, and we expect to be able to have strong models for technical leadership roles in the next year.

Continuous improvement is core to these models. Catalyst strives to continually collect and account for outcome data in order to ensure the best results for our clients, as measured by productivity and performance. This focus on continuous improvement is important because these models are not perfect. However, the results our teams have achieved prove the approach yields significantly (measurably) better outcomes than the imperfect existing market for evaluating talent and assembling teams.

Indeed, the results of this method of team assembly are eye-opening. It allows teams to achieve peak velocity in as few as three sprints. It can improve quality by 55 percent and improve productivity by more than 70 percent. But most importantly, it allows agile teams to deliver greater business value and innovation. For Catalyst, it also allows capacity management that always enables deployment of up to two full Scrum teams anywhere in the United States within twenty-four hours. This capability is key to innovation and developing trust between business and technology stakeholders.

For value and innovation, speed matters. Timeframes for delivery are shrinking as user patience erodes and competitors seek to beat you to market. Every additional sprint it takes to reach peak velocity costs in direct development time and even more in lost business revenue, productivity, reputation, or customer satisfaction. Achieving peak velocity in just three sprints allows you to capitalize on market opportunities, beat competitors to market, or fix urgent issues that are draining productivity or revenue from your organization.

Operating at high velocity also increases the ability of a development team to experiment and innovate beyond the initial project plan. In a business climate where every company is a software company, experimentation and innovation is where you find market differentiators.

Development teams compiled using cutting-edge analytics give your organization the best chance to stand out in a crowded field. They not only provide faster time to peak velocity, but also offer greater productivity per dollar or time spent on a project. Getting more productivity per dollar or hour leaves teams with the time, budget, and freedom to explore new product functionalities, development technologies, business use cases, and other avenues to maximize business value.

We’ve had clients specifically mention that they know they’re getting teams with only one or two strong developers, but they think they can’t do anything about it. While it might be antithetical to the agile concept to rate team members individually, anyone who’s worked with a development team knows there can be large discrepancies between the knowledge, skill sets, and throughput of individual team members.

What happens when the team member who is carrying 70 percent of the workload (and this is not an unrealistic number) goes on vacation or finds a new job? The team is exposed, work grinds to a halt, deadlines are missed, and budgets explode. And now you have to start ramp-up all over again as the new team members become familiar with each other and the project.

An analytical approach to team assembly increases value by compiling more consistent teams. There is no one superstar inflating the team’s average productivity or throughput. Every member is interchangeable. There is no precipitous drop if one person should leave or a new member is added. And teams can be formed in a predictive manner where you know what the sum of the parts will equal. You can combine the right set of personal and technical traits to fit the specific needs of the project.

The combination of these personal and technical attributes is even more important when you’re assembling an outsourced team to work or embed with a client. That client has as established corporate culture, business goals, and vision for the project or product on which you will be working. You can’t provide them with full value on the project if you can’t work with or understand their culture, goals, or vision.

Working within the culture matters. It allows you to fully understand how end-users will interact with the product. It allows you to become a partner and make educated recommendations for improvement. It allows you to innovate on behalf of the client. This is all made easier if you know from the start that your agile team culture matches your client’s culture. This is possible with analytical team assembly.

These outcomes are within reach. We owe it to our organizations or clients to use such team assembly methods. If we don’t, we are creating inferior teams that can’t provide the highest level of value and innovation.