Working in Squads

Working in a large team presents its own set of challenges, more so when the team is distributed. One such challenge is to retain agile practices that provide actual value, over those that are enforced because a manual says so. Agile teams teach us to be reactive to unexpected situations and follow a continuous improvement processes. This helps us evidence scenarios which may not be problematic at first, but aren’t always suitable for certain conditions.

In large teams, we try to solve the needs of various facets of the business. This atmosphere isn’t very conducive to continuous improvement, as our ideas could get lost amidst several voices. When we began to face this challenge, we decided to split the team into smaller groups called squads. This blog explores our experiment and how we fared at it.

Why we did    [Why work in squads?]    

• Large teams can hinder collaboration and communication among members. Making decisions, reaching a consensus and voicing improvement ideas get harder as the teams get larger.
• The coordination is centralized and does not give much scope or space for self-organization of the team 
• When a team is large and the team members have different perspectives of the business, it is easy to lose the big picture and start concentrating on the details. Business objectives end up taking a back seat. 
• "If it works do not touch it." We demonstrate this phenomenon in the way we code  and our team processes. If things work in a certain way, is there no need to change it?  That’s not entirely true, we can always be better. The process in which we were working previously may have had a lot of value, but it can get outdated
• Practices such as daily standups can be futile for large teams where people focus on different issues, making several details irrelevant to other members

How we did this - Our approach to squads: 

Forming teams

Form three teams with an average of 6 members, in order to balance the load between client members and consultants. These teams are guided by lines of business that they can focus on, for a medium term. 

Clear Objectives

Each squad has a clear goal that can be achieved in a short timeframe. It is important to work together on a common goal, so all members are aware at all times of what they hope to achieve.

Business Analysts

If you're looking to add value to the business, it is essential to have at least one expert in each squad who can give clear guidelines of what you’re hoping to achieve. We had three analysts in the team, and the first thing we did was to assign each BA to a squad. We then realised that they can actively participate in more than one squad, which worked out excellently for us. 

Kick off the objective plan

Before starting the implementation and development, conduct an informative session with all members of the squad, where the business analyst clearly explains what they expect and why; so everyone has a shared understanding. 

Squad Amigos

When we started with a card, we used to do a session called 3 friends, which was formed by a business analyst, a developer and  a tester. Initially, the sessions can be only among a few members in the squads but we can then increase it and take more responsibilities. This typically reflects self-organization where our accountability also increases. 

QA

It’s often assumed that the QA stage can be made within one squad alone. But with time, it’s important to open QA out to a larger group, because certain changes or features need to be reviewed by other squads, especially if they have more knowledge on it.

Standups

• Internal

At the end of the day we hold a standup, where each member or pair speaks of what they have done, what they intend to do, the problems they have had, etc. The standups are scheduled at different times through the day as there are people like BA's that may be in more than one squad and would like to attend all standups.

• External

At the beginning of each day, all teams meets and one person from each squad informs in a general way what they did to reach the goal. Without getting into the details, the member identifies if something is relevant to share to the group as problems, or transverse solutions.  This keeps the standups short and crisp. 

Rotation and Pairing

• Internal

Splitting the team into squads allows us to pair with the client more often; it is important to keep rotating between squad members.

• Among squads

We start the rotation between squads after finishing the goal, where a member of a squad can go to another squad without leaving work undone.

Retrospectives

• Internal

We perform retrospectives between squad members where we involve the Iteration Manager, someone who watches the process in all squads and can generate faster feedback about what has not worked in other squads.

• External

The Iteration Manager facilitates session when the period ends, he/she exposes statistics and relevant information to the whole team, this is the space where you can also discuss common topics and share solutions between squads. 

Deployment:

The final step of managing delivery to production remains centralized, with positive results.

Conclusions and Benefits:

• Organizational independence: self-organizing teams with freedom of action.
• Reaching agreements is easier and faster.
• More efficient and rapid feedback.
• We can try a practice in one squad to see results, and extrapolate to the other squads if they work or discard without causing too much impact on the whole team.

We have seen after nearly five months of work in squads, the results are positive. Undoubtedly, the important thing is to learn from mistakes and enhance the successes, as this does not end, it's a way of learning and improving daily.