Moving from Waterfall to Agile Testing: Lessons Learned

Moving from Waterfall to Agile testing means changing when testing happens and who takes part. Instead of handing completed development to QA near the end, involve testers while requirements are being clarified and development is underway. Plan test design and execution as part of each increment where feasible, and make acceptance criteria, blockers, and release evidence visible to the whole team.

This is a change in workflow, not a guarantee of better quality or faster delivery. Agile practices can expose risks earlier, but results depend on the team, system, governance, and how well the work is carried out. Experience reports describe particular organizations; treat their timelines and results as examples, not forecasts.

What changes when testing moves into Agile delivery

Area	Waterfall-style handoff	Agile testing approach
Timing	QA may receive a mostly complete release late in the project.	Testers contribute during clarification, development, and each increment where possible.
Ownership	Testing can appear to be a separate QA phase or department responsibility.	The team shares responsibility for quality; specialists still contribute testing expertise.
Planning	Test planning and environment needs may be handled after requirements or code are complete.	Examples, risks, test needs, and dependencies are discussed early and refined as the team learns.
Feedback	Defects and requirement gaps may surface near a release gate.	Feedback can arrive during the increment, though external approvals and environments can still create queues.
Evidence	Documents and sign-offs may be built around phase completion.	Required evidence remains part of the work; teams can make it visible and generate suitable records as they go.

The Agile Manifesto values working software and customer collaboration, while recognizing that processes and documentation still have value. This does not mean deleting governance or treating testing as optional. Read the Agile Manifesto.

Lessons from teams that made the transition

Changing the board does not change the handoff by itself

A Marchex experience report describes teams that adopted iterations and boards but continued coding first and testing afterward. They still faced bottlenecks, inconsistent releases, and QA overtime. Unifying development and QA work on boards and including both in retrospectives were described as early steps toward partnership. The lesson is to make testing work part of the shared flow, not merely rename the old phases. Read the Marchex report.

Early QA involvement can reveal risks sooner

A mixed-methods Agile/Waterfall report says that early review helped its team start test cases sooner and identify risks before late-stage QA. Agree on acceptance criteria, examples, test data, environments, and external dependencies while the work is being clarified. Keep the examples open to refinement as understanding changes. Read the mixed-methods QA report.

Automation takes investment and does not replace expert testing

A criminal-justice program report describes rising regression risk in a mature system and a commitment to automation. During the transition, the team still relied heavily on expert manual testers while coverage was being built. Prioritize stable, valuable checks that run repeatedly, but budget for test data, environment stability, maintenance, and diagnosis. Preserve exploratory testing and domain expertise. The report also notes that the program might have adopted automation regardless of its lifecycle choice. Read the criminal-justice transition report.

Governance and documentation still count

The mixed-methods report warns that its initial Agile approach did not account for required test evidence and release documentation. In the criminal-justice case, relatively few documents could simply be removed; manual documentation was reduced gradually and generated reports were used where suitable. Preserve records required by contracts, policy, regulators, customers, or release approvers. Improve how they are produced rather than assuming an Agile transition makes them unnecessary.

There is no universal transition schedule

Mayden’s case study describes moving all product-development teams to Scrum in six months. A different report describes retaining formal stages and gates while inserting a Scrum execution phase and using more just-in-time planning. These are examples of different contexts, not recommended deadlines or universal models. Read the Mayden case study and the phase-based Agile report.

A practical transition sequence

Agree on the problem to solve. Identify where work waits, what quality or delivery risk matters, who owns product decisions, and who must approve releases. Make the reason for the change concrete enough to revisit.
Map the current path. Follow one change from request through development, testing, evidence, approval, and release. Record queues, handoffs, unavailable environments, and decisions that depend on other teams.
Bring QA into clarification. Invite testers to discuss requirements and examples before implementation is considered complete. Define observable acceptance conditions, risks, test data, and environment needs. Refine examples when learning changes the understanding.
Use a shared view of work. Track stories through development, testing, blocked states, and evidence on a board visible to the team. Include testing tasks and dependencies. Separate boards and separate retrospectives can preserve the handoff even when teams use iteration terminology.
Plan quality work inside the increment. Include test design, execution, defect investigation, and any required evidence in the plan and completion criteria. Coordinate early with external teams that own environments, integrations, security review, or release approval.
Automate selectively and incrementally. Start with repeatable checks that protect important behavior and are costly or risky to repeat manually. Stabilize environments and data, and assign ownership for failures and maintenance. Keep manual exploratory and domain-specific testing in the plan.
Keep gates and evidence visible. If procurement, regulation, contracts, or organizational policy require formal gates, list them as explicit dependencies and define what evidence each gate needs. Where possible, work iteratively between gates and generate records from the work itself.
Use retrospectives to change the system. Review where testing waits, where defects or approvals accumulate, and which constraint the team can change in the next iteration. Choose a small action, an owner, and a way to see whether the queue changed.

A public-sector case report describes joint customer and contractor commitment and whole-team training as deliberate startup choices. This is a reminder to include the people who control product decisions and release constraints, not just the delivery team. See the case report.

Choose a transition shape that fits the constraints

Transition option	Useful when	Questions to resolve
Broad reset	Leaders can change governance and teams can coordinate across the organization.	Can product decisions, release approvals, and team responsibilities change together? Is there capacity for training and operational adjustment?
Gradual team transition	Some teams can change their delivery habits while neighboring groups retain existing processes.	How will interfaces, shared environments, evidence, and handoffs work across teams? Who resolves dependency delays?
Hybrid or phase-based execution	Formal gates or contracts must remain while teams can change execution within a phase.	What must be true at each gate? Can planning become more just in time between gates? How will iterative work produce the required records?

Compare the options using six constraints: authority to change governance and approvals; regulatory, contractual, and documentation demands; legacy integration and environment complexity; current automation and maintenance capacity; availability of product owners and cross-functional team members; and the amount of coordination needed with teams that remain on Waterfall. The public-sector rescue, criminal-justice transition, and phase-based reports describe substantially different settings, so their approaches should be adapted rather than copied. Public-sector rescue report.

Measures that show where the transition is stuck

Use measures to locate queues and guide discussion, not to claim that a new process caused an outcome. Start with a few measures the team can act on:

Time waiting for QA: how long work sits ready for testing before someone can start.
Work age by state: whether items accumulate in development, testing, environment setup, or approval.
Acceptance clarity: how often testing uncovers an unanswered requirement or missing example.
Escaped defects and rework: where important problems are found and what conditions allowed them through.
Automation health: useful coverage, flaky failures, maintenance effort, and time to diagnose a failed run.
Evidence and approval lead time: whether required records are ready when the release decision is due.

Do not reward teams for maximizing test counts, automation percentages, or story throughput in isolation. A metric can be gamed or conceal growing risk. Pair numbers with examples from recent work and use retrospectives to change a bottleneck.

Common problems and fixes

Problem	Likely cause	Practical fix
QA receives a batch of finished stories at the end of an iteration.	The old coding-then-testing sequence survived the process change.	Share the board, involve QA in refinement, limit work in progress, and plan smaller slices that can be tested earlier.
Stories repeatedly fail acceptance late.	Acceptance conditions or examples were unclear, or testers joined too late.	Discuss examples and risks before implementation; ask product, development, and QA to agree on observable outcomes.
Automated tests fail unpredictably.	Unstable environments, shared test data, timing assumptions, or unclear ownership.	Stabilize setup, isolate data where possible, capture failure details, and make maintenance and triage explicit work.
Automation effort grows but regression confidence does not.	Tests may cover low-value paths, duplicate checks, or be too costly to maintain.	Prioritize critical repeated risks, review whether each check changes a decision, and retain expert exploratory testing.
Release approval blocks an otherwise finished increment.	External evidence or approver needs were discovered late.	Map gate requirements early, name the approver and lead time, and prepare evidence alongside the work.
Teams argue about Agile versus Waterfall responsibilities.	Decision rights and cross-team interfaces are unclear.	Agree who owns product decisions, testing, environments, evidence, and release sign-off. Make dependencies visible and review them together.
Documentation grows despite iterative delivery.	Required records were not distinguished from redundant manual status documents.	Confirm what is mandatory, remove or simplify only what policy permits, and generate records where reliable and suitable.
Retrospectives produce discussion but no change.	Actions are broad, ownerless, or outside the team’s authority.	Choose one constraint within reach, assign an owner, and check its effect in the next retrospective; escalate the rest with a named decision-maker.

Performance, reliability, and cost considerations

Capacity: Testing earlier can reveal issues sooner, but it also requires tester participation during clarification and development. Plan that capacity instead of treating it as extra work that fits automatically.
Environment reliability: Shared or unstable systems can make feedback slow and test results hard to trust. Account for environment ownership, representative data, resets, and dependencies in the plan.
Automation cost: Building and maintaining checks takes time. A useful suite reduces repeated effort only when the checks are relevant, stable enough, and maintained as the product changes.
Release risk: Smaller increments can make changes easier to inspect, but they do not remove integration, approval, or operational risks. Keep required end-to-end and release checks appropriate to the system.
Documentation effort: The criminal-justice case team reported spending more than 15% of total team effort maintaining documentation over the previous eighteen months. This is a case-specific finding, not a general Agile estimate. Its report also says nearly 50% of business-user-story effort went to emergent stories outside the initially identified scope; that figure is likewise specific to that project. Source and context.

Or skip the browser setup

For website checks in a testing workflow, a screenshot can make visual changes and failures easier to inspect. You can run a browser yourself, or use ScreenshotNeo, a website screenshot API and MCP server from Yorker Media. Its API returns a PNG, JPEG, WebP, or PDF from one GET request. See the ScreenshotNeo API docs.

curl -G "https://api.screenshotneo.com/v1/shot" \
  -d access_key=YOUR_API_KEY \
  --data-urlencode url=https://stripe.com \
  -o shot.webp

import requests

r = requests.get(
    "https://api.screenshotneo.com/v1/shot",
    params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"},
    timeout=90,
)
open("shot.webp", "wb").write(r.content)

const q = new URLSearchParams({
  access_key: 'YOUR_API_KEY',
  url: 'https://stripe.com'
});
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);

Cookie banners are accepted before capture, and more than 60 known consent platforms, newsletter popups, and chat widgets are removed; each step can be turned off.
Bot checks, blank pages, timeouts, failed loads, and cache hits cost nothing. Response headers say which page verdict applied and whether the request was billed.
An MCP server gives Claude, Cursor, and other MCP clients the tools take_screenshot, get_page_info, and capture_pdf.
The Free plan includes 1,000 screenshots per month with no card. Paid plans start at $5 for 3,000; every feature is on every plan.

FAQ

Does Agile mean there is no QA phase?

It means testing is planned throughout delivery where feasible, not that specialist QA or release checks disappear. Some systems still need formal validation or approval stages.

Should a team automate everything before changing its process?

No. Automation can be developed over time. Start with repeatable, valuable checks and keep manual testing expertise in the workflow.

Can an Agile team work with Waterfall teams?

Yes, but the shared interfaces need attention: dependencies, environment access, acceptance conditions, required evidence, and approval lead times. A hybrid arrangement is one possible fit when formal gates remain.

How long should the transition take?

There is no evidence-based universal deadline in these case reports. Mayden reported a six-month organizational transition to Scrum; other cases used different approaches and constraints. Set a local plan based on authority, dependencies, and capacity.

Does adopting Agile automatically improve quality or delivery speed?

No. The reports describe practices and case-specific outcomes. Measure your own queues, defects, and release constraints and adjust based on what the team learns.