Scrum, Kanban, Shape Up, or Linear-Style Flow: Which Software Methodology Actually Fits Your Stage?

Founders ask me this question in some form almost every week. "We are doing Scrum but it does not feel right. Should we switch to Kanban? Someone told me about Shape Up. What do you actually use?"

The honest answer is that I do not use the same methodology at every client. I pick based on team size, product stage, and what the team is actually struggling with. But the decision is not random — there is a framework, and this article is it.

I will walk through the four methodologies I actually see working in startups, what each one is good at, what it is bad at, and a simple decision tree at the end. By the time you finish reading, you should know which one fits your team today, and you should also know why the one you are doing now is not working.

The four methodologies worth knowing

I am not going to pretend to cover every agile variant that has a certification program behind it. In the field, on teams under 100 engineers, the vast majority of what works falls into one of these four buckets.

Scrum

What it is: Time-boxed sprints (usually two weeks), with a defined set of ceremonies: sprint planning, daily standup, sprint review, retrospective. Work is broken into user stories and estimated in points. A product owner owns the backlog. A scrum master runs the process.

What it is good at: Giving a team that has never had any process a starting structure. Creating predictability for external stakeholders who need to know what is shipping in two weeks. Surfacing process friction through retros.

What it is bad at: Early-stage product work where requirements change faster than the sprint length. Teams that hate ceremony. Engineers who feel infantilized by story points. Anything where the cost of context-switching between "sprint planning work" and "real work" eats more time than the process saves.

Honest take: Scrum gets a lot of hate, most of it deserved when practiced badly and undeserved when practiced well. At the 15–50 engineer scale in a mature product, a well-run Scrum practice is a perfectly reasonable choice. At the 5–10 engineer scale on a rapidly evolving product, it is almost always overkill and the team can feel it.

Kanban

What it is: Continuous flow instead of sprints. Work moves across a board with explicit WIP limits (work in progress limits). The rule is simple: do not pull a new task until you finish or unblock the one you are on.

What it is good at: Teams with a continuous stream of incoming work where the mix changes unpredictably — support engineering, platform teams, any team that has a lot of reactive work alongside planned work. Reducing WIP and surfacing bottlenecks. Teams that want to ship when things are ready, not when the calendar says so.

What it is bad at: Planning work more than a week ahead. Coordinating with non-engineering stakeholders who want to know "what are we shipping this month." Teams that use Kanban as an excuse to never plan at all.

Honest take: Kanban is the most underrated methodology for small startup teams. I install it more often than any other option. But it requires WIP limits to actually be enforced, and most teams that say "we do Kanban" are really just "we use a Trello board."

Shape Up

What it is: A methodology popularized by Basecamp (the company). Work is done in six-week cycles, followed by two-week cooldown periods. Before each cycle, leadership shapes the work — defining the problem, sketching the solution at a medium level of abstraction, and setting an appetite (the maximum time the team is willing to spend on it, not an estimate of how long it will take). Teams then have autonomy to figure out the details during the cycle. If the work does not fit in the appetite, it gets killed or descoped, not extended.

What it is good at: Small product teams making product decisions under uncertainty. Avoiding the trap of endless estimation. Protecting leadership's strategic focus (six-week cycles create natural decision points). Forcing explicit tradeoffs between scope and time.

What it is bad at: Teams with a lot of reactive or unplanned work (Kanban is better). Teams with tight external dependencies or fixed ship dates. Very young teams that do not yet have the judgment to shape work well.

Honest take: Shape Up is my personal favorite for the 5–25 engineer scale doing real product work. It makes leadership do the hardest work (shaping, making tradeoffs explicit) before anyone commits, which is exactly where most teams fail. It is not for everyone, and it requires discipline from the founders, not just the engineers. But when it works, it really works. I will write a separate article on when it breaks.

Linear-Style Flow ("ship when ready")

What it is: Less a formal methodology than a pattern I see in very high-performing small teams. Named after the way teams using tools like Linear tend to operate. Work is tracked in a simple issue list with priorities and clear ownership. There are no sprints, no story points, and no formal planning ceremony beyond a weekly sync. Engineers pull the next thing off the list when they finish the current one. Things ship when they are done. The team plans one week ahead and has a rolling sense of the next month.

What it is good at: Small, senior teams who trust each other and do not need ceremony to stay aligned. Shipping fast. Not wasting time on process. Adapting to changes within a few days instead of a few weeks.

What it is bad at: Larger teams where informal coordination breaks down. Teams with a lot of junior engineers who need more structure. External stakeholders who need roadmap clarity. Any situation where the lack of ceremony is a cover for a lack of discipline.

Honest take: This is what works at the 3–8 engineer stage when the team is senior and the founder is close to the work. It is also what teams think they want when they are complaining about Scrum, but it works much less well than people expect once you are past a dozen engineers. It requires trust and judgment that most larger teams do not have uniformly.

The decision framework

Here is the tree I actually use with clients. Four questions.

Question 1: How big is the engineering team?

Under 8 engineers: Linear-style flow or Shape Up. Skip Scrum entirely. Kanban works if the team has a lot of reactive work.
8 to 25 engineers: Shape Up or Kanban for product teams, depending on how predictable the work mix is. Scrum is an option but rarely the best one.
25 to 50 engineers: Mix. Stream-aligned product teams usually do Shape Up or Scrum; platform teams usually do Kanban. Different teams do different things on purpose.
50+ engineers: You are past the point where a single methodology answer works for everyone. Let teams pick within a narrow menu (e.g., "Scrum or Shape Up, not both") and focus on cross-team coordination instead.

Question 2: How predictable is the work?

Mostly planned, product-driven work: Shape Up or Scrum.
Mix of planned and reactive work: Kanban, or Shape Up with a defined "reactive capacity" each cycle.
Mostly reactive / unplanned work (e.g., support, platform): Kanban.

Question 3: What is the team struggling with right now?

"We never finish what we start." WIP is too high. Kanban with strict WIP limits, or Shape Up with firm appetites. Not Scrum — Scrum allows WIP creep between sprints.
"We cannot predict what we will ship." Shape Up (if you control the roadmap) or Scrum (if you need to commit externally). Linear-style flow will make this worse, not better.
"We argue about estimates constantly." Kill story points. Switch to Shape Up (appetite) or Linear-style flow (no estimates).
"Our ceremonies eat half the week." Your process is too heavy for your team size. Scale back to Kanban or Linear-style flow.
"Junior engineers are lost." You need more structure, not less. Scrum or a structured Shape Up with clear mentorship pairing.

Question 4: How mature is the product?

Pre-product-market fit: Shape Up or Linear-style flow. Scrum's two-week commitment is too rigid.
Scaling a working product: Any of them work. Pick based on team size and predictability.
Mature, revenue-critical product: Scrum or Shape Up with strong guardrails. Linear-style flow is too loose.

The "agile transformation" trap

I want to call out one pattern specifically because I see it almost monthly. A startup hires a "head of agile" or an agile coach, runs a multi-month transformation program, and emerges with more meetings, more Jira fields, and the same shipping velocity.

What actually happened: they mistook ceremony for methodology. They added process without removing anything. They trained people on frameworks without asking whether the framework fit the problem.

The fix is not "more agile." The fix is usually less of everything. Fewer meetings. Fewer artifacts. Fewer estimates. More trust in the team to do the work, combined with specific decision points where leadership commits to tradeoffs.

If your current methodology conversation sounds like "we need to do Scrum better," stop. Take a week. Ask the team what they would actually keep and what they would cut. Then cut.

What I do at my clients

When I walk into a new fractional CTO engagement, I do not prescribe a methodology in the first meeting. I watch for two weeks. I go to the standups. I read the backlog. I sit in on planning. I ask each engineer one question: what is in your way?

Then I propose. Most of the time it looks like one of these three patterns:

Small senior team (under 10), founder is a great product thinker: Shape Up with six-week cycles, weekly sync, rolling backlog. Founder does the shaping alongside me for the first cycle, then gradually takes it over.
Midsize team (10–25), mixed seniority, complex product: Shape Up for product teams, Kanban for platform or support-heavy work. Explicit interaction modes between teams (see Team Topologies). DORA metrics as the shared scoreboard.
Team that had a bad Scrum experience and wants to "just do Kanban": Start with Kanban, enforce WIP limits hard for four weeks, then layer in appetite-based planning once the team has stabilized. Do not call it Shape Up because the word is loaded; just do it.

Notice that none of these start with "first, we overhaul everything." The highest-leverage move is almost always removing something: killing a meeting nobody benefits from, dropping story points, cutting a planning ceremony that produces no decisions.

Counterpoint: the methodology matters less than the operating rhythm

I will contradict the premise of this article for a moment. If you have a strong weekly operating rhythm — clear planning, real retros, protected maker time, good 1:1s — the methodology on top of it is almost a rounding error. I have seen teams thrive with mediocre Scrum and a great rhythm, and I have seen teams sink with perfect Kanban and a broken rhythm.

So before you switch methodologies, ask whether the rhythm is actually working. If it is not, fix the rhythm first. The methodology is a structure; the rhythm is the pulse. Structures without a pulse are just shapes.

Your next move

This week, do two things:

Write down what is actually frustrating about your current methodology. Not the vague "it feels slow" — the specific things. Who is frustrated. About what. When.
Run the decision framework above against your team and product stage, honestly. If the answer is the same methodology you have now, the problem is execution, not choice. If the answer is different, the problem is fit.

Do not change methodologies in the same week you notice the problem. Sit with the decision for a week first. Real methodology changes are expensive and disruptive; do not make them in a mood.

Where I come in

Choosing and installing a software methodology is one of the specific things I get hired to do. Usually I am not replacing an old methodology — I am helping a team see that the real problem is how they are doing the one they have, and that a small number of well-chosen changes will move them more than a full transformation.

If you are staring at your team's Jira board wondering why the velocity chart looks so sad, let's talk. I will ask you a dozen specific questions, tell you what I would try in the first month, and we can decide from there whether there is a fit.