Ways of Working

Software borrowed its original process from construction. Write down every requirement, freeze the design, build exactly that, inspect at the end. Each stage had to finish before the next began, and the work only flowed downhill, which is why people called it waterfall. For a bridge that sequence makes sense. Nobody relocates a pier after half the columns are up.

Software turned out to need the trip back uphill constantly. Teams would spend eighteen months building to a specification and hand over something the customer no longer had a use for, because the business had moved on in the meantime. Of the 300 requirements written at the start, forty would end up being the ones anyone touched. The structure guaranteed that you learned you were wrong last, after the money was gone.

So in 2001 a group of practitioners published a statement arguing for the opposite sequence, and a flood of rules followed for actually running it: build a small piece, show it, correct course. Meeting names, role names, units for counting work, conventions for using a board — each arrived with a label attached. A decade later no two companies had the same combination. One team cut its work into two-week chunks, another refused to cut it at all and managed flow instead, a third mixed the two.

This axis is the name for that accumulated pile of rules. Why the pile needs a single name becomes clear on somebody's first day. "Let's put that in the next sprint." "Drop it into the backlog for now." "We're full, I can't pull anything else in." Sentences like these go by several times a day. A sprint is a work cycle cut to a fixed length, usually two weeks; a backlog is the list where untouched work waits. Both words come out of the same framework, and that framework has a name and a manual — but without the connection, a newcomer memorizes them as isolated slang.

The terms under this name split seven ways: what a team believes about building software (methodology), how that belief turns into rules (framework), who tends the rules (roles), how effort gets sized (estimation and planning), how people talk and decide (collaboration), how work is cut into trackable pieces (work management), and where all of it falls apart (risk).

Methodology is the layer of attitude, and there are two entries. Agile says: don't lock the plan, build something small, show it, then correct direction. Lean says: anything that doesn't turn into value is waste, so remove it and make the flow faster. The two overlap rather than compete. Twelve half-built features held open at once reads to agile as feedback arriving too late and to lean as inventory piling up, and both give the same instruction: start less, finish things. What neither one tells you is what to do tomorrow morning. How many meetings there are and who gets to decide what is settled one layer down.

Framework is where the attitude becomes rules you can follow. There are four, and the first fork is whether you cut time or manage flow.

1. Scrum — cuts time into fixed lengths such as two weeks, with a meeting at the front to choose what goes in and one at the back to look at what happened. Roles and meetings are specified down to their names, which makes it the easiest framework for a team to adopt cold.
2. Kanban — makes no cuts and instead lays the flow of work across a board. Its central rule caps how many items can sit in any one column at a time. Limit "in development" to three and the person about to start a fourth goes and clears a blockage instead. It fits teams where incidents and inbound requests arrive without warning.
3. Extreme programming — regulates coding habits rather than meetings. Two people working at one screen, writing the test before the feature, merging everyone's work several times a day: those are its rules.
4. Scaling framework — the extension layer for putting rules designed around one team on top of many. At eight teams, each team running well on its own stops being enough, and you need explicit rules for the points where teams wait on each other.

Roles divide by who tends those rules. There are four seats, separated by whether the seat serves one team or many and whether it owns only the process or the people too.

1. Scrum master — attached to one team, keeps the meetings doing real work and clears whatever the team is stuck behind. Not a boss: the seat assigns nothing and evaluates nobody.
2. Agile coach — moves between teams teaching them to improve how they work. Less about solving the problem than about leaving the team able to solve the next one.
3. Delivery manager — watches whether what was promised ships when it was promised. Mostly needed on large releases where several teams and outside dates are entangled.
4. Engineering manager — also owns the engineers' evaluation and growth. Authority over people is what separates this seat from the other three.

A company of ten fills all four seats with one person. As headcount grows, the process seat is usually the first to break off on its own.

Estimation and planning deals with how long things take. Agile estimation sizes work in relative terms instead of hours: call the login screen a 3, then size everything else against it as a 1, 2, 5 or 8. Hours fail as the unit because the same task takes different people different amounts of time, which makes the sum meaningless. Capacity planning counts what the team can actually absorb next cycle. Five engineers over two weeks looks like fifty person-days, but subtract three days of vacation, two days of interviews and four days of helping another team and you have forty-one. Estimation measures the size of the work; capacity measures the size of the container.

Collaboration covers the rules between people. Collaboration mode sets when the team gathers and when it works apart. Talking it out in a shared hour and writing it down for people to read later differ in exactly opposite ways on speed and on record-keeping, so a team whose working hours barely overlap leans toward writing. Decision making writes down in advance who settles what. Wait for everyone to agree, hear everyone and let one person call it, or hand it off entirely — pick per type of decision, or the same question reopens in every meeting. Five people trying to reach consensus on a price increase will still be at it three weeks later.

Work management covers the units work gets cut into. A work item is one entry in the issue tracker. The layers run from large to small — epic, story, task, bug — and each layer carries different information. How far down to cut is the team's call, usually to something one person finishes within a few days. When the pieces are wildly uneven in size, counting the remaining ones tells you nothing about progress.

Risk gathers the places where the other six give way. Delivery risk covers scope creeping outward, work stalling while another team finishes something, and code rushed out in one cycle slowing the next one down. None of the three appears out of nowhere; each is the delayed result of an earlier decision.

The seven aren't menu items picked independently — they hold each other up. Choose a framework and the meetings and roles come with it; fix the roles and the decision rules follow; you need an estimation unit before a plan means anything; and risk surfaces exactly where the plan and reality separate. That's why one piece lifted out on its own usually spins free. If a team adopts the fifteen-minute morning meeting and nobody ever mentions being stuck, what's missing isn't the meeting. It's the agreement that saying so costs you nothing.

"First week is about learning how the team works — what the meetings are, who makes which call."

Knowing the team's rules matters before individual skill does, because nothing moves without them. A strong engineer who doesn't know which meeting settles scope waits a week for an answer that was available on Tuesday.

"This isn't a tool problem. It's a ways-of-working problem."

Changing the ticket template or the board settings won't fix it; the decision process and the meeting structure are what need work.

"The old setup doesn't fit now that we're bigger. Let's redo it next quarter."

Rules that held at eight people broke at twenty-five, so the team needs to agree on new ones. A morning meeting that took fifteen minutes with eight people takes fifty with twenty-five, and most of the room stops listening halfway.

Pagedeck reached 45 people and the teams stopped working the same way. Mia's product team runs in two-week cycles. Theo's platform team runs no cycles at all and manages flow on a board. When Grace asked why one company needed two answers, Theo's argument was about the kind of work each team receives. The product team can decide today what will exist in two weeks. The platform team gets incident reports and requests from other teams with no warning, so the harder it tries to hold a cycle, the more often the plan breaks mid-week.

The two teams did align on some things. They use the same names for the layers of a work item, they review how they work on the same day each quarter, and requests that cross team lines come through one channel. Rather than standardize the whole method, they standardized the seams.

The most common mistake is treating ways of working as a list of meetings and tools. From outside, meetings and boards and tickets are all that's visible, so the reading is understandable. What actually separates a fast team from a slow one is where decision authority sits and how quickly bad news travels upward. Copy the list alone and you get the shape without the change: everyone gathers each morning, recites yesterday, disperses, and the person who has been blocked for a week still says nothing. The meeting count climbs, the time from idea to release sits exactly where it was, and the team concludes that process is a tax rather than that it copied the wrong half.

Believing there's one right answer is the other frequent error. Books and certifications teach complete rule sets, so one of them looks like the correct one. But what fits depends on team size, on what the product is, and on what the company promised customers. A team with a contractual response time and a team still searching for something worth building cannot run the same rules. Believing in a single answer leads to importing another company's setup wholesale, and then, when it runs badly, concluding that the team failed to follow it properly rather than that the rules were wrong. After that the real problem never gets found.