We wrote this because we kept watching good teams do good work that didn’t matter.

The frustration that started it

Somewhere between 30% and 50% of product effort goes into work that never moves a customer or business outcome. The corollary is just as stark: 80% of paying users use only 20% of the features. That waste is not a people problem. It is the predictable output of organisations that throw work over the walls between sales, product, engineering, and customer success.

We call that work a BananaBananaA task without context — no "why", no link to a real outcome. The thing the method exists to eliminate. — a task with no “why”, no visible link to a real outcome, and no influence over it. Backlogs fill up with Bananas because context gets lost on the way over the wall. The slogan we kept coming back to: stop throwing Bananas, start collaborating.

What made it worse was reaching for “modern” ways of working that were mostly invented decades ago — Kanban (1956), Six Sigma (1986), Scrum (1989), XP (1996), RUP (1998), SAFe (2007). Useful in their day, but none designed for hybrid teams doing high-uncertaintyUncertaintyWhat the team does not yet know — sized and tracked deliberately rather than hidden inside estimates. product work.

A true agile method

Two names usually thrown onto that pile don’t belong there.

Shape Up (Basecamp, 2019) is genuinely modern, and we’ll say it plainly: we like it. It rejects the same estimation theatre we do and takes cross-functional collaboration seriously. The difference is scope. Shape Up shapes work for a single team against a six-week appetite; Scaleflow is more elaborate in its rituals and weekly rhythm, and is built to scale up — many initiatives and teams, a whole organisation kept in context at once. If Shape Up already works for you, a lot of Scaleflow will feel like home.

The Agile Manifesto (2001) isn’t a method at all. It’s four values and twelve principles, and in its true form it is close to perfect. The tragedy is that the frameworks which flew its flag drifted into exactly the ceremony and proxies it warned against — until “agile” became a synonym for process for its own sake. Scaleflow is an attempt to be agile in the Manifesto’s original sense, honouring the left-hand side of each line rather than the word:

• Individuals and interactions over processes and tools — our process exists to force interaction (the cross-functional Daily Check-inDaily Check-inA 15-minute daily ritual where the team surfaces reality and unknowns rather than reporting status., the Product BoardProduct BoardTwo or more stakeholders who see the team's weekly demo and coach it — the human in the loop, with no single lead.), never to stand in for it.
• Working software over comprehensive documentation — progress is a working weekly demo, never story points or a status report. Our documents are lightweight, living context that replaces meetings, not specs that pile up beside the work.
• Customer collaboration over contract negotiation — we work backwards from the customer and keep a customer voice on the Product Board.
• Responding to change over following a plan — the ApproachThe ApproachThe multi-week narrative roadmap — titled weekly outcomes ("The one where…"), each with a demo, planned backwards from success. is re-cut every week; the plan is a way to communicate, not a contract to defend.

The Manifesto’s own principles read like a description of the weekly rhythm: deliver working software frequently, business and team collaborating daily, working software as the primary measure of progress, a sustainable pace, and teams that reflect and adjust at regular intervals. We didn’t invent any of that. We just built a rhythm that tries to actually live up to it — which, twenty-odd years on, turns out to be the radical part.

Why a method, not a tool

The seed ideas go back to a “Banana Inception” deck in 2016 and were codified during a lab project at trivago in 2019. Under the working name WhatNow the approach matured, and became Scaleflow in 2021.

Through all of it, one decision held: this is a method, not a tool. Tools change; the thinking shouldn’t have to. Scaleflow is software-independent on purpose — the magic is in the practice, not the platform. Teams have run it in Notion, Google Docs, Office 365, and Confluence. What matters is the rhythm, the artifacts, and the opinions behind them, not where you keep them.

The thinking starts from a few first principles. Building software is not a linear path. Uncertainty is a certainty. Meaningful solutions require close collaboration. Focus is king. A team that gets 10% better every day gets 10× better over time. And — the one most teams won’t believe until they’ve tried it — process can reduce project-management overhead instead of adding to it. Everything else in this reference is downstream of those six beliefs.

How to argue with this

Treat every page as a claim you can push on. The method is opinionated, and it should be — but opinions only stay honest if they can be challenged.