Lean and agile methodology exists to answer questions you don't know the answer to. You ship early and ship often, learning from real users, then adjust based on what you've learned. It's a brilliant tool for avoiding work that isn't valuable — for finding out what you didn't know you didn't know.
A full-app redesign has no questions. There aren't many reasons to run one: a rebrand, or a new head of design who doesn't like what's already there. I'll just call it a rebrand from here — the other one behaves exactly the same way once it lands on a sprint board. Scope is fixed on day one, front to back, and it doesn't matter what users think of it. The decision's already been made somewhere above the team doing the work; the only open question is how you get there, and that's an execution problem, not a product one.
That's different from a product or UX redesign — rethinking a flow, a page, a journey — where the answer genuinely is unknown and you have to iterate to find it. Agile is built for that kind. It's not built for a rebrand, where there's nothing left to learn by shipping a piece of it and watching what happens. All that does is confuse your users on a schedule, at the rate of your sprint cycle.
The ways I've watched it fail
I've been a developer for over a decade. I've worked on five rebrands at three different companies — plus a handful of marketing-only rebrands that never needed a developer's input. If I had a nickel for every time I heard my company announce a rebrand... I wouldn't be rich, but it happens more often than you'd think.
Most recently, my team spent over a year trying to "fit in" a rebrand around everything else — a page here, a flow there, whenever a sprint had room. Piecemeal rollout meant the product was visibly two apps stitched together, for months. Half the screens carried the old brand, half the new one, and every release made the seam more visible, not less. Users noticed. It eroded their trust. A year of distraction bought us a Frankenstein app that never stopped looking unfinished.
It was a team of three, running two-week sprints, with roughly 10% of our time reserved for the rebrand — for a year. Nearly all of it was wasted. On at least three separate occasions we burned more time than that entire 10% budget just arguing about how to handle a single piece of work, because the ground had shifted since we'd last touched it — a component had been rebuilt elsewhere, a pattern had changed, and nobody could agree what "on-brand" meant that week.
Before that, I saw the same failure play out more slowly. Another company I worked at ran something they called a "kaizen" board — an unprioritised list of tasks, bugs, and refactors that developers pulled from sprint work would rotate onto for a week. The rebrand tasks were dumped there. As you can imagine, that just meant they never got fully migrated. For two years. There were still a dozen rebrand tasks left on that board when I left.
Prior to that, I watched it fail a different way. A four-person team pulled one developer off sprint work to build a full rebrand behind a feature flag, while the other three kept shipping features — mostly new minigames — at the usual pace. Releasing the rebrand piecemeal was off the table, but so was slowing down new features, so the compromise was: build new features in the old style, and the solo developer would convert them behind the flag later. Keeping the feature pace was worth more to the business than finishing the rebrand.
Everyone hated it. The rest of the team felt bad every time they shipped something new, because it was one more thing sitting on the solo developer's plate. The solo developer felt worse — months of work with nothing to show for it, because none of it could ship until all of it did. Eventually another project needed that developer back on feature work, and they never returned to the rebrand. By the time I left the company, it was still sitting behind that flag, unreleased, at least nine months later.
The two failure modes
Those three have the same shape underneath. Treat a rebrand like a backlog of feature work and it loses every time it has to compete for a sprint — it's the one thing nobody's ever forced to ship this week, so it doesn't. Do that for long enough and you guarantee one of two dead ends: the Frankenstein app, old brand and new brand running side by side indefinitely, or the flag that never flips, real work that's never anyone's full-time job, stalled just short of done — sometimes for years, sometimes for good, if someone above you decides it's time for another rebrand before this one ships.
Either way it never gets done.
The way I watched it succeed
The most recent "just-fit-it-in" rebrand was eventually cut short by the announcement of another rebrand. Instead of making the same mistake again, or any of the other mistakes I've seen made, I convinced my team and product leadership (who sold the exec on it) to dedicate ourselves to nothing but the redesign. We finished the whole thing in six weeks.
I've written up how that project actually ran, including how we used Claude to do the manual labour safely.
This alternative isn't bravado — it's just matching the method to the problem. Pull a small team off the roadmap, tools down on everything else, and give them however many sprints it takes to finish the thing — but nothing else is allowed to compete with them for the team's time. Done in weeks, not straggling for a year.
It worked because the scope stayed fixed and the team's days stayed protected — not because we were faster or smarter the second time around.
The scope discipline matters as much as the dedication. This only works if you don't let feature changes sneak into those sprints alongside the redesign, and if you don't let any other stream of work run in parallel that would need building twice or cost you days merging competing branches. Mixing them is how six weeks becomes six months.
That's exactly what doomed the solo-developer rebrand: one person pulled aside to work alone, while the rest of the team kept shipping features around them faster than the work could be converted. Nobody wanted to be the one piling more onto a project that was already drowning, so nobody stopped it — and it never shipped.
The objection
"But that's disruptive — you can't just stop the roadmap for six weeks."
Sure you can, and you should, because the alternative costs more. Weigh six weeks of paused feature work against a year of a Frankenstein app quietly degrading your velocity, or a redesign that dies behind a flag and has to be re-sold to execs from scratch. The disruption isn't the six weeks. It's pretending you can avoid them by spreading them across a year instead.
If the scope is "the whole app" and why you're making the change isn't in question, stop asking how to phase it in around everything else. Tools down, and go do it.
Top comments (0)