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 crystalizes 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 immediatly 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 out of sudden 7 issues were ready to be code reviewed. The result might be obivious: a lot of work was in the waiting state for days and reviewing was bombarded.
Nowadays, I use several mythaphors to explain how too much load hinders flow. One of the methaphors is traffic jams. Too many cars at once result in a traffic jam. Because of this, the preffered speed can not be achieved. In software this means the velocity drops. However, 10% less cars might make the whole highway drive smoothly. 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 preffered. This also can be longer endured as the developer finds it easy.
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.
Reasons for unlimited WIP
The speaker quoted reasons why teams operate with unlimited WIP:
- Resource utilization: “I don’t want to look idle” / “We need to keep everyone busy”