High-performance IT delivery is especially challenging with agile at scale where multiple teams create IT products that have to be combined to deliver value in the end-to-end business process. This puts distinctive demands on the training and coaching of team members working in cross-functional teams in such an environment. To know what to train in, we need to grasp what are the specific challenges, so we’ll do a minor diversion from our theme. In this blog we talk about several challenges. In future blogs, we will describe how to approach training and coaching for these challenges.
(This is the fifth blog in the series “How to train cross-functional teams”, for links to previous blogs please go to the end of this blog)
Standard Agile (for example as defined in the Scrum guide) is focused on a single team. So when scaling to multiple teams, it’s a challenge how to align across teams.
In agile at scale, we work with multiple (sub-)systems that depend on each other to deliver value to the user. Teams often take responsibility for one specific system. In some instances, there’s even multiple teams working on a single system. In these cases, it’s crucial to align across teams, but Standard Agile is focused on optimizing the work for a single team. Therefore, a lot of teams working in an agile at scale situation, fail on managing the dependencies with other teams.
This challenge influences a lot of different work areas and we don’t have space to talk about all of them. The following ones are those that in our experience have posed the greatest challenges.
Alignment of epics and features
A business process that requires multiple (sub-)systems to generate business value requires proper alignment of the user stories that are part of the various (sub-)systems. For this the teams involved need alignment in the epics, features and user stories. Standard Scrum or other team-focused Agile approaches don’t cater for this alignment. Agile at scale frameworks (such as SAFe®, Nexus, LeSS etc.) describe how to make this work, but it needs people to fulfill specific roles. Which, especially at the start is a serious challenge.
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 regression testing and acceptance testing). For a team it’s easy to focus their sprint planning only on the tasks that need to be done within the team, and forget the joint testing tasks. On the opposite end, there could be multiple tasks for the same joint testing, if all the teams plan for it. Management of test data and test environments can also be hard when testing across teams, because you need to do something in one system, check something in another system etc. Apart from not knowing enough about the other systems, there’s also the problem with having access. This challenge can of course be solved, which starts with being aware of it first.
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. Unfortunately, it’s quite common to instead start a “bug ping pong” match, trying to throw the problem at the other team.
Coordinate across teams
Teams often don’t realize they need someone to coordinate between teams. 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 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…
Priority-setting is difficult with multiple teams, because the priorities need to be aligned. There’ll be a problem when something in one team is low priority, that’s needed for another team’s high-priority story. Often, teams have different product owners with totally different priorities. Stories that’s needed by another team, should be high-lighted so they’re not drowned in all the other stories. The product owners need to align their priorities so that the teams can deliver what they’ve promised.
Support from outside the team
Often not all tasks a team needs to do, can be done by the team members. There are always specific knowledge and skills needed that are not in the agile team. This can for instance be about shared services, such as information security expertise, or architecture expertise. In agile at scale these knowledge and skills can be supplied by specific people or teams which can facilitate, but sometimes that’s not possible. There may be a challenge in how to organize support from the staff-organization for tasks that the teams don’t have expertise for. In very large organizations you even have so many specific tasks that you may run out of distinctive names for roles of people at higher layers of the model.
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? It can be really hard to determine which team should look into a specific issue. There need to be some sort of process in place. How can the first line support people determine which team (or multiple teams) should address the issue? Will there be a specific team that analyzes the issue before other teams are involved? How does the issue get included in a specific team’s sprint? There’s no right or wrong answers, but if the systems are in operation, you’ll need to handle client-issues so figure this out beforehand and adjust when the need arises.
Conclusion: Challenges of agile at scale
There are various specific challenges when working in an agile at scale situation, and we’ve discussed some of those. Of course, this is not a complete and definite list of challenges but those that we deem most important to address. We haven’t discussed how to address these challenges. That will be a topic for future blog posts.
What challenges do you see 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 is the fifth blog in the series “How to train cross-functional teams”, the first blog of the series is here: How to train cross-functional teams, the second blog is here: https://labs.sogeti.com/how-to-be-a-good-cross-functional-team-member/ , the third one is here: https://labs.sogeti.com/does-every-team-member-need-coding-skills/ , and the fourth one here: https://labs.sogeti.com/five-different-ways-to-train-a-cross-functional-team-member/ )
This blog has been co-authored by Rik Marselis.
About Eva Holmquist
Eva Holmquist has more than twenty-eight years of professional IT experience, working as a programmer, project manager and at every level of the testing hierarchy from a tester through test manager. She has also worked with test process improvements and in test education as a teacher and with the development of courses including a Swedish ISTQB Foundation certification course. Author of the book ”Praktisk mjukvarutestning” (Software Testing in Practice) as well as science fiction and fantasy novels. Eva works as a Senior Test Specialist at Sogeti helping clients improve their testing practices using her broad experience in system development, process improvements, and education. She is a frequent speaker and has during the last year held presentations about agile testing, DevOps and quality assurance, cognitive quality assurance and bias in artificial intelligence.
More on Eva Holmquist.