Waterfall and Scrum are often discussed as opposing choices. My preferred starting point is to agree the direction and constraints, then deliver and learn in short cycles. Structured planning is not exclusive to Waterfall: Scrum includes planning, and its plans adapt as evidence changes. The useful choice is how to coordinate commitments while keeping room to learn.
Plan what needs shared agreement
Establish the problem, intended outcome, major dependencies, budget boundaries, and important milestones. Sequential planning can help where approvals or external commitments need coordination. Make assumptions visible rather than treating every early estimate as a promise.
- Improve resource, timeline, and budget planning by making the work, available capacity, dependencies, and constraints visible.
- Give the team a clear goal and shared targets to work towards, so everyone understands what success should look like.
Keep the execution open to learning
A broad plan does not need to freeze every feature. Translate the direction into a prioritized backlog and a clear Product Goal. Use Sprint Goals to focus the team on meaningful progress, and inspect usable increments with stakeholders. Feedback should be able to change what happens next.
- The environment and people’s needs change, so the plan needs to adapt as the team learns.
- Prioritise time and effort on work that delivers real value. Reconsider planned items when they no longer support the intended outcome.
A hypothetical system replacement: fix constraints, adapt the solution
Suppose an old system must be retired by a fixed date and the replacement must connect to an existing finance interface. The retirement date, integration contract, data checks, and cutover approvals need early agreement. The team can still learn which screens, exception paths, and rollout sequence work best.
At a review, staff struggle with the new approval flow and an integration test exposes a mapping error. The Product Owner and team reorder the backlog to address these risks, defer a lower-value dashboard, and revise the rollout forecast. If the minimum safe cutover is now at risk, take that evidence to the decision owner early and agree a fallback.
Keep the fixed constraints visible, but change the plan around what the review reveals. Reviews should affect scope, sequencing, and forecasts; accepting feedback while leaving every commitment untouched defeats their purpose.
Avoid a hybrid that blocks adaptation
Putting Scrum events around a fixed feature list does not create room to learn. The team needs authority to inspect and adapt its work. A genuine external deadline can remain fixed while solution scope and sequence change; quality and a usable result still matter.
Teamwork and communication are essential to making this approach work. Keep goals, progress, risks, and changes visible, and discuss them openly with the team and stakeholders. Shared understanding helps people coordinate decisions and adapt together.
For me, a useful hybrid creates enough structure for stakeholders to coordinate and enough flexibility for the team to respond. It is a delivery choice to evaluate, rather than a universal best method.
Kanban may suit work that arrives continuously, such as support requests and small service changes. Make the workflow and priorities visible, control work in progress, and watch how long items take. Choose around the work pattern and coordination needs, rather than project size alone; flow practices can also complement Scrum.