Software process

One of my university courses was called software process. During the course, I had several insights into what a productive software process might look like. At my previous job, one of my tasks was to be a scrum master of the development feature team. During the university course new ideas clicked. This article crystallizes the ideas.

---

Limiting Work In Progress

One of the key ideas of one of the guest lectures, was limiting the Work In Progress (WIP) Count during a sprint. After hearing this statement, I immediately understood what the speaker was talking about. At work, one of my coworkers was a star at saving up multiple issues at once. And then all of a sudden 7 issues were ready to be code reviewed. The result might be obvious: a lot of work was in the waiting state for days and reviewing was bombarded.

Nowadays, I use several metaphors to explain how too much load hinders flow.

Traffic jams

One of the metaphors is traffic jams. Too many cars at once result in a traffic jam. Because of this, the preferred speed can not be achieved. In software this means the velocity drops. However, 10% less cars might make the whole highway drive smoothly.

Juggling

Juggling is also a good example. For a juggler, 3 balls are experienced as easy. However after too many balls, say 6, all balls fall.

To ensure the sprint operates smoothly less balls in the air should be preferred. This also can be longer endured as the developer finds it easy.

The Zeigarnik effect

Then there is the Zeigarnik effect. Our brains essentially keep an open “mental loop” for unfinished work, making it harder to forget. This means unfinished issues will keep lingering in your mind until the work is solved.