One of the fundamental values of Agile is teamwork – the idea that together, groups of individuals can accomplish greater things than they could accomplish alone. Agile teams aren’t simply otherwise “normal” teams who decide to be Agile. They’re groups of cross-functional people with shared values who work together to:
- Challenge existing ideas
- Identify new opportunities
- Commit to continuous improvement in everything they do
Les clés pour constituer des équipes Agile et des Agile Release Trains hautement performants
Découvrez comment bâtir des équipes Agile extrêmement performantes et obtenez des réponses à des questions importantes.Obtenir le livre numérique • Les clés pour constituer des équipes Agile et des Agile Release Trains hautement performants
Essai gratuit de LeanKit : logiciel Kanban en ligne LeanKit
Inscrivez-vous pour bénéficier d'un essai gratuit de 30 jours et ainsi commencer à créer des tableaux Kanban en ligne avec votre équipe dès aujourd'hui. Découvrez par vous-même comment LeanKit prend en charge les initiatives de livraison continue, élimine les gaspillages et améliore les processus et la vitesse d'exécution de votre équipe.Commencer votre essai gratuit • LeanKit Free Trial
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.
What is an Agile Team?
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.
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.
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
- Communicate closely with other teams, or
- 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).
Agile Team Structure
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.
Stages of Agile Team Development
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.
Tools for Success for Agile Teams
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.
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.
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.
How to Make an Agile Team
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.