Quality coaching in SAFe means coordinating development and testing activities beyond the boundaries of individual teams. SAFe (Scaled Agile Framework) connects several teams in an Agile Release Train but leaves open who steers quality across all of them. Quality coaching fills that gap with requirements coaching, process workshops and defect management at every level.
Key Takeaways
- Organizations that move straight from waterfall to SAFe bring old baggage along: fixed target dates without a clear scope, where functionality gets cut until the date fits, which systematically undermines quality.
- Development teams that only know their own story cannot secure quality across the release: defects appear because nobody knows how their component fits into the overall business process.
- A physical process simulation, in which testers from different teams act out their dependencies together, builds a shared understanding of the product faster than any document.
- Defects at the cross-team level stay unresolved because no team feels responsible: a designated defect coordinator per release train is the pragmatic answer until the teams take on that responsibility themselves.
- Negative test cases and edge cases require business knowledge that is often missing at every level in SAFe transformations and rarely travels efficiently from the solution level down to the development teams.
What Quality Coaching in SAFe Means
Quality coaching in SAFe is a role that coordinates responsibility for quality across the boundaries of individual development teams. It closes a gap that opens up when scaled agile frameworks like SAFe bring several teams together on one shared release and one shared system. Built-in quality works inside a team, but between teams nobody owns it by default.
In agile work, quality is the development team’s job. Everyone on the team shares it. That works well in a single Scrum team, as long as the team stays in its own bubble.
SAFe adds another level above the development team: the Agile Release Train. It combines the work of several teams toward one release. That means the results of the individual teams have to fit together, and that fit is exactly what needs testing. In the standard setup, nobody is responsible for this coordination.
Quality coaching is more than test coordination. Depending on the situation, it also means communication coaching, requirements coaching and method coaching: everything that together makes sure the end result is of usable quality.
Why a Quality Gap Opens Up after the Transformation
The gap appears because teams moving from waterfall to agile bring along a way of working that stops at their own piece. People who spent years in waterfall are used to working through their test cases and being done once their own results check out.
After the switch, a tester often still sees the job as testing their own story and reporting it as done in the review. What comes next drops out of view: the feature that has to be rolled out to the system together with the stories of other teams.
Teams never set up any agreement with each other on the same feature. People no longer even knew that such coordination was needed. The consequence: at the development level, variables were named differently, and at the business level, validations behaved differently. On the same system, that led to contradictions.
Many of the people involved are simply overwhelmed. They don’t know what they need to do to make the overall result work. Even a simple question goes unanswered: if ten development teams work in one Agile Release Train, who provides the test environment all ten teams test on? At first, every team says it is only responsible for its own tests.
How to Analyze the Quality Gap
Every intervention starts with analysis. Before you change anything, you need to understand how the teams work and why certain defects show up at the product level.
It helps to sort the root causes. Are the defects down to the methodical approach? To communication, because A doesn’t talk to B? Or are they architectural, because something already went wrong in planning when the full scope wasn’t known?
A structured interview based on a questionnaire makes the picture reliable. It covers all roles and levels: testers in the development teams, Scrum Masters, Product Owners, Product Managers and engineers at the higher levels. The central question is always the same: how do you see your responsibility and your influence on the product as a whole?
The results are often sobering. At the development team level, the product itself is sometimes completely unknown. A team knows it is supposed to add an attribute to an interface, but not what the interface transmits or how it fits into the business process. In some cases this lack of knowledge reaches all the way up to the Agile Release Train, which means no better guidance can come from there either.
Simulate Business Processes Instead of Explaining Them
One effective way to build a shared understanding is a physical simulation of the business processes. Testers from the teams involved walk through the complete processes together in one room, with paper on the wall.
Everyone takes on a role in the process. One person is the ID generator and creates an ID. The next says they need an ID, looks up data for it and goes to their database. The database returns the requested data. Station by station, the whole process gets played out.
The simulation works because it answers questions that stay open in daily work: Who am I working with? What does the person before me do, and the person after me? What exactly do they need from me to do their job? And what does the whole thing add for the company?
The result is that everyone understands their own place in the bigger picture. Once people have walked through the process, they start looking left and right in development and testing. Joint tests across several teams grow out of that understanding. A tester will say they want to check that the ID and the data work together, that they need three other teams for it, and then set up a meeting.
Requirements Have to Be Explainable, or They Go Back
A requirement that can’t be explained clearly in a short time is not ready for implementation. That simple rule makes a useful filter.
The rule of thumb in coaching: if an epic, a feature or a story can’t be explained in ten minutes in a way that clears up all critical questions in the five minutes that follow, it goes back. It simply isn’t ready for anyone to work on it in a meaningful way.
Definition of Done and Definition of Ready are taken for granted in agile work, and they steer the quality that comes out. In a company that decides on SAFe at short notice without thinking it through, these artifacts don’t appear by themselves. They have to be established first.
You can’t put a team that only partly understands how SAFe works on this task without guidance. Otherwise you get work results for their own sake, not for the sake of quality.
Who Owns the Shared Test Environment
In an agile setup, responsibility for the cross-team test environment belongs to the system architect. The first and most important step, though, is to recognize that right now, nobody owns it.
At the team level, the lead can be assigned pragmatically. The obvious choice is the team that already runs the most comprehensive test environment with the most connections to other services and teams. That team takes the lead and the others contribute. This puts responsibility where it belongs in the agile model: with the development team.
Things still get stuck at the boundaries of responsibility. As long as not every contribution is clearly defined, not everything fits together. That is where the system architect comes back in and has to sit down with all interface partners to align the pieces.
The mix of old and new systems makes this harder. New microservices sit next to legacy monoliths with completely different release cycles. Still, an environment where everyone can test together is a big step forward from the starting point, where there was none at all.
The target picture goes further. When a service releases a new version, it should be deployed to the environment automatically, and the service itself should announce that something new is available. Today, people often go through release notes instead and work out what needs to go onto the test environment. Tedious, but it works.
Defect Management Needs a Clear Coordinator
Defects that show up in the space between teams need a designated coordinator, or nobody feels responsible. In that shared space, nobody caused it, and nobody wants to have caused it.
The defect coordinator first takes in all defects for an Agile Release Train or a solution. They check which area a defect belongs to and talk to the person responsible for that area, who then brings in the right development team. Defects are collected centrally and distributed to the working level in a coordinated way.
When a defect affects several teams, there are several ways to handle it. It gets passed on from team to team, or it gets tasks that each team works on separately, or it gets cloned for each team. This is deliberately where the quality coach’s responsibility ends, because interfering with how teams work would hurt their self-organization.
A standardized process is recommended so that nothing slips through the cracks. Teams take the recommendation into their retrospectives, but often answer that nothing slips through for them. That attitude is not far from the developer who says he doesn’t make mistakes.
Business Knowledge Is a Bigger Gap than Technology
The biggest open weakness is not in technical testing but in business understanding across team boundaries. Within teams, component testing and integration testing work well. The problems appear at the cross-team level.
Along the end-to-end test chain, the technical understanding of the application is often still there, but the business understanding is gone. A tester can then technically try out every combination on an interface but doesn’t know, for validation, whether a particular case should be allowed through at all.
“People only see what’s in the story. If nothing from the overall business process says that certain things must not work, they don’t know it. So they test it, and it passes.”
(Andreas Neumeister)
As long as the business side is only partly understood, negative test cases and edge cases get left out. If you don’t know what must not happen from a business point of view, you can’t test for it. The happy path gets tested, and the rest falls through.
There is also no efficient channel for moving business knowledge from the solution level through the Agile Release Train to the individual development teams. When a solution manager talks to 20 or 25 teams, each piece of content only matters to some of them. The teams it doesn’t concern tune out, and nobody has time to tell the same story 25 times, team by team.
Waterfall Deadlines Undermine Quality
Waterfall target dates carried over unchanged into agile work are among the most damaging legacies of a transformation. In waterfall, fixed dates were easier to plan for. Those dates came along into agile, but now with an unclear scope, because the work is agile.
The result is a contradictory mandate: fixed date, open scope. To hit the date, people keep tinkering with the functionality until it fits. The date is met, but the application is no longer the one anyone wanted.
For quality assurance, this is poison. Functionality is constantly taken out, put back in, reprioritized, and at some point the call is for more functionality and fewer tests. Legacy habits like these make quality work harder than it needs to be.
The real goal of quality coaching is to make itself unnecessary. The basic agile idea that responsibility for quality lies with the development team is only fulfilled when everyone accepts that responsibility, acts on it and knows how. That includes not only the tester but also the requirements engineer and the developer, backed by a shared understanding of quality and common quality goals.
Frequently Asked Questions
Is it enough in SAFe for each development team to ensure its own quality?
No. In an Agile Release Train, multiple teams consolidate their results into a single release and a shared system, and it is precisely this integration that must be tested. In the standard setup, no one is responsible for this. Quality coaching takes on this coordination and combines it, as needed, with requirements, methodology, and communication coaching.
What causes errors that only become apparent when multiple teams work together?
They can be categorized into three groups: the methodological approach; communication, when Team A doesn’t communicate with Team B; and architecture, when the full scope was unknown even during planning. Typical symptoms include inconsistently named variables at the development level and validations that operate differently from a business perspective. This leads to contradictions within the same system.
How is a shared understanding of the overall process established within a Release Train?
It is established more quickly through a physical simulation than through documents. Testers from the participating teams walk through the entire business process in a room, with paper on the wall, and each takes on a role: one generates the ID, the next searches for data related to it, and the database returns the results. Afterward, the testers spontaneously arrange cross-team tests.
How can you tell if a requirement isn’t yet ready for implementation?
By how easily it can be explained. As a rule of thumb: If an epic, a feature, or a story cannot be explained in ten minutes, and if all critical questions aren’t clarified within the five minutes that follow, the requirement is sent back. “Definition of Done” and “Definition of Ready” aren’t a given; they must first be established during a short-term SAFe implementation.
How can you organize a test environment where multiple teams engage in testing together?
In an agile setup, this responsibility falls to the system architect. Pragmatically, the team that already operates the most extensive test environment with the most connections to other services takes the lead, while the other teams contribute. Problems arise at the boundaries of responsibility as long as contributions aren’t clearly defined. In such cases, the system architect coordinates with the interface partners.
Why do bugs often go unresolved at the cross-team level?
Because in the cross-team space, no one sees themselves as the cause, and no one wants to be. The pragmatic solution is to appoint a dedicated bug coordinator for each Agile Release Train or solution. This person initially accepts all bugs, assigns them to a specific area, and speaks with the person responsible for that area, who then involves the appropriate development team.
Why are negative test cases and edge cases often not tested in scaled environments?
Because the domain knowledge is lacking, not the technical expertise. A tester can try out all combinations of an interface, but during validation, they don’t know whether a specific case is even allowed to pass. If the story doesn’t specify the overall business process, the happy path is tested and the rest falls through the cracks.
What happens when fixed deadlines from the waterfall model are carried over into agile work?
This creates the contradictory requirement of a fixed deadline with an open scope. To meet the deadline, the functionality is tweaked until it fits: remove features, add them back in, reprioritize, and at some point, this means more functionality and fewer tests. In the end, the deadline is met, but the desired application is not.
