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.
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.
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.
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.
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.
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.
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.
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.
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.
Splitting the team into squads allows us to pair with the client more often; it is important to keep rotating between squad members.
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.
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.
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.
The final step of managing delivery to production remains centralized, with positive results.
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.
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.