What does a high-performing development team really look like?
In a marketplace that is evolving almost daily, the ability to bring new business-critical applications and software to market can make a difference between gaining a competitive advantage and remaining in the middle of the pack. The pressure on development teams to get it done fast—and right the first time—has perhaps never been greater.
But we all know from experience this is easier said than done. It doesn’t take much for critical projects to suffer from scope creep, missed deadlines, and wasted resources. While there may be many explanations, focus often falls on performance of the development team.
So what does a high-performing team really look like? What can technology leaders do, particularly up front, to foster the sort of team performance that meets business expectations under such pressure?
We see development teams in action every day—both our own and those at our clients. In our experience, there are several things that differentiate those that deliver consistently from those that struggle to meet expectations. Generally speaking, these are the same types of things that characterize any high-performing team—whether in sports, business, or any other discipline.
1. Balancing technology with the intangibles.
Of course, there are technology-specific factors and tools—such as clear and effective development methodology and technology architecture—that are critical to a development team’s performance. But successful software projects require methodology, technology, strategy, and collaboration. Balance among those four areas is essential. When there is too much focus on the first two, teams falter.
2. Ensuring strong and clear understanding of the project vision.
All team members need to understand what they are doing and why. The “why” (the business problem the project is designed to address) is as important as the “what.” If it isn’t apparent, then the team’s focus will wander, jeopardizing the ability to fulfill objectives.
This sounds simple, but many times we find this to be the root cause of performance issues. For example, we recently performed an assessment for a client that was experiencing issues completing a key software project. What we found were barriers between the business and IT that prevented the development team from truly understanding the project vision. The sides were not talking; they were passing notes. This resulted in a lack of clarity about the business requirements and a development team not fully “engaged” in the solution.
3. Creating a structure that breeds success.
High performing individuals in a poor structure will underperform, but average individuals in a high performing structure can and will exceed expectations. Think about a sports team devoid of all-stars—the 1980 US men’s Olympic hockey team, for example—that has achieved beyond expectations.
It’s a fallacy that you need the “best” developers to get top performance from your development team. What you do need is good leadership to make sure the team is focused on the right things and to bring out the best in all team members. Some of the best development team leaders we’ve seen function in a role of guidance. They make sure others on their teams are in the best position to succeed.
Does the size of team matter? Obviously, different projects have different needs, but a rule of thumb for agile development suggests that seven people, plus or minus two, is optimal for effective teamwork. A team of fewer than five people often doesn’t have the critical mass of time and/or complementary skills to accomplish the goal at hand. On the other hand, in teams of 10 or more people, it can be unwieldy to make and maintain all of the “deep connections” necessary among members, and the team may begin to lose the dynamic of working closely.
4. Providing the team with a compass rather than a map.
Consider leading your team by giving them a virtual compass, rather than a map. Maps provide a definite, preset route but don’t offer teams the latitude to explore, grow, and discover the best path forward. A compass always points “True North” as a guide, but doesn’t tell teams exactly how to get from A to B, much less from A to Z. A product vision provides a team with that True North to guide them.
Software development is as much an art as it is a science. If it was a science, then every development team would come up with the same solution—and innovation would be slow to occur. Accordingly, a development team needs the ability to self-organize in a way that allows it to work at its best and create the best solution. That won’t happen if someone is confining a team to following the map, telling them what to do at every step of the way.
5. Building trust.
Agile teams have a high degree of trust among the developers and also with management. Developing trust takes time, but transparency, accountability, and open communication are key starting points. For example, these dynamics make it safe to deliver news when it is bad—and that leads to faster resolution and keeping the team on track to achieve its goals.
Better than the sum of the parts
Many development “teams” operate simply as a collection of individuals. A high-performing development team delivers more value than the sum of the parts. Its teamwork saves time and money. More importantly, it contributes to the business’s success in the market. Developers who understand and are emotionally “invested” in the project and comfortable in their role(s) within the team turn out great work—and that makes customers happy and businesses successful.