Agile quality is about embedding the right practices at every stage of software development, from idea refinement to release, so that quality is built in rather than checked at the end. A “practice” here means a small, concrete unit of skill, knowledge, and mindset. Breaking quality work into these small practices makes improvement tangible, helps teams divide responsibilities by actual skill, and gives organizations a concrete way to connect quality goals to business outcomes like cost reduction or faster delivery.
Key Takeaways
- Breaking quality practices into the smallest possible skill containers makes improvement tangible enough for teams to act on, instead of staying paralyzed by the size of the whole.
- A single tester working against five developers will always fall behind on execution, so moving that tester to test strategy and delegating execution to developers is a structural fix, not a compromise.
- Agile frameworks like Scrum are vehicles for delivering value, not the destination. When the framework becomes the goal, the PI event matters more than its purpose.
- Management is a root cause of quality gaps when acceptance criteria stay undefined, because a tester cannot scope work without knowing when the organization will sign off.
Agile testing is just proper testing
Agile testing does not differ from testing in any fundamental way. The principles stay the same. What changes is the pressure to apply them, because an agile setup does not let you sit and wait for a finished increment before you start.
Derk-Jan de Grood spent the first part of his career in testing before moving toward agile work. When he stepped back into an interim test manager role, he expected everything to have changed. On the managerial side, it had not. The old problems were still there, like memory drawers opening one after another: the same issues he had seen years before, in the same shape.
The technical side is a different story. Automation, a CI/CD pipeline, the tooling around testing, all of that has moved a lot. But none of that is “agile testing” either. It is simply how testing should be done now. Treat it as the default standard, not as something extra you bolt on when you adopt a framework.
The surprise comes when organizations start a large new project and you look at the plan. Manual testing on functional level, no pipeline in sight. The skills exist, but they are not put to work.
Why competence sits unused on the shelf
Knowing a test technique and being allowed to use it are two separate things. Many testers know the techniques and never apply them in real work. The gap is rarely about talent. It is about whether the knowledge gets activated.
Derk-Jan frames the fix around scaling skills, not scaling frameworks. The whole mass of “good software development” is too big to grasp as one block. People look at it, shrug, and go back to their ordinary job, because the heap of work feels too large to touch.
The same trap shows up in innovation budgets. Teams get ten or twenty percent time to “do something with innovation” and then stall, because nobody knows where to start. The management layer asks why nothing improves. The teams ask what they are supposed to improve. When teams stay silent, the business fills the gap with more ordinary work, and the improvement time quietly disappears.
Break improvement into practices
A practice is the smallest container of skill, knowledge, and mindset you need to do a certain task well. That is the unit that makes improvement workable.
For a tester, one such container might be “using test techniques”. CI/CD is another. Test automation is another. Each one is small enough to name, discuss, and pick up. Derk-Jan counts somewhere between a hundred and a hundred and fifty of them.
Once the work is split this way, a team can actually trade. You hold these skills, I hold those, shall we exchange knowledge? That opens the door to lunch sessions, brown paper sessions, reading, or mobbing. The improvement stops being an abstract mandate and becomes a concrete swap of capabilities.
The same move works upward. Instead of telling a team to “do innovation”, you let them cherry-pick: shall we do CI/CD, shall we do test automation, shall we sharpen this one tool. Tangible beats vague every time.
Shared responsibility for quality has an ownership problem
When everyone is responsible for quality but no one owns a piece of it, quality slips. A developer wants to code. Asking that same person to also own UI design, test data, and automation as one undivided lump produces shrugs, not results.
Cutting the work into practices fixes the ownership gap. You can ask a sharper question: who has the skill for this, and who wants to get better at it? That question has an answer. “Who owns quality?” usually does not.
The strict multi-discipline team, where everyone is a developer and separate testers are not allowed, has lost its appeal. The better aim is a self-sufficient team that holds all the needed skills and knowledge, while still letting people specialize. Specialists can also meet across teams in a guild or chapter and run the same skill-exchange game there.
How a tester moves from running to strategy
A tester drowning in retesting should move one layer up, toward test strategy, instead of trying to out-test the developers. Five developers will always produce work faster than one tester can check it.
Derk-Jan describes a small team where a single tester worked his guts out against the output of five programmers. The team sat down and split the work: which tests should the tester run, which tests can the developers take on. They put it in a simple table. That freed the tester to think strategically.
This shift gives a tester two conversations. One with the organization: are these the tests you actually want me to do? One with the team: here is everything that needs testing, I cannot cover it alone, help me on this part or give me another tester. Quality becomes a team activity again, with the responsibility shared and each person bringing a specialism.
The lesson generalizes. If you are stuck repeating, retesting, and getting frustrated by the same loop, the answer is rarely to test harder. Step up a level and find out who else can help.
Agility outlives the agile hype
Agile as a label may be past its peak, but agility is not. The frameworks were once cool for their own sake. A PI event was bragged about for its size rather than its purpose: how many people, how big, how impressive, never mind why.
Derk-Jan now describes himself less as an agile transformation expert and more as a value delivery expert. Agile was never the goal. It is a vehicle to reach a different goal: getting people more responsible, more self-assured, and pushing decisions lower in the organization.
That reframing starts with one question, and it is the hardest one: why do you want to do this at all? A manager often answers with “release faster” and “save costs”, or worse, does agile because it is a hype. Without a real why, the rest is theatre.
Connect business goals to practices
The practices are what link a vague business ambition to concrete team action. That is the bridge most transformations miss.
If the practices together make up good software development, you can ask of each one: does this reduce cost, does this speed delivery, does this cut returns or quality defects? Derk-Jan even ran the list through an AI to sort practices by effect, while noting that an expert still judges the result better.
This lets a team answer the business in its own terms. The business wants cost reduction. The team responds: then we will work on these specific practices, because they improve quality and serve that goal. You are still doing agile and still doing proper development, but you sell it through the outcome the business asked for, not through the framework name.
Frameworks are a Jenga tower
Scrum is a set of practices that worked for some teams, not a law. Every team and every organization is different, so you choose what works for you and try it out. You cannot know up front whether a daily stand-up or a Kanban board pays off for your context.
Derk-Jan uses a Jenga tower to teach this. Scrum hands you guidelines: a fifteen-minute stand-up, a team of up to nine, every day. Does the world collapse if the stand-up runs twenty minutes? No. Is it a disaster if you skip a day? Probably not. Each rule you relax is one block pulled from the tower.
As long as your tower doesn’t fall, it’s okay. But if you take out too much, you don’t know what you’re doing, it might fall. Derk-Jan de Grood
The tower holds when you remove blocks with judgment. It falls when you strip out so much that nothing supports the structure anymore. Tune the framework, do not worship it, and do not gut it blindly.
Where quality gets lost first
Management is the most common place quality breaks down, and not as an easy scapegoat. Leaders need to be quality-aware, because they decide which practices count and when something is considered done.
Acceptance is a concrete example. Derk-Jan worked with a client where it stayed unclear when work would actually be accepted, buried under discussion and contracts. If you do not know when you will accept, you cannot know what you need to test. Usability testing, user testing, the adapted business processes, in scope or out of scope, who tests all that, none of it could be answered. For an organization new to this, sorting it out takes real time. For one that releases frequently, it may be no problem at all.
The second blocker sits inside the team: the basics done badly. If CI/CD is not in place properly, start there. But some organizations are so swamped by ordinary work that they cannot invest in improvement at all, because every minute goes to testing and retesting. That is exactly the team that needs to move one layer up and find help, before the repetition grinds it down.
