RAMIT AGARWAL

We have already discussed the squads and other different teams and groups here.

In this post we will take a deep dive into a squad. But, before that quick revision on what is a squad.

A squad is a small, self-sufficient & empowered team, usually 6-12 people, that focuses specific tracks within a project and works together to deliver value quickly. Together they are a “whole team” and they don’t need anyone else to get things done in the product that they own.

Squads are further organized into tribes to ensure alignment and scalability.

Guiding Principals of a squad

• Customer is at the center of work. A squad should show deep understanding of the customer challenges, and have empathy with the customer
• Persistent ownership supported by servant-leaders. A squad owns all aspects of the product, including user experience, priority, delivery as well as the process. They are supported by servant-leaders who put the squad’s needs first and help resolve external conflicts and dependencies.
• Empowered to drive towards Business outcomes. Every squad team member is held accountable for delivering results as per OKRs. They are expected to deliver outcomes and not output.
• Test-and-learn, with agile execution. A squad is constantly experimenting with approach, learning, and adjusting based on ongoing learning.

Characteristics of a squad

• Cross-functional: To be self-sufficient a squad must have team members with different skill sets.
• Collaborative: Open communication, cross-training, co-located to understand the challenges each one is facing and brainstorming ideas how to overcome those challenges together in pursuit of a common goal of creating meaning outcomes. Such team members are called “T-shaped”. The vertical line in “T” represents the individual’s core skill set and the horizontal line represents general understanding of other’s skills. More on “T-shaped” in a different post.
• Autonomous: A squad has a flat structure where squad members are expected to self manage and organize themselves. Hence the recommended size of a squad is somewhere from 6-12.

Team roles in an agile squad

While each project is different, a squad usually has the following team members

• Scrum Master – Acts as the facilitator for the team, ensures external dependencies are resolved in time for the team to perform best. According to Agile Alliance

“The Scrum Master is the team role responsible for ensuring the team lives agile values and principles and follows the processes and practices that the team agreed they would use.“

• Product manager – Depending on scope, may define the product vision for a tribe. Aligned to a single product and is responsible for defining the product vision and OKRs. Responsible for product definition, research and experimentation for prioritizing.
• Product owner – Responsible for maintaining backlog, writing user stories and delivering by validated features, maintenance and technical work.
• UX designer – Sometimes shared between multiple squads depending on scope
• Architect – Shared by multiple squads
• Tech Lead
• Engineers – This can include developers and testers
• QA
• Agile coach – Shared between multiple squads.

Each of these roles will have their own definitions, we will not go into details of that.

Although the squads are self-sufficient, they can’t work in isolation because the overall program success depends on how good every squad, every track is delivering. They are part of a tribe and each member is connected to chapters and guilds.

This is how big companies try to stay fast and flexible.

Types of Agile teams

Here are the 6 team structures for agile. Now, which team structure to choose, will depend on factors like cost, availability and type of project. There is no good or not so good team structure, each will have its own advantages and disadvantages.

• Generalist – As the name suggests this type of team structure includes team members who can be called “jack of all”. They have diverse knowledge and can perform a wide variety of tasks without delving too deeply into any specific task. This is hard to scale so it works well in smaller teams.
• Specialist – Everyone in the team is a specialist in a different skill-set and is responsible for the tasks that fall under their domain. This structure is common in larger teams. One of the drawbacks of this structure is that people will end up waiting for their next task. The downtime can be minimized by cross training team members.
• Hybrid – This is a combination of the generalist and specialist team structures. This type of team has specialists to focus on complex tasks that need their expertise, while the generalist will work on bringing those tasks together to create a whole product.
• Transitioning – More than a team structure this is a phase used to define a team transitioning to agile ways of working. It is important to talk about transitioning teams because these teams need a lot of support and motivation to ensure success. This team will include agile coch/SME to help manage the workload, ceremonies etc.
• Parallel – In this team structure, everyone changes roles with each new iteration. For example, everyone is developing in 1 sprint and then everyone will move to testing in the next sprint. This approach requires extensive cross training and highly motivated individuals who can adapt.
• Sub-team – This structure is a team within a team. This type of team structure is used when the sub team can work independently on 1 aspect of the product but the overall product delivery of the project is dependent on the whole team completing their respective parts and combining to create a bigger picture. This type of team structure works well where the organization as a whole practice agile.

Benefits of the agile squad

• Knowledge Sharing, expertise and enhanced collaboration – When people with different skills work together to solve a common problem they end up sharing what they know, enabling deep understanding and expertise across their functional area. Each member completely understands all aspects of the projects and processes removing silos.
• Accelerated Product Development – As a complete team with all required skillset and availability they do not have to wait for others. They can continue to test, release and integrate the features every sprint.
• Increased Efficiency and Productivity – A squad creates its own delivery processes, helping them define what works best for the work they are doing and hence allow them to increase productivity. In agile, each squad looks at the prioritized backlog and breaks it down into tasks and sub-tasks. This helps them clearly understand the effort and allows them to take only what they can deliver and the stories that are ready with no dependencies.
• Improved Ability to Respond to Change – A change is no longer considered a change request that must go through change control board for approval and funding. Squads are meant to be flexible and they follow a prioritized backlog to define what is next. They don’t get stuck in long-term plans. They are capable of changing focus quickly keeping up with changes in user demand or strategic goals.

Disadvantages of the agile squad

Squad based agile methodology is a good practice for delivering product faster to the market but it may not work in every situation. Before adopting this methodology it is essential to understand the situations where it will not work. If the existing product is tightly coupled that changing one area of the code will impact different areas then this will create external dependencies.

Squad model is excellent in eliminate knowledge silos within 1 particular squad. But, it creates knowledge silos among different squads. These silos must be carefully managed with effective communication between squads. Hence, maintaining tribes, chapters & guilds are critical to eliminate these silos.

Scope, time and cost are considered the edges of a golden triangle in project management. The scope of an agile is unknown, because the team is focused on improving the product and delivering value. As a result the overall cost and time required is unknown.

Documentation in agile is “just in time”. As a result, it is usually less detailed often times not there. There is no traceability to the documentation.