Quality in agile teams needs both breadth and depth. The common slogan that everyone owns quality can hide who takes on hard work. Cross functional does not mean flat skills. Teams need specialists who go deep, and generalists who connect the dots. Treating frameworks as a checklist leads to mechanical habits and weak results. Testers still add sharp value with risk thinking, test design, and feedback loops. AI can handle routine checks, yet it produces noise and gaps. Human judgment remains the guardrail. Map quality tasks to clear owners, ask better questions, and keep value visible. Progress follows from clarity, not slogans.
In this episode, I talk with Gitte Ottosen about cross functional teams, quality engineering, and how deep skills fit in agile work. We question the Everyone owns quality mantra. If all own it, who does the hard parts. Gitte calls out mechanical agile and the comb shape myth that makes people wide and shallow. We talk about what Scrum expects from a team and why testers still bring sharp value. AI may take easy tasks, yet we need critical thinking and solid test design to judge its output.
"But if you ask many Scrum masters today, and unfortunately a few coaches as well, what does the Agile manifesto say or what are the 12 principles of Agile? They don't know." - Gitte Ottosen
Gitte Ottosen is a test manager and quality coach with a strong focus on a value driven approach to software development. She has 30 years of experience in IT, primarily within test, test management and process improvement, in both traditional and agile contexts. She is focusing on supporting a quality mindset across teams and organizations in Denmark. As a self-confessed test and agile evangelist who preaches the need for a strong quality and value driven focus, Gitte is a strong advocate for a context-driven approach, a role requiring profound professional insight, passion, and persistence—qualities that she holds in abundance. Gitte is a dedicated trainer within the areas of agile and test and is a regular speaker at international conferences.
The move to cross-functional teams has become an article of faith in modern software development, especially among Agile practitioners. But as Richie and Gitte Ottosen discuss in the latest episode of Software Testing Unleashed, the reality is more complicated—and sometimes, the attempt to distribute responsibility for quality just leaves it adrift.
When organizations transitioned their testers into Agile teams, the expectation was that everyone would pitch in on testing and other quality tasks. “We start talking about the T shape,” Gitte recalls, referring to the expectation that team members develop broad secondary skills outside their core specialty. Yet, Gitte points out, “It's always dangerous when you say everybody is responsible for something because who then takes that ownership?”
In practice, developers, whose “passion” is software creation, often lack both the interest and experience in higher-level testing. Meanwhile, testers are suddenly tasked not only with their traditional craft, but also with supporting developers, coaching on automation, and sometimes even pipeline management.
This push for multifaceted team members sometimes misses the mark. “When people get very broad, they don’t get very deep in the competence level,” Gitte warns. She references metaphors like “T-shaped,” “π-shaped,” and even “comb-shaped” professionals. While developing a few deep areas of expertise alongside broader awareness is valuable, expecting every team member to be deeply skilled in everything leads to “very, very short” teeth in the comb—lots of knowledge, but only at the surface level.
For both testers and developers, this can result in cognitive overload and a decline in quality. Richie echoes this concern: “We load on the testers a lot of stuff they have to do now… so the pure testing part, the concrete thinking about what we can test—is no time for that.”
In the current conversation about “quality engineering,” there’s broad agreement that quality should be “everybody’s responsibility.” But Gitte underscores a critical reality: many Agile teams aren’t ready for this step. They lack testing maturity and expertise, and without someone deeply skilled in testing, quality engineering becomes an aspiration rather than a reality.
The solution isn’t to return to rigid silos, but to recognize complementary strengths within teams. As Gitte says, “Let people do what they're passionate about, then they become good at it.” Forcing testing tasks on those uninterested in them just for the sake of being cross-functional can harm both morale and software quality.
So, what can testers actually do to shift the quality needle within their teams, especially if they don’t have formal authority? Gitte recommends workshops like “quality to activity mapping” and “quality to people mapping” to make each person’s contributions visible and align with delivering customer value. The process is collaborative, not imposed. As she puts it, “It brings an awareness to the table… ownership of the team.”
This approach helps clarify how different team members can contribute to areas like requirements, automation, and infrastructure. The goal is for each member to “thrive at doing what they do best,” while collectively ensuring quality.
With AI poised to automate much of the “junior stuff,” there’s a risk that teams of comb-shaped generalists will lose their edge in more sophisticated testing. Gitte sees a continued need for critical thinking and deep expertise: “Sitting there reviewing the output of a test design made by an AI without understanding the test design technique, you don’t add any value whatsoever.”
If testers are to serve as the “gatekeepers” or “shepherds” of software quality in an AI-augmented future, they must retain—and deepen—their mastery of test design techniques, risk-based testing, and the principles of exploratory testing.
If you’re a tester on a cross-functional team, what should you focus on? Gitte’s advice is clear:
Learning by doing—applying theory in real-world contexts—is the fastest route to these goals. And while broad awareness is valuable, retaining your depth of expertise will make you the most valuable asset in your team as software quality grows more complex.
In the end, the path to better software isn’t about making everyone do everything. It’s about making sure the right people are empowered to do what they do best—and ensuring each cross-functional team has the depth it needs to deliver real value.