09Stories without increments

A second kind of myopia affects scope rather than time. When team members define themselves by a narrow technology ("I do React and Redux, nothing else"), stories get reshaped to fit individual skills. The result is a story that is a collection of tasks rather than a slice of value.

What Scrum actually asks

Scrum requires the team to be cross-functional, not each individual. Nobody is expected to master every skill. The framework has, however, consistently pushed against silos within the team: earlier versions of the Scrum Guide rejected sub-teams and titles, and the 2020 version replaced "Development Team" with a single word, "Developers". The usual model is the T-shaped profile, or what Scott Ambler calls the generalising specialist: deep expertise in one area, combined with the ability and willingness to contribute in neighbouring ones.

How fragmentation happens

1. Stories are split by technology layer (front end, back end, database, tests) instead of by value.
2. Each fragment becomes a task for one specialist, and the breakdown continues until every piece fits an individual profile.
3. Nobody owns the story as a whole. Coherence is expected to emerge at integration, late in the sprint.
4. The sprint turns into a small waterfall: everything is "90% done" on the ninth day, work in progress is high, and the increment is not usable.

Conway's law, formulated in 1968, adds a lasting consequence: systems tend to mirror the communication structure of the organisations that build them. Teams organised by technology layer produce architectures organised by layer, with rigid interfaces between them, and every new feature has to cross all of them. Narrow skill sets end up shaping the codebase as well as the backlog.

The causes are mostly organizational

• Utilisation thinking. When managers want every person busy all the time, work is shaped to keep each specialist occupied. Lean thinking makes the opposite argument: optimise the flow of work, not the utilisation of people. Modig and Åhlström's This Is Lean explains the distinction between resource efficiency and flow efficiency clearly.
• Hiring and careers by keyword. The market hires "React developers", CVs are written that way, and people protect their employability by staying in their lane.
• Individual tracking. When individual output is measured, several people swarming on one story looks like waste, even when it is the fastest way to finish it.

The economics are also shifting. AI coding assistants considerably lower the cost of working outside one's core stack; a front-end developer can now contribute credibly to a back-end change with assistance. The argument "that is not my skill" is weaker than it was a few years ago. What remains is mostly a matter of willingness and incentives.