Many of our clients have moved into a tribe and squad structure over the past year or two, and they have encountered some challenges along the way which I thought would be interesting to share with everyone. The goals were for teams to be more Agile, delivering faster to the customer and to add value earlier.

Normally, squads have no more than seven people in them (including the product owner and squad leader/Scrum Master if one exists), and could consist of similar to the following structure:

Spotify Model

Spotify is commonly referred to as the “ideal” organisation that has moved to the tribe/squad structure. Employees are often encouraged to watch the Spotify model videos as a guide to how it should work.

While Spotify is a great example, organisations need to take into account their own industry challenges, as it may not be feasible to put such radical changes into practice in a complex environment with highly integrated applications, while remaining compliant and secure.  For example, a company developing safety-critical software, or a financial organisation with multiple vendors and security risks.

You can check out the YouTube video on the Spotify model here. It is a really interesting model and worth looking at if you haven’t seen it before.

It is also worth noting that Spotify started out using Agile methods from their inception, so one big advantage for them was that they didn’t have to go through a large-scale transformation.

Agile training

Often, when moving into Agile ways of working, the scrum framework is recommended, as it has simple rules and techniques around how the team works. It also includes the means to inspect and adapt the way of working to deliver what the customer wants.

However, it is important that adequate training is offered. This includes the squads who will be doing the work and building the product, as well as the wider organisation. They all need to understand how working in an Agile environment differs to traditional methods, and what it means for the teams to be self-managing and left alone to focus on their goals.

Having an experienced Scrum Master is valuable as teams adapt to Agile methods, as they can mentor and coach the team in Agile practices, such as the activities required in Iteration planning, daily stand-ups, reviews and retrospectives. Over time, as the team becomes more mature in Agile, they can rotate the role of squad leader/Scrum Master, rather than this being a full-time role.

Agile coaches are also an effective way of helping the teams to challenge themselves, enforce ‘the rules’, and ensure that all team members know the goals of the ceremonies, and the reasons why the whole team needs to be in attendance. 

When moving to Agile, many teams also struggle with breaking down the user stories to small tasks that can move across the board quickly, often resulting in more of an iterative Waterfall model, where testing is still getting squeezed at the end of each iteration.  This often leads to iterations failing and testing being seen as the bottleneck – which should never be the case, as the whole team is responsible for quality.

Autonomous teams

The tribe/squad structure emphasises the need for all squads to have the skills and capability to do everything themselves (including release management), and team members becoming cross-functional to help each other out where needed. This can mean that business analysts, developers and testers are responsible for performing their specialist skills across multiple applications and technologies.

When new teams form, each member brings with them a different set of skills based on their BA, development and testing expertise, which may previously have been across only one or two domains. This requires a lot of upskilling for individuals to pick up other domains that now require their attention, often resulting in a squad’s throughput slowing down for quite a period of time while the cross-skilling occurs.

Test automation

Agile teams require a greater level of test automation to allow for faster delivery, while having confidence that the product delivered meets the expected quality criteria. As a result, manual testers normally need to upskill in automation, so that they can automate their tests during iterations as the teams build their product increment.

While it can feel like the team is slowing down initially, squads need to allow the time for automation to happen within the iteration to reap the benefits of automation as the product increment grows. Focusing on iteration goals and delivering faster can result in squads taking the approach to test manually now (“we’ll automate later, let’s just get this across the line”).  However, looking at the bigger picture, the time spent on these tasks would have benefitted the team (and overall product) in future.

Getting automation right takes time. You need to consider the tools (appropriateness, licence costs, easy to learn, maintainable, etc.), skills required, how to correctly set up the frameworks, ownership when the project is complete, etc.  Therefore, an automation strategy that considers all these factors is recommended.

Performance and security testing

Autonomous teams as a goal can be difficult to implement, especially with specialist skills such as performance testing or security testing. It may not be feasible for each squad to pick up all performance testing tasks, but it could work for the performance test execution and analysis if it is picked up by some squads. However, the generation of scripts will still be carried out by the specialists.

Similarly, the squad could learn new techniques to develop and test for security risks, such as SQL injection. This aids in the move to shift testing left and finding defects as early as possible.

Unit testing

As we all know, it is often difficult to get some developers to do any unit testing, let alone automating it, as they go to ‘shift left’ and move towards the bottom of the automation pyramid.  However, developers’ unit tests are critical in Agile teams, and preferably those tests should be automated as they go along. 

If the ultimate goal is to strive towards a Continuous Integration environment, both tests and builds must be automated to providing fast feedback so defects are found and resolved quickly.

Integration testing / testing across multiple squads

If the architecture within the organisation is very complex, changes made by some squads could adversely impact other squads and areas of functionality. There needs to be good communication between squads, or there could an increase in the number of production incidents. Alternatively, the architecture could be re-engineered in order to create independent modules, or the use of web services or APIs.

Good impact assessments need to be carried out by developers for any code changes. This ensures adequate regression testing coverage and minimises the risk of defects being deployed to production.

Preferably, this needs to occur in the planning stage where the design of the solution is being discussed. It is good practice to get architects involved in planning sessions to avoid later rework.

Shared test environments

You may see the number of teams grow and the amount of change increase, but it also pays to consider the approach to test environments. If environments are shared across multiple squads, you might find yourselves tripping over each other when making changes.

Test data could also become problematic. One team could generate test data for their purposes, then another team uses that data, meaning it is worthless for the team who created it. Consider planning ahead and perhaps looking at automating the creation of test data, or perhaps introducing the ability to stand up and down test environments as needed.

Keeping consistency across multiple squads

Practices and Disciplines may be created to ensure each tribe and squad are following consistent practices, and that minimum standards are being followed. E.g. in the realms of business analysis, development and testing. Each tribe would then have a BA/Dev/Test chapter lead as a representative into the overall discipline, feeding information between their tribe and the discipline, and ensuring that their tribe is following best practices and minimum standards.

However, considering each squad is able decide their own way of working, there is likely to be inconsistencies. For example, in the test management tool each squad chooses to use, some teams may use TFS, ALM Quality Centre or JIRA. This can cause challenges in sharing testware, and possibly consistent reporting, across teams.

Practices and Disciplines can also help guides teams on tool usage, avoid duplicate licence costs, creation of additional frameworks, and more. They may also have the means to upskill members of the squads where a gap lies, such as if an iOS developer needs to pick up Android development skills, or a business analyst requires new test techniques to assist in certain testing tasks.

With organisations world-wide altering their way of working in the technology space to deliver value to the customer faster, this means there is a greater a focus on collaboration with business users, and a stronger emphasis on shifting left and an increase in test automation. This requires individuals to change their mindset and challenge themselves to pick up new skills.

The challenges that are encountered along the way will continue, but as long as teams learn from them and continue to improve, this will surely lead to success.