Ways of Working: Revision

This part asked a deceptively small question: once you have a group of people and a goal, how should they actually work together day to day? Not the goal itself, not who reports to whom — the rhythm. When does work get decided, how does it move, who talks to whom, and how often. That rhythm is your “way of working,” and most teams inherit theirs by accident, copying whatever the last place did.

The whole part argued for the opposite: choose your way of working on purpose, from an understanding of what it’s for. This page pulls the threads back together so you can hold the shape of the part in your head at once — no new material, just the throughline made plain.

The one question underneath everything

Every method you met sits on a single spectrum. At one end is planning up front — decide the whole path before you start, then execute it. At the other end is adapting as you go — take one small step, look at what happened, decide the next step from what you learned. Waterfall lives near the first end; the more iterative approaches live near the second.

Neither end is “advanced” or “backward.” The second page of the part made the deciding factor concrete: how much uncertainty you face. When the work is well understood and the cost of a wrong turn is high — pouring a building’s foundation, running a payroll cycle, a surgical checklist — planning up front pays off, because you can know the path and you can’t afford to wander. When the work is genuinely uncertain — a new product, an unfamiliar market, a problem nobody on the team has solved before — heavy planning just produces a confident, detailed map of the wrong territory. There, adapting wins, because the only way to learn the terrain is to walk a little of it.

   PLAN UP FRONT  <───────────────────────────────>  ADAPT AS YOU GO
   low uncertainty                                    high uncertainty
   known path                                         path discovered by walking
   change is costly                                   change is expected
   (foundation, payroll,                              (new product, new market,
    surgical checklist)                                unsolved problem)

Most real work is not at either extreme. It’s somewhere in the middle, and often different parts of the same project sit at different points. So the skill is not picking a side — it’s locating your work honestly on the spectrum and choosing a rhythm that matches.

In practice — one project, two ends of the spectrum

A cafe opening a second location shows how a single effort spans the whole spectrum. The lease, the buildout, and the health inspection are near the plan-up-front end — the path is known, the sequence is fixed, and getting it wrong is expensive, so you plan carefully and follow the plan. But the new menu, the local marketing, and the opening-week staffing are near the adapt end — nobody knows yet what this neighborhood will actually buy, so you try small things, watch what sells, and adjust weekly. Treating the whole opening as one big up-front plan would over-plan the menu and under-plan the plumbing. The honest move is to place each piece separately.

Scrum: a rhythm for adapting on a heartbeat

Scrum is one popular answer to “how do we adapt in an organized way?” Its core insight is that pure improvisation is exhausting and pure planning is brittle, so it splits the difference with a heartbeat — a fixed, short cycle called a sprint (commonly a week or two). You plan only as far as the next heartbeat, do the work, show the result, and reflect. Then you do it again.

The pieces all serve that heartbeat. A prioritized backlog is simply the to-do list kept in order of importance, so that whatever you pull into a sprint is the most valuable thing available right now — priorities can change every cycle without derailing anything. Roles give the recurring decisions an owner: someone accountable for what is most worth doing, someone accountable for helping the team actually do it, and the people doing the work. And the retrospective — the team pausing at the end of each cycle to ask “what should we change about how we work?” — is the quiet engine of the whole thing. It’s a loop that improves the process itself over time, not just the product. A team that runs honest retrospectives gets a little better at working every few weeks, compounding.

Strip away the vocabulary and Scrum is: work in small time-boxes, always do the most important thing, show real results often, and deliberately improve how you work. That’s it.

Kanban: make the work visible and stop starting so much

Kanban attacks the same problem from a different angle. Instead of a fixed heartbeat, it starts with a truth every busy team feels: work that’s invisible can’t be managed, and a team that starts everything finishes nothing.

So Kanban does two simple things. First, it makes the work visible — every task becomes a card that moves across columns like “to do,” “doing,” “done.” Suddenly the whole team can see what’s in flight, what’s stuck, and where things pile up. Second, and this is the counterintuitive heart of it, it limits work in progress — it caps how many things can be in the “doing” column at once. When the cap is full, you’re not allowed to start something new; you have to help finish what’s already moving.

That second rule encodes a principle worth memorizing: finishing beats starting. A pile of half-done work delivers nothing and hides where you’re actually stuck. By limiting work in progress, the bottleneck — the one step where things back up — becomes glaringly obvious, and it becomes everyone’s problem instead of one overwhelmed person’s private struggle. The whole team can converge on the jam and clear it. A warehouse that caps how many orders are “in picking” at once, a clinic that limits patients mid-assessment, a design team that stops taking new briefs until the current ones ship — all are using the same lever.

Where Scrum imposes a rhythm from the outside (the sprint), Kanban lets the rhythm emerge from the flow of work itself. Both are legitimate. Some teams even blend them.

Scrum and Kanban, side by side

It helps to see the two answers next to each other. They solve the same problem — organized adaptation — with different primary levers.

                    SCRUM                        KANBAN
  primary lever     a fixed cycle (the sprint)   a limit on work in progress
  rhythm            imposed from outside         emerges from the flow of work
  planning cadence  once per sprint              continuous, as capacity frees up
  best when         work benefits from a steady  work arrives unpredictably or in
                    beat and clear commitments   a steady stream of varied requests
  the core habit    the retrospective loop       watching and clearing bottlenecks
  shared idea       show real results often; improve how you work over time

Notice the bottom row: whichever tool you pick, you are trying to deliver value often and get better at working. The levers differ; the purpose is the same. That shared purpose is what lets a team borrow from both — running Scrum’s retrospective while also capping work in progress, for instance — without contradiction.

The frameworks are tools, not identities

Here is the part’s most important warning, and the reason the final content page exists. Scrum and Kanban come with rituals — the daily stand-up, the sprint planning meeting, the board, the retrospective, the estimates. Every one of those rituals exists to buy a specific benefit: visibility, alignment, learning, focus. But rituals are easy to copy and hard to understand, so teams routinely adopt the ceremony without the reason.

The common trap — cargo-culting the rituals

The phrase “cargo cult” comes from groups who, having seen cargo planes land during wartime, later built runways and mock control towers out of straw hoping the planes would return — imitating the visible form while missing what actually made it work. Teams do this constantly with methods: they hold a stand-up every morning that nobody finds useful, run sprints that don’t end in anything shippable, or estimate every task in points while ignoring the estimates entirely. When you can’t answer “what is this ritual for, and is it delivering that here?”, you are almost certainly paying the cost — the time, the meetings, the overhead — while getting none of the benefit. Cargo-culting is the single most reliable way to make a good method feel like pointless bureaucracy.

The cure is to treat every practice as a claim you can test. A stand-up claims to give the team shared awareness and unblock people quickly. If yours does that, keep it. If it’s become a status report to the manager that everyone dreads, either fix it back toward its purpose or drop it. The method is not a team you belong to or a badge you wear — “we’re a Scrum shop” — it’s a set of tools, and tools that don’t earn their keep should be put down without guilt.

The evidence — process helps most where it’s needed most

Studies of team performance generally find that the amount of process a team needs tracks with how uncertain and interdependent the work is — heavy coordination pays off when many people’s work depends on each other and the path is unclear, and becomes pure overhead when the work is simple and independent. That mirrors this part’s whole argument: there is no universally “right” amount of ceremony, only an amount that fits the work in front of you. Treat any figure claiming a single best cadence or team size with suspicion; the useful truth is directional, not precise.

The throughline

Zoom all the way out and this part rests on the same foundation as the rest of the book. Method exists for exactly one reason: to turn people plus a goal into reliable outcomes — steadily, without the chaos of pure improvisation or the burnout of forcing a rigid process onto uncertain work. Everything in this part is downstream of that.

That’s why there is no single right way of working, and anyone selling you one is selling. The planning-versus-adapting spectrum tells you which direction to lean based on how much uncertainty you face. Scrum and Kanban are two well-worn tools for leaning toward adaptation, each with its own logic — a heartbeat, or a flow. And the discipline that ties it together is the refusal to worship any of them: you fit the method to your context, keep the practices that visibly earn their keep, quietly retire the ones that don’t, and let your retrospective loop keep adjusting the fit as the context changes.

If you remember one sentence from this part, make it this: the method serves the outcome, never the other way around. The moment a team is working hard to satisfy the process instead of using the process to do good work, the tool has become the master — and it’s time to pick up a different tool, or reshape the one you have.

How it connects

This part gave you the rhythm a team works to. It leans on the Teams part, which is about who’s on the team and how they relate, and it feeds directly into Project Management, where these ways of working meet real scopes, deadlines, and stakeholders. The retrospective habit at the center of Scrum is the same improvement loop that runs through the whole book — the willingness to look honestly at how you work and change it — and it reappears in Meetings and One-on-Ones as the small, regular checkpoints where that honesty actually happens.