How to Start New Agile Software Projects: Building Good Teams

The software team; that diverse mix of personalities, knowledge, skills, and experiences, is at the center of every project. It’s the stuff that makes your project tick. It’s more important than a great requirements document, more important than a perfect software architecture, and more important than funding. Well… maybe not that last one, but without an effective team, you probably won’t be able to deliver on the vision that got you the funding in the first place.

This post is part of a series. Check out the other posts in How to Start New Agile Software Projects.

Today, we’ll explore key topics essential for building a high-performing software team, including starting points for recruiting, and creating a “whole team”. We will discuss team dynamics, and the importance of psychological safety in a post next week.

It’s worth noting that building and leading high performance teams is a complex problem space with many factors that have a direct impact on the outcome. There are several great books that do a great job of detailing specific aspects of team leadership, and I am merely describing the techniques I rely on most of the time.

The Architect role

At Opreto, we include an architect position in every team. While this isn’t a common pattern amongst many software teams, we’ve been able to use that role to unlock something missing in a lot of modern teams: synergy.

The architect role has evolved over the past decades, from one of pure technical design, systems integration and initiative planning, to one that also focuses on empowering teams to reach technical excellence.

You can read Alan Laudicina’s excellent post on The Importance of Software Architects in Agile Development for a thorough overview of the role of a modern architect. In the context of team topology the architect promotes team synergy in the following ways:

• Providing technical expertise through deep technical knowledge and experience.
• Keeping the team aligned on the project’s vision and direction.
• Promoting communication and collaboration among the team.
• Actively mitigating architectural risks of the project.
• Using breadth of knowledge to empower cross-functional teams.

We find the role to be of critical importance to the functioning of a good team, so this is a role we always fill. But the software architect can also begin laying the groundwork for the other members of the team as they are brought on board, so it makes eminent sense to fill this position first, and then focus on recruiting the rest of the team.

The cross-functional team

In The Art of Agile Development, James Shore introduces us to the concept of the Whole Team, a cross-functional team structure that is designed to minimize external dependencies and tighten feedback loops. The idea is to have a team that includes all of the necessary skills and knowledge to deliver the product or service, including software development, quality assurance, user experience design, and other areas of expertise.

To determine which roles to include in our teams, we first research the project’s domain, then establish the project’s vision, and finally plan for the initial technical needs of the project. The roles that will need to be filled on the team are informed by these three essential factors, allowing us to identify the set of skills to recruit for.

Team Governance

Another critical element in our recruitment of teams is the way in which these teams govern themselves once the project is underway. Conway’s law is an axiom that states that the design of a system is heavily influenced by the communication structure of the organization that creates it. Naturally, if you’re building a new team it will be subject to your organization’s existing communications structures and policies. If these policies happen to provide an optimal environment for your new team, you’re already way ahead of the game, but otherwise, you have a big problem on your hands.

We create more effective and efficient teams by applying the Inverse Conway Maneuver: a technique for optimizing an organization’s governance model by deliberately shaping the communication structure of the organization to better align with the desired design of the system - in this case the way in which we like our teams to function.

As a software delivery partner for our clients, we are free to design and lead our teams according to the needs of the project, unshackled from organizational governance. For that reason, we typically build holacratic teams.

Holacracy is a decentralized approach to team governance that emphasizes self-organization and distributed decision-making at the team level, resulting in a flat organization with little centralized bureaucracy to get in the way. It requires a high level of autonomy, trust and transparency, which are traits we specifically hire for, and then encourage throughout the lifetime of a project.

We use a set of software systems for rapid communications, and structured organizational tools for planning, and leverage agile development techniques to shape our teams into units that are thus self-organizing, and highly-communicative; an application of the Inverse Conway Maneuver to generate and support holacratic “whole teams”.

Recruiting

Only now, armed with an architect, a communicative holacratic model, and the knowledge of the roles, experiences, skills, and personalities needed by the team, can we start the process of finding the right candidates and getting to know them.

Don’t make the mistake of blindly recruiting people based solely on their qualifications, certifications, or experience.

In addition to technical skills, we put a lot of emphasis in our recruitment process to ensure we find candidates that possess the traits required to thrive in a holacratic team environment. We also look for candidates who are driven to help us foster an open and transparent culture, and who excel at facilitating activities for the betterment of the whole team.

Finally, we ensure that we’ve identified all the roles required to create a true cross-functional team that is capable of completing entire units of work without relying on external dependencies in order to increase productivity. This can seem expensive or even wasteful, but is usually a lot cheaper than introducing long delays in our clients’ go-to-market roadmaps.

Conclusion

Building and nurturing a healthy team is key to the success of a project. What’s really unfortunate, is that although common sense will get you 50% of the way to having a reasonably functional team - achieving high performance requires a lot of work, thought, and knowledge.

In this post, we’ve summarized our perspective on a few of the best-practices of software team leadership, and expounded on how it informs our choices during the critical step of team building. In the next post, we’ll discuss team dynamics and how to avoid common dysfunctions in teams, as well as tools you can use to ensure good communication inside them.