Ways of working · first published on Medium, 31 December 2025
Rethinking the SDLC, Building Software with Continuous Participation
Introduction
Most organizations still rely on the classic Software Development Lifecycle: requirements, design, development, testing, deployment.
It is simple, familiar, and structured, but it creates an unintended behavioral pattern. Each group joins only when their phase arrives. Product works alone first, then development takes over, then testing joins after the build, and everyone participates late by habit rather than intention. This delays feedback, hides assumptions until it is costly to correct, and creates avoidable rework.
The goal is not to replace the SDLC. The goal is to fix the behavior it unintentionally reinforces, by making participation continuous rather than sequential.
The Core Idea, Open Work Before the Handoff
Teams should invite others to participate earlier than the SDLC suggests.
Work does not need to be finished before being seen. Drafts, stubs, sketches, outlines, and partial logic are enough for others to review, challenge, and refine.
Key principles
Phases stay the same, but participation is no longer restricted to phase boundaries. Ownership stays intact, but visibility begins earlier. Feedback becomes continuous, not tied to handoffs. Work is shared in incomplete form so issues surface before they harden. The SDLC remains, but the behavior becomes open and collaborative instead of isolated and sequential.
Why This Matters
Late feedback is expensive, demoralizing, and slow. Early feedback is cheap, fast, and informative.
Examples:
Requirements: Developers and testers see early drafts, catch missing cases, identify high risk areas, and help refine language before development even starts.
Design: QA reviews flows and usability before coding, flagging issues that would otherwise appear only after a feature is built.
Development: Developers expose stubs, mocks, or partial implementations so product and QA can validate behavior before the full logic exists.
Testing: Test decisions and risks become visible early so development can adjust structure or add hooks before testability becomes a problem.
This prevents the common cycle of build, hand over, discover gaps, rebuild.
Practical Examples
Early Requirement Review
Product writes a draft. Developers and testers review it immediately. They challenge assumptions, find missing flows, and clarify ambiguous behavior. Product adjusts the requirement before refinement. The team enters development with clarity, not uncertainty.
Early Design Visibility
Designers share rough sketches or flow diagrams with QA before they create full design specs. QA highlights usability constraints or edge cases that would otherwise appear later. Design adjusts early, saving days of rework.
Development Sharing Incomplete Work
A developer creates a skeleton API that returns a mock response. QA tests early flows. Product interacts with early behavior and confirms expectations. Once validated, development completes the real logic with high confidence and fewer surprises.
Implementation Framework
1. Identify habitual late points. Find where your teams repeatedly say we should have caught this earlier. Typical areas include requirement clarity, design gaps, testability issues, and integration assumptions.
2. Add simple routines for early participation. These are not ceremonies, they are habits. Examples include sharing requirement drafts, showing design sketches, exposing early stubs, or posting implementation plans.
3. Use incomplete work intentionally. The purpose of early sharing is not polish, it is visibility. Work can be rough, partial, or indicative. What matters is that others can respond.
4. Keep roles and ownership unchanged. Developers still develop. Testers still test. Product still defines direction. The difference is timing, not authority.
Concerns Teams Usually Raise
"Will this create more meetings" — No. Most participation happens through short async comments on drafts, prototypes, or stubs. This saves meetings by eliminating long conversations caused by late discovery.
"Will roles become blurred" — No. Everyone reviews early, but nobody takes ownership from another group. Developers still write code, testers still own quality insights, product still drives intent.
"What if people disagree more often" — They already disagree, but they do it too late. Early disagreement is healthy because it prevents flawed work from progressing.
"Will this slow us down" — No. It accelerates delivery by catching issues early instead of remediating them after the fact.
What This Model Is Not
It is not a new methodology. It is not a replacement for agile, scrum, or the SDLC. It does not add process, remove phases, or shift ownership.
It simply corrects the behavioral problem the SDLC unintentionally creates, the belief that each group should participate only during its phase.
Conclusion
The SDLC provides structure, but structure should not prevent early visibility.
By inviting all groups to participate before the handoff, teams expose assumptions early, find issues when they are still cheap to fix, and avoid the cycle of late discovery that slows delivery.
This approach keeps the SDLC intact while making it collaborative, transparent, and significantly more effective.
Want a guardrailed assistant like this on your site, or AI automation with the same rigour?