How to Make an Agile Team

Although all Agile teams share some common values, there is no golden recipe for the ideal Agile team. Within Agile, there are teams who practice Scrum – with its specific roles, rules, and practices – and those who practice Kanban, and those who practice neither, or a hybrid of the two. Some organizations require Agile teams to be co-located, while others embrace the challenges (and potential upsides) of remote work.

Before diving in any deeper, let’s align around what an Agile team is – and what it needs. An Agile team is typically defined as a cross-functional group of people that have (more or less) everything they need to deliver a working, tested increment of product.

Although most of the language around Agile is product-focused, it can truly be applied to any type of work – you can replace product with campaign or project or case and still reap the benefits of Agile.

Let’s break down each of the elements within this definition.

Cross-functional

To deliver a sound, working, tested product, you need multiple perspectives to come together. You need the insights of people who are responsible for developing the product, those maintaining it, and those who will sell it to the world. Together, these unique perspectives can engage in the deeper problem-solving magic that is possible for Agile teams.

Independent

Agile teams are usually described as being able to independently deliver working increments of product. In software, this can be a bug fix, a new feature, a new in-app messaging system, or some other update. In other industries, this can be anything from an event promotion campaign to a new packaging design. As long as Agile teams have the skills they need to create a working piece of something, they can enjoy the speed and productivity boosts that come from working in this way.

This isn’t to say that Agile teams don’t

1. Communicate closely with other teams, or
2. Occasionally need to call upon specialists for support.

Intentional communication with other Agile teams is critical for a creating seamless, meaningful customer experience; working in Agile teams simply increases the intentionality and purposefulness of the communication. And when a problem arises that requires expertise outside of the team, an opportunity is created for cross-functional mentorship, which only serves to strengthen the team (as we’ll explain later).

So, who should make up your Agile teams? This is where it can get complicated – because it truly depends on your company, your product, and the goals you’re trying to achieve by forming Agile teams in the first place.

Your Agile teams should be able to deliver a working increment of your product (or “product”), so a good starting place is to identify the distinct phases of your product cycle. These teams typically include between 5-9 people – more, and it becomes difficult to truly operate as a team without (intentionally or unintentionally) breaking into smaller subteams.

Teams should organize around products, or features, when possible. Organize around subsystems where you have shared functionality – otherwise known as business capabilities. Once you have the business capabilities understood, align the business capabilities with the technical architecture and ultimately, the organizational architecture. The intersection and alignment of business, technical, and organizational architectures is where you form a complete cross-functional group.

Most product cycles have a development phase (which is typically more project-driven), ongoing maintenance, and then a sales/marketing component, which includes elements of both project-driven and ongoing work. Many products have several concurrent development efforts happening at once – and require maintenance and sales/marketing for each of them.

Let’s say your product’s capabilities fall into one of three categories – the core product, with its features, updates, and bugs – integrations, with its own unique set of needs, and reporting. One way to configure your Agile teams could be around these categories – you might have one team dedicated to the development of your core product, one to integrations, and one to reporting. These teams would each include individuals from development, product management, and product design. This team would be responsible for delivering new features, updates, and designs related to their part of the product.

Then you would have a maintenance team dedicated to supporting each of the categories: A core product maintenance team, an integrations maintenance team, and a reporting maintenance team. These teams might involve members from customer support, ops, development, and product management. These Agile teams would be responsible for maintaining, supporting, and strengthening the integrity of their piece of the product.

Then, you could have teams dedicated to promoting/selling each of the categories – so rather than having one large marketing team that is scattered across your entire product, you have a cross-functional team of product managers, customer success individuals, marketers, and salespeople who are dedicated to one specific area of the product.

These teams would form a matrix that would connect at strategic points but could also work independently to solve the unique issues facing their focus point in the cycle.

Of course, this is just one model for team makeup; there are unlimited ways to form your Agile teams. What’s important is that these teams are formed intentionally to achieve a common, shared, ambitious goal, and that the goal is forward-thinking, sustainable, and driving the right kind of growth for the organization.

Agile teams are like any other team in that just like the individuals within them, they evolve over time. Tuckman’s Stages of Team Development are often used to describe the distinct phases nearly all teams go through. The stages are: forming, storming, norming, and performing. Tuckman’s theory says that these phases are all necessary and inevitable for the team to grow, face up to challenges, tackle problems, find solutions, plan work, and deliver results.

A common pitfall for Agile teams is that they fail to weather the storming stage. During the norming stage, team members are polite, courteous, and perhaps subdued; they bend to each other easily for the sake of maintaining harmony and momentum.

The storming stage is where strong opinions start to surface more readily, and conflict is likely to arise. Conflict, defined as differences in opinions, perspectives, or viewpoints, is necessary for the success of any Agile team. But many Agile teams struggle to see conflict as healthy and disband or reconfigure before they’re able to realize the benefits of working through differences.

If the members of an Agile team are constantly changing, it’s impossible for the team to move through each of these stages and eventually get to where the magic truly happens: Performing.

Keeping Agile teams intact is a challenge for any organization and requires organizational discipline. When change is introduced, such as with the introduction of a new employee or the departure of an existing team member, the team effectively starts over, back at the forming stage, where progress can be made, but elite performance is unlikely to occur.

High-performing Agile teams rely on sound engineering practices – like code reviews, task branching, continuous integration, and frequent releases – to maintain stability throughout each change. These engineering practices are critical for building sustainably high-performing teams and should be enforced and reinforced.

Two other critical tools for success are a learning mindset (empowered through mentoring) and shared skill sets.

Mentorship

One of the unique benefits of working on a cross-functional Agile team is the opportunity to learn from the perspectives and experiences of people across your organization. Often, mentorship is thought of as a junior team member learning from a senior team member, but on an Agile team, this definition is expanded: Age, and even experience, are weighed far less than simply a difference in perspective. A senior marketer can learn a great deal from a junior product designer and vice versa. A junior developer can gain invaluable insights about how to think about their own work through conversations with a customer support team member.

Cross-functional mentorship is one of the greatest benefits of Agile teams, and over time, can greatly expand the shared knowledge of the organization and promote stronger working relationships within it.

For employees of all ages, cross-functional mentorship also creates opportunities for professional growth that simply don’t exist in other organizations.

Shared skillsets

More traditional mentorship, from a senior person in one role to a junior in that role, is also important and should be fostered in and between Agile teams. The more knowledge that can be shared between individuals in a similar role, such as across all product managers or all developers, the more flexible, or agile, each team can become.

Increasing shared skill sets unlocks the power of each team to tackle various types of work. Newly formed Agile teams typically must rely more on the expertise of external specialists than established teams, because as teams evolve and learn, they build within them the skills they need to become fully independent.

Whether you’re a product manager, engineer, marketer, or otherwise, learning new skills makes you increasingly valuable to the organization, and better positioned to grow in your career.

As the saying goes, the whole is greater than the sum of its parts. Organizing talented individuals into cross-functional Agile teams can help your organization realize its true potential with Agile.

If your organization has embraced Agile ideals, but has not yet experienced the speed, innovation, and agility that Agile can provide, start by forming Agile teams in an area that is primed for change. The success of just one Agile team can create a ripple effect across the organization, and over time, transform your organization into the impenetrable innovative powerhouse you know it has the potential to become.