When Cloud Sounds Like Cheaper Hosting
Your company has been selling vertical software for 15 years. You have 50 employees, steady revenue, happy customers ...
Quality Was the Point of Agile Coaching
8 min read
Before It Became Ceremony Management
15.05.2026, By Stephan Schwab
Quality is one of the most abused words in software. Everyone demands it. Few define it. Even fewer fund the conditions required to produce it. That confusion also swallowed Agile coaching. In its earlier form, especially around the original American Agile scene, coaching meant helping teams build better software through technical excellence, feedback, and disciplined collaboration. Later, much of the market replaced that with process consulting, ceremony moderation, and a strange kind of social streetwork for software teams. The word stayed. The center of gravity moved.
What Quality Actually Is
"Quality is not polish. It is fitness for use under real conditions, with changeability still intact."
A pretty interface is not quality. A successful demo is not quality. Passing QA on Thursday and collapsing in production on Monday is not quality.
Quality in software means the system does what it needs to do, keeps doing it when reality gets ugly, and can still be changed without turning every improvement into surgery.
That includes at least five things:
- The software behaves correctly for users and for the business.
- It fails in understandable ways instead of corrupting data silently.
- It can be changed without setting off three unrelated explosions.
- Teams can tell whether it is healthy because feedback is fast and real.
- The people building it can sustain the work without drowning in fear and rework.
That last point gets ignored because it sounds soft. It isn’t. A team living in constant anxiety does not produce quality. It produces camouflage. People hide uncertainty, batch risky work, avoid touching fragile areas, and redefine “done” until leadership can sleep.
Quality is not just a property of the product. It is also a property of the way the product gets built.
What Agile Coaching Originally Meant
"The original promise was not better stand-ups. It was better software through better feedback."
Back when Agile coaching still had a pulse, especially in the early American scene around Extreme Programming, Scrum in its less sterilized form, and the broader Agile movement before it was industrialized, the work was much more concrete.
A coach was supposed to help teams learn how to build software in smaller steps, with faster feedback, better collaboration, and stronger technical discipline. That meant pairing. Test-first thinking. Continuous integration. Refactoring. Real customer feedback. Work sliced small enough to finish. Conversations close enough to the code that misunderstanding had somewhere to go other than production.
The center of the work was quality.
Not quality as a gate at the end. Quality as something built in through feedback, design, and technical practice from the start.
That is why the old Agile language included technical excellence at all. Not as decorative philosophy. As the mechanical basis for adaptability. If the code is brittle, the tests are absent, integration is terrifying, and deployment is ritualized, you are not agile. You are merely moving panic around the calendar.
A useful coach in that older sense did not just run workshops. They changed how work happened. They helped teams learn to see defects earlier, reduce batch size, make risk visible, and build confidence through executable evidence.
How It Drifted
"Once the market realized it could sell Agile without touching code, the decline was predictable."
The serious technical version was harder to sell.
It required skilled practitioners. It required credibility with developers. It required getting close to ugly code, broken pipelines, weak test strategy, and management habits that rewarded the wrong things. It required conflict.
So the market did what markets do. It found the cheaper version.
Suddenly Agile coaching could be sold without strong technical grounding. You no longer had to know how to help a team build quality into the code. You just had to know how to facilitate, moderate, reframe, empathize, map sticky notes, and introduce safe words for organizational discomfort.
In the United States that often turned into method consulting dressed as transformation. In Europe it often took on an even stranger social role: a kind of streetworking for software teams. Someone to calm people down, absorb frustration, keep communication flowing, translate pain into harmless language, and make the system feel cared for without forcing it to change.
That work is not always useless. Human conflict is real. Team distress is real. But it is not a substitute for improving software delivery. It often becomes a way of helping people survive a bad system instead of confronting why the system keeps producing low-quality software in the first place.
Why the Market Preferred the Worse Version
"The market rarely buys truth first. It buys relief first."
This drift was not just professional corruption. It was also psychology.
Real quality work threatens people.
It threatens executives because it reveals that deadlines, funding choices, and reporting structures may be degrading the product. It threatens managers because it exposes how little of delivery can be fixed with scheduling theater. It threatens developers because actual technical discipline removes the romance of heroic improvisation. It threatens consultants because measurable improvement is harder to fake than facilitation energy.
Process theater, by contrast, is emotionally convenient.
It gives leaders a visible intervention. It gives managers a vocabulary. It gives teams a ritual. It gives consultants a productized offer. It gives everyone a story in which they are trying very hard.
That story has enormous psychological value. It reduces anxiety without requiring a direct encounter with the real causes of bad quality.
Needs, Status, and the Strange Economics of Quality
"People say they want high quality. Very often they want reassurance at a discount."
Here is the ugly part.
Many buyers do not actually want the discipline required for quality. They want the feeling of having acted responsibly.
That is a different need.
Some want status: “We brought in Agile coaches. We are modern now.” Some want absolution: “If delivery still fails, at least we followed best practice.” Some want social peace: “Please reduce conflict without changing incentives.” Some want cheap hope: “Can we get the benefits of technical excellence without the cost, time, or discomfort?”
And the market responds beautifully to those needs.
It offers improvement theater at a price point and tone the buyer can tolerate. Not too confrontational. Not too technical. Not too demanding. Just enough language about mindset, collaboration, and maturity to sound serious.
There will always be someone willing to buy cheap, best-quality promises as long as the story is comforting enough. There will always be someone willing to sell them.
This is not unique to Agile. It is how most low-accountability markets behave. If the buyer cannot easily inspect the underlying quality, packaging wins for a long time.
Software is especially vulnerable because quality is mostly invisible until it breaks in public.
The Psychological Split Inside Teams
"When quality is expensive and invisible, organizations start rewarding the appearance of control instead of the presence of integrity."
This is where the human cost shows up.
Developers who care about quality usually experience the system as a stream of preventable compromises. They can see the missing tests, the dangerous coupling, the batch size, the silent risks, the fake estimates, the deployment fear. To them, quality is concrete.
Leadership often experiences the same situation differently. They see deadlines, budgets, board pressure, staffing constraints, and the constant need to keep the organization coherent. To them, quality can become an abstract aspiration that must compete with everything else.
The coach was originally supposed to help bridge that gap through evidence, practice, and shared feedback loops. In the degraded version, the coach often becomes a buffer that helps both sides tolerate the gap without actually closing it.
That is a profound downgrade.
It turns coaching from capability-building into emotional shock absorption.
What a Quality-Focused Coach Would Still Do
"A real coach makes quality more visible, more teachable, and harder to fake."
If the role is worth anything, it still has to do at least these things:
- Help teams make work smaller so feedback arrives before damage compounds.
- Strengthen the technical practices that make change safe.
- Make quality visible through tests, delivery signals, defects, and production behavior.
- Coach leaders to read evidence instead of ritual.
- Reduce dependency on the coach over time instead of creating a permanent translation caste.
That is why leaders must own the journey, and why methodology becomes dangerous when it replaces reality with loyalty. The job was never to install more process. The job was to improve the system’s ability to produce high-quality software.
The Market Will Keep Buying Theater
"As long as quality stays hard to inspect, theater will remain cheaper to buy than competence."
That part is not going away.
There will always be buyers who prefer a neat method over an uncomfortable diagnosis. There will always be consultants who can make low-quality systems sound temporarily sophisticated. There will always be organizations that call something quality because someone approved it, documented it, or ran a ceremony around it.
Fine. Let them.
For those who actually want quality, the definition has to stay sharp.
Quality is software that works under real conditions, can keep changing, and is built through disciplined feedback rather than ceremonial reassurance.
That was the serious core of Agile coaching before the market diluted it.
It is still the only part worth keeping.
Contact
Let's talk about your real situation. Want to accelerate delivery, remove technical blockers, or validate whether an idea deserves more investment? I listen to your context and give 1-2 practical recommendations. No pitch, no obligation. Confidential and direct.
Need help? Practical advice, no pitch.
Let's Work Together🎭 This Week's Episodes
Telenovelas show what we can't say in client meetings. The drama is heightened, but the patterns are real.
The First Pairing Session
Stefan proposes pairing and, worse, mob programming. The team expects chaos. Daniel fears losing the last lever he still pulls: approval. Mariana e...
Technical Consultancy
Embedded Delivery Partner
Embedded into your team as an active contributor, reducing delivery friction and helping important work move cleanly.
Technical Advisor
Peer-style technical assessments before far-reaching decisions; reduce architectural and product risk early.
Product & Delivery
Ship working software to real users earlier. Measure impact and adapt based on evidence rather than assumption.
Custom Software Development
High quality, maintainable software. Short-term augmentation that leaves lasting capability in your own team.
Recent Articles
- Quality Was the Point of Agile Coaching (15.05.2026)
- What Real AI for Normal People Looks Like (11.05.2026)
- A Chatbot Is Not an AI Strategy (04.05.2026)
- Designing Systems in Dialogue With AI (01.05.2026)
- What AI Changed About Software IP (24.04.2026)