Frankenstein’s Methodology
Scrum, Kanban, Waterfall, FFF and their hybrids. What you can combine on one project and what’s best kept apart.
Built it. Launched it. Changed our minds.
The delivery model is usually chosen before kickoff and written into the contract. Or the PM inherits a signed contract and builds the workflow around it. Some companies simply use the same methodology for every project.
Then the client wants regular demos, development gets buried in urgent tickets and acceptance requires documentation and signed-off contract milestones. Sometimes you have to change the process or stitch together a Frankenstein’s monster from several. I won’t get into every possible reason. Let’s look at what you can actually mix and match.
What you can mix
Scrum + Kanban
We work in Sprints, with planning and reviews. Add WIP limits and keep an eye on cycle time and blocked work. If testing is backed up, developers stop pulling in more tasks. Clear the queue first. The Sprints stay. So does the Sprint Goal. Kanban helps manage flow without throwing out the team’s agreements.
Waterfall + Scrum
The contract sets out the requirements, budget, deadlines and acceptance process. Internally, the team works in Sprints, runs demos and tests integrations before handing over a phase. I’ve seen this regularly in client delivery. Just don’t confuse a completed Sprint with an accepted project phase. Estimate the client’s new requests separately too. Don’t quietly drop them into the backlog for the team to absorb.
FFF + Kanban
Take a prioritised backlog, limit WIP and ship finished features. Kanban makes workload and bottlenecks visible. FFF lets you change what goes into the release. But the client has to agree that you can cut scope. Otherwise, absolutely everything ends up fixed except the PM’s nervous system.
What not to mix
FFF + fixed scope
The methodology says scope is flexible. The contract specifies features, deadlines and acceptance criteria. You can’t cut anything without the client’s approval. So the team follows FFF internally while still being held to a fixed scope. Instead of managing scope, the PM negotiates exceptions to the contract. And the client has no obligation to agree. I’ve written a separate post about this.
Scrum + constant ASAPs
The Sprint plan is agreed. Then an urgent feature lands, management adds a few more tasks and a developer gets pulled onto another project. By the end of the Sprint, half the planned work is unfinished. If urgent requests land every day, reserve capacity for them or change how the work is organised. Scrum allows the scope of work to be renegotiated. Constantly changing the Sprint Goal is another matter.
Waterfall + unestimated changes
The requirements are agreed, the scope is estimated and development starts. The client changes the business logic, adds screens and requests new integrations. The team accepts everything. Nobody revisits the deadline or the budget. Waterfall doesn’t ban changes. You just have to assess and agree on them. Otherwise, by release day you’re delivering more features on the original estimate.
How this can actually work
Say the contract follows Waterfall, development uses Scrum and testing runs through Kanban. The client sees a demo every two weeks. Final acceptance follows the contract. The important part is to distinguish completed tasks, working features and fulfilled commitments.
You can finish a Sprint without getting the phase accepted. You can demo a feature and then spend a month fixing its integration. Agree upfront on what counts as done, what acceptance requires and how requirements can change. While you’re at it, decide who gets to change priorities.
If you suddenly decide to switch from Scrum to Kanban halfway through a project, look at why. Stalled reviews, urgent tickets and the missing analyst won’t disappear when you change the label. WIP limits and clear backlog policies might be all you need here.
I’m a project manager. About working with russian clients and teams, sharing experience and things I’ve noticed.
The content published on this website is intended for informational and analytical purposes and reflects the author's professional experience, personal opinions, and subjective assessments. Any recommendations provided are not universal guidelines and may need to be adapted to specific circumstances, agreements, and workflows. Discussions of professional practices, products, and management decisions are intended to evaluate their effectiveness, not to damage anyone's honor, dignity, or reputation. Examples may be fictional, generalized, or anonymized and are not intended to disclose confidential information.