I asked you to share the challenges you’ve observed with regard to incremental software delivery. Fellow list reader Robert Höppner wrote in on the struggle of “true teamwork” in software development:

Hi Jonathan,

In my experience, most teams use the scatter-gather approach for work and assign individual tasks to each team member. These tasks are often purposefully unrelated so that the team can achieve a high degree of parallelization.

The flip side is that most of the time, only one team member is working on the single most important, small change. This weakens the build-measure-learn cycle.

Actual teamwork—mob programming, pair programming, etc.—is much more efficient when it comes to creating small, deliverable changes. But somehow, project managers don’t seem to like it.

Best,
Robert

I agree with Robert’s assessment. Although the efficiency gains from pairing/mobbing aren’t always intuitive. Perhaps the most obvious efficiency gain from pair/mob programming comes in the form of the avoided code review (if, indeed, you choose to avoid another, async code review). But that’s not the only one, and perhaps not the most important. I’m not going to write a treatise on pair programming here (I wouldn’t be qualified, anyway), but there are many benefits: We use different parts of our brain when typing (driving in pair programming parlance) and reading (navigating), making the trade-off not between one brain and two, but more like between half a brain and one. We reduce communication overhead with pairing. And we get different perspectives. We optimize for finishing work, rather than starting work. Just to name a few of the benefits.

And then getting back to incremental work… it’s almost always easier, especially early on, to find ways to further slice your task, with the help of other people.