Cross-functional teams in agile are groups where members each hold deep specialist skills and use those to support the team beyond their core role. The risk is breadth without depth: when everyone is expected to do everything, no one does anything well. Quality stays a shared responsibility only when each person understands their specific contribution to it.
Key Takeaways
- Saying everyone is responsible for quality without a named owner means no one takes ownership, and most agile teams lack the testing competence to carry that responsibility collectively.
- Broad skill profiles, the so-called comb shape, produce shallow expertise across the board; two or three deep competences per person is the realistic ceiling for genuine excellence.
- Reviewing AI-generated test output without understanding test design techniques adds no value, because you cannot spot what is wrong or missing if you do not know what the correct output should look like.
- Testing context determines the tester’s contribution: someone without a technical background delivers most value upstream, shaping acceptance criteria and process models, not downstream in the pipeline.
Mechanical agile breaks the cross-functional team before it starts
Many companies adopt agile by copying its surface and skipping its reason. They read part of the Scrum guide, install a few roles and ceremonies, and call the result agile. Gitte Ottosen calls this mechanical agile, and it is where cross-functional teams begin to fail.
The tell is simple. Ask a Scrum Master, or even some coaches, what the Agile Manifesto says or what the twelve principles are. Often they cannot answer. That knowledge is the foundation of a cross-functional team, because it explains why the team works the way it does.
There is a difference between doing agile and being agile. Doing agile treats the method as a hack you bolt on. Being agile means the team understands the purpose behind the practice and acts on it.
What Scrum actually says about a “developer team”
Scrum does not say testers are unnecessary. The Scrum guide uses the term “developer team,” but a developer in that sense is any team member with specialist knowledge that supports the team’s ability to deliver value. That includes testers, business analysts, and others.
The misreading has real consequences. Gitte has seen companies fire their test managers and testers on the logic that Scrum demands a developer team and developers should now do everything. That decision rests on a term taken out of context.
A team member’s job is to contribute deep skill toward delivered value. Testing is one of those specialties, not a task that vanishes when the org chart changes.
Quality engineering is a strong idea built for a world few teams live in
Quality engineering, treated as a shared mindset where the whole team owns quality, is worth wanting. A high-performing team that takes full responsibility and carries the competence to test well is the goal. The problem is the gap between that goal and most real teams.
Most agile teams lack the competence in testing to make this work. When quality engineering is layered on top of everything else a team already does, without anyone holding the skill, the result is worse, not better. The mindset is sound. The maturity is missing.
“Quality is value to someone at some time who matters.” That definition, attributed by Gitte to Jerry Weinberg and extended by James Bach and Michael Bolton, gives the work a target: find the people who matter, and deliver value at the right time.
We just have to remember that most of us don’t live in the perfect world. We live in the real world. We don’t live in unicorn world. — Gitte Ottosen
Why “everyone is responsible” can mean no one is
When everyone owns something, ownership can dissolve. Some teams take collective responsibility seriously. Many do not, and quality slips through the cracks between roles.
For most developers, testing beyond unit and unit-integration level is not their passion. They chose their craft to build software, not to test it broadly. That is not a flaw, it is where their skill and interest sit.
People who love testing exist too. The better move is to let team members work where their passion lies, because passion produces skill. Forcing someone into work they do not care about does not produce good results. Developers should still test, but they need the skill set and someone to support them in building it.
Going too broad makes a team good at nothing
The shift from I-shaped to T-shaped specialists has kept stretching. T-shape became pi-shape and M-shape, three deep competences, which is still workable. Then came talk of comb-shaped people, with many teeth and every tooth short.
That image carries the warning. A comb has many skills and no depth. When everyone is expected to do everything, nobody does anything really well.
The pressure is not only on testers. Developers carry the tooling, the pipeline, and the cognitive load of the full delivery chain. Gitte points to a drawing by the Comic Agile cartoonist titled the agile team’s cognitive overload, which captures how widely the weight is spread.
Aim for N-shape or M-shape: two or three areas of real depth, plus the ability to support teammates outside your core. That is what Scrum describes, and it beats spreading thin.
How a tester adds value when classic testing is off the table
Find where your value lands relative to delivered value, then work there. The answer is context-dependent, not fixed, and it changes with the team and the project.
A tester without a technical background cannot review unit tests or support the pipeline. That same tester can help the product owner write good acceptance criteria, review feature descriptions, and strengthen the intake of requirements. The value moves to the front of the development model, before code exists.
A tester with a technical background can do test automation, support unit and unit-integration testing, and help with the pipeline, while still bringing test design techniques and exploratory testing to the table. Same role, different contribution, shaped by skill.
On the customer side of a project, where a hard line separates you from the vendor’s developers, the value points toward the business. You map workflows, draw process diagrams, and use them both to test and to teach the developers what the system is meant to do. Testers often understand the intended use of a system better than anyone else.
Where to start: fix the foundation before you reach higher
You cannot fix everything at once, so start from scratch with unit and unit-integration testing. As the team matures there, move your focus elsewhere.
A tester can drive this without writing code. You can explain structured testing, help developers decide what to test, and make sure the tooling supports what they need to do. Spend a period reinforcing the developers’ maturity, then shift toward the work only a tester can do well.
The real-world starting point is rarely clean. User stories and feature descriptions are often poor or missing, acceptance criteria absent, and some developers have spent decades never working with testing and no interest in starting. Map your context first, then choose where to begin.
Two mappings that put quality ownership in the team’s hands
The Newsroom approach offers two workshop tools for continuous improvement: quality-to-activity mapping and quality-to-people mapping. Both make each member’s share in quality visible.
For quality-to-people mapping, run a workshop using six key areas, among them quality awareness, automation, and infrastructure. Put those areas down the first column of a matrix and the team roles across the top, developer, tester, business analyst, and others. Each person brainstorms their share in each area and what they can contribute.
Once the board fills with sticky notes, the team prioritizes, because not everything improves at once. You can prioritize by people or by the DevOps activities where quality matters.
The point is ownership. The improvement is not pushed in from outside. It surfaces awareness inside the team and shows members they have value to bring. It also breaks the reflex that equates quality with testing alone, when quality assurance, quality control, and testing are distinct things.
AI shifts the work, but only skill makes the shift safe
AI can review user stories, draft acceptance criteria, and generate Gherkin scenarios. It still takes a person with judgment to check whether the output is right. Critical thinking is the skill that matters most here.
There is a contradiction worth naming. Reports describe a future where testers act as reviewers and gatekeepers of AI output, while the measured competence level of test professionals is declining. You cannot guard the gate if you do not know what good testing looks like.
Test design techniques sound old-fashioned and stay essential. Reviewing AI-generated test cases without understanding the underlying technique adds nothing, because you cannot tell whether the output is sound. Gitte has caught basic ChatGPT producing far too many test cases for a simple request, precisely because she knew the technique well enough to see the error.
Trust is what testing builds. To give stakeholders confidence that what ships is safe and delivers the expected value, the team needs the skill to verify that the requirement was interpreted correctly and that the AI followed that direction.
What a tester should learn to stay valuable
Build depth, not breadth. A handful or two of test design techniques, understood well enough to use daily and to spot when AI output is wrong, is the base.
The full list Gitte recommends:
- Test design techniques. Know enough of them to apply in daily work and to judge AI-generated tests against what you expect to see.
- Exploratory testing. Many claim to do it and actually do ad hoc testing. Exploratory testing is still structured and uses critical thinking and test design techniques. It is simply not documented in scripted test cases.
- Test design for requirements. Use techniques to move from a process drawing to tests, so coverage is sufficient, neither too little nor too much.
- Risk-based testing. Many say they do it and few do. A product or quality risk analysis is only the start. The harder step is turning that analysis into the most effective set of tests, since teams often test too much or test the wrong things too much.
- Prompting. Use ChatGPT, Copilot, and similar tools as support, not as a replacement. Understand where they are strong and where they are not, and never copy-paste output uncritically.
You may not need another course. Reread the material you already have, find videos or e-learning, then sit with a colleague over real documentation and ask which technique fits. Trying it is the fastest way to learn. Learning that is never applied in practice is wasted.
