Our blog series is about training cross-functional teams. However, not all challenges can be solved by training only, therefore this blog elaborates on other solutions to challenges when working agile at scale.
(This is the eighth blog in the series “How to train cross-functional teams”, for links to previous blogs please go to the end of this blog)
When working at scale, teams will still have to do their own testing (such as unit- and integration testing). On top of that, there’s a lot of testing that needs to be done across teams (such as end-to-end testing, regression testing, and acceptance testing).
The identification of testing needs, that must be addressed across the teams, can be done on multiple levels. In a specific team’s planning, you can identify needs for other teams to test that originates from your team’s user stories. These must be communicated to the other teams. Some needs occur from the information flow between the systems. The business process is often a great source to identify these. In a joint test planning session with team representatives from each team, these needs are often easiest to find. Those representatives then bring the result into their own team’s planning.
Joint testing sessions are also a good way of speeding up the testing and improving communications. In those, representatives from each team tests together. Often, you handle your own system and communicate what you expect to happen, and what really happens in each system. For instance, team one’s representative enters information in their system, and team two’s representatives checks what happens in their system.
If there is a lot of testing that needs to be done across the systems, you can have a specific end-to-end testing team or a virtual team. Even if you have that, we need the specific knowledge gained by the individual team regarding their system. Therefore, even in those instances, joint testing sessions are needed.
Joint problem solving
Another challenge is problem-solving across teams. If there’s a problem, it’s often hard to pinpoint exactly where the problem is located. Thus, the need for joint problem-solving including debugging. When several teams are involved, we need to work together to find the cause of a problem and figure out a solution.
When a big enough problem arises, gather representatives from each team that may be involved and do a joint problem-solving session. When you’re looking at what happens in each system, and in their logs it’s often much easier to pinpoint the source. You can also change the logging to include more information to easier find the problem. These joint problem-solving sessions are often extremely creative, and great fun.
Coordinate testing across teams
There is a lot of coordination that needs to be done between teams relating to testing. This includes, but isn’t limited to, test data that needs to be synchronized to enable testing, joint testing, and test environments.
Teams often don’t realize they need someone to coordinate between teams. This can be done by a Quality Orchestrator, or a Test Manager responsible for all teams’ testing. There will be work that needs to be done jointly, but there’s also work that needs to be synchronized. For instance, you need to synchronize changes across teams. Both for planning when to do them if there’s a change needed in both teams and for the planning of testing if it needs to be done in one team and the other team depends on it. You also need to coordinate releases, test environments, deployment in test environments, interfaces, deployment in production, operations, and much more…
To facilitate coordination across teams it helps to have good agreements about how to handle the work across teams as well as good agreements about interfaces so that teams are less dependent. It’s also beneficial who in the team is responsible for what coordination. This can of course be a user story in each sprint, that different people take on.
Managing issues from operations
With multiple teams, it can be a challenge to manage issues from operations. How do you organize the management of client issues in the live environment? Different organizations have different needs so it’s hard to describe the best way of solving this.
There needs to be some sort of process in place. One way of doing this is to have a specific team that handles the initial analysis and determines what team or teams need to be involved in the problem-solving. Another way is to have generic user stories in each team for joint problem solving of issues from operations. It’s common to have a portion of the sprint log dedicated to solving operational issues but it’s usually used for issues that have already been determined to belong in a specific team.
There are various specific challenges when working in an agile at scale situation, and we’ve discussed some of the solutions to the most common ones relating to testing. Of course, depending on the organization there are other possible solutions. Hopefully, you can get some ideas from our description. The next blog in this series will address the remaining challenges.
How do you address the challenges when working agile at scale?
Please, let us know in the comments below, we will incorporate your challenges in our future blogs as well!
This blog has been authored by Rik Marselis.
This is the eight blog in the series How to train cross-functional teams, the second blog is here How to be a good cross-functional team member, the third blog Does every team member need coding skills, the fourth Five different ways to train a cross-functional team member, the fifth Challenges of agile at scale , the sixth Do cross-functional team members need business knowledge?, the seventh What’s the difference between training on-line and on-site?