Group work is the foundation of every workplace. Whether it’s a school project or the development of a new life-changing drug, it’s hard to imagine a breakthrough being achieved merely by one person. Therefore, it’s essential to distribute people into teams and assign them tasks, responsibilities, and shared goals. That’s why in the Agile approach, teams are so important. Here’s what you need to know and always remember about Agile teams.
“In any given moment we have two options: to step forward into growth or to step back into safety.” – Abraham Maslow
What is an Agile Team?
Let’s start with the basics. According to SAFe®, an Agile team is a cross-functional group of 5-11 individuals who define, build, test, and deliver an increment of value in a short time box. The size of the group matters – the bigger the team, the poorer the quality of communication within that team. That’s why in this approach, it’s preferable to have a collection of smaller teams rather than a few vast teams. For example, it’s better to have two teams of five people than one team with ten people, states the SAFe®.
Team structure: Agile vs Traditional
In 2001, exactly 20 years ago, the Agile Manifesto emerged. From that moment, everything has changed in the management world, as companies could choose between keeping the Classic (Waterfall) approach or adopting the Agile one, as both have their advantages.
The Classic approach was designed for large-scale initiatives. Although many companies declare they want to ditch the Classic approach in favor of the Agile one, the former is alive and kicking. Companies often adopt elements from both approaches that suit them best to create their own “flavor” of the Hybrid approach.
One of the main differences between Classic and Agile approaches is team structure. You can find the best comparison in the geometry world: the Classic approach favors triangles while Agile is much more into circles. What does it mean? In the Classic approach, one leader commands the rest of the members and calls most, if not all, of the shots. It’s a rigid and hierarchical structure that may be effective in large organizations but harmful within smaller teams. Why?
According to experts, “a hierarchical structure can hinder a team by encouraging politicking and unproductive rivalry”. Rivalry is not desirable in the Agile approach. Cooperation and mutualism are much more important as everyone works on a common goal. Notably, the responsibility does not lie with one person (usually the leader) but is distributed across all team members.
Agile team vs Scrum team
To understand the key differences between Agile and Scrum teams, we must understand what Agile and Scrum are. As the Northeast University article states, the key difference between Agile and Scrum is that while Agile is a project management philosophy that utilizes a core set of values or principles, Scrum is a specific Agile methodology that is used to facilitate a project. Meaning that Agile is a philosophy, and Scrum is a way to implement it into the product’s workflow, and it’s worth noting here that Scrum isn’t the only Agile framework.
Another popular approach is Kanban, which emphasizes teamwork on fewer items at a time and focuses on reducing the time spent on each stage of development to reduce the time between start and of tasks. You can also choose Extreme Programming (XP), which focuses on producing higher quality software and higher quality of life for the development team. XP is the most specific agile framework regarding appropriate engineering practices for software development, states Agile Alliance.
Let’s get back to the point. Agile involves members from various cross-functional teams. The Scrum team, meanwhile, includes specific roles, such as the Scrum Master and Product Owner, states the article.
Agile Team: Roles and responsibilities
We can distinguish four main roles within an Agile Team:
- Product Owner – a person who defines the vision and business value of a product. They call most of the shots about the direction of each story and prioritizes the work.
- Team members – a group of testers, programmers, and designers who have direct ownership of specific tasks that must be completed to fulfil Sprint goals.
- Scrum Master – the coach, the facilitator, the one responsible for the Agile approach kept in the team. Scrum Master takes care of most ceremonies (such as Daily, Review, or Retrospective), and serves as a soft power within the team.
- Stakeholder – as Scrum Glossary defines them, is a person external to the Scrum Team with a specific interest in and knowledge of a product that is required for incremental discovery. They are represented by the Product Owner. They engage actively with the Scrum Team at Sprint Review.
Building an Agile Team Structure
Forming your team can be fun, but it also requires preparations. It’s not like the Fellowship of The Ring was a group of completely random people – each one of them served their purpose and brought extra value to their task (you know, to defeat Sauron forever). How to be sure we can achieve similar-scale goals? Atlassian points out four stages of forming a team:
- Forming – team starts to form, manager guidance is much needed as roles and processes are not established yet.
- Storming – team members clarify the processes and start to understand the vision, yet their relationships are still unclear.
- Norming – the moment of calming and clarifying the goals, vision, procedures and relationships between team members.
- Performing – good performance of the team, members work well together, as well as on goal, the manager’s supervision is not necessary.
Characteristics of an Agile team structure
Each Agile Team is built differently, as it must reflect the budgeting, goals, and objectives, as well as manpower availability within the company. We can distinguish few key structures that Agile Team can have:
Generalist Agile Team
The term “generalist” refers to members’ overall knowledge about all aspects of the product. They’re not deeply specialized, but they have a broad knowledge of many different things. This allows them to flexibly interchange within teams if necessary. Often seen in more “soft” branches of the company, such as sales.
Specialist Agile Team
The polar opposite of the generalist team, this form relies on people specialized in a very specific set of skills. Team members are experts in their niche, meaning they’re not so flexible but are truly outstanding in the field. This type of team often consists of programmers, architects, or data administrators.
Transitioning Agile Team
A pioneer within the company, this team adopts the Agile way and ditches the Classic (Waterfall) one. Transitioning team connects best practices from their workflow with Agile to work out the best practices within their company.
Parallel Agile Team
After each iteration, members of this team exchange the tasks. Meaning that after each member develops the software, in the next Sprint, they all will test it. The approach is recommended for experienced teams with highly trained members.
Agile Product Sub-Team
A Russian doll of organizing work, Sub-teams are meant to work on a specific area of larger Agile teams. Instead of tackling one big issue, the Agile team breaks it down into smaller, more manageable tasks and solves the chunks of this task more effectively.
Cross-functional team structure
In a “traditional” organization, each department works on its own goals. Marketing solves commercialization and communication problems, legal checks if everything is done by the book, IT develops apps, and so on, and so forth. Everyone takes care of their own part, and they rarely interact with other sections of the company. That’s one of the reasons the Agile approach emerged in the first place – to crush down these walls between departments (corporate silos) and bring maximum business value through cross-areal collaboration.
That’s why the Agile approach promotes cross-functional teams. These are groups made up of people from different functional areas within a company, like sales, marketing, and UX. Their goal? To put customer needs first and shorten the time of solving issues. Instead of tossing the problem between the departments, a cross-functional team can tackle it much more effectively, mostly because it already consists of people from different departments. It shortens the time of customer care, improves communication, and has a good impact on potential innovations, as each member of the team can bring their unique set of skills to the table.
Team capacity in Agile
As Atlassian states, team capacity is defined as the ratio of units of work that a team takes on measured against the maximum units of work that a team can get through in that period of time.
How can we measure it? Usually, we need the Focus Factor first. It’s the team’s ability to remain focused on the sprint goals without any other distractions. We can calculate it by dividing the average number of completed story points from the last three to five iterations by the multiplication of available team member’s numbers and the total number of hours they’re available. The formula will look like this:
Having the Focus Factor value in place, we can now estimate Team Capacity. It’s simple – we just multiply the Focus Factor by the multiplication of available Team Members, Hours, and Days in the Sprint. The formula for a two-week Sprint with free weekends looks like this:
How to measure the success of an agile team?
Many indicators can help to measure the success of an Agile Team. To name a few (with some help from the Agile Alliance):
- On-time delivery that can be tracked by the Sprint Burndown Chart
- Completed Story Points during the Sprint
- Customer Satisfaction
- Business Value
- Product Scope
- Productivity
- Visibility
How to improve agile team performance?
Agile as an approach is never fully implemented. There is also room for improvement, as teams may feel burnout, or team members may have different opinions and approaches, leading to disruption within the team. Fortunately, Agile supplies us with proper tools to improve performance and/or morale.
First of all, it’s always a good idea to refer to Scrum Master. Part coach, part facilitator, they can help ease tensions between team members and align them with their the team’s goals and vision. Avoid micromanaging – the difference between meeting someone’s needs and watching over their shoulder is stark. Also, you must remember about ceremonies, especially about the Daily. It aligns team members with their work and allows them to avoid doing the same multiple times.
The same goes for Review and Retrospective – these events are occasions to summarize and improve potential flaws that happened during the completed Sprint.
Remember to keep the Agile Team relatively small (five to ten people). Encourage members to keep the product backlog up-to-date to track the progress and use chosen metrics to visualize how much work the team has done during the Sprint.
Picking the right people for your team
It’s always hard to decide which people would suit our Agile team best. However, a specific set of skills and traits make people fit into this kind of team. For example, cooperation and empathy are always more important than ambition and competitiveness, as Agile supports working together rather than against each other.
Also, people with the ability to adapt to sudden changes and focus on learning more will quickly find their place within the Agile team. During team gatherings, we need to balance the technical skills and soft skills – as Agile teams are often cross-section, it’s good to decide if we have experts in their niches or people with broader knowledge. The first one is less flexible but consists of experts in their fields, while the second one may need more time to work on a product but are much more adaptable to changes.
As seen, forming the Agile Team is no laughing matter. Properly constructed and managed team can bring enormous benefits for the business value. It’s always worth it to carefully craft – the return on investment will be worth the time and effort to create the great Agile Team.
