Limit your pull requests and see what happens. This is our story.
A problem many developer teams face is an increasing number of pull requests. Have you ever heard yourself say “The work is done, it just needs to be reviewed”, only to have it merged days (or weeks 😱) later?
Believe it or not, our iOS team also had this problem. It was not uncommon for us to have 22 pull requests open for review. Let’s put this in context: 22 pull requests in a team of 8 developers. If all of those pull requests are counted as work in progress all of us were doing 2.75 things at once.
It seemed like a few people did most of the reviewing, which also meant getting anyone to review your pull request was a tough process.
I hope this is not the first time you hear this, but multitasking is a myth. Us humans are terrifically bad at it. What we actually do when we “multitask” is task switch (or context switch).
Having recently joined and seeing this as a pain point in the team, I felt we could run two fun exercises to highlight this problem. Enter our first game…
The first game: Proving you don’t multitask well
- Draw four columns on a page
- Write one of these at the top of each column: “1–12”, “3–36”, “Jan-Dec” and “7–84”
The objective: Fill out all the columns so that the first column would have 1, 2, 3 etc., the second column will have 3, 6, 9, 12 etc., the third column Jan, Feb, Mar, etc. and the fourth column 7, 14, 21 etc.
Time yourself doing this.
Round 1:
Complete all columns by writing one value in each column, i.e. jumping between columns as you go. (You’ll write 1, 3, Jan, 7 in the first row and then move on to the next row, writing 2, 6, Feb, 14 etc.)
This should take you about 90–120 seconds. Go ahead. I’ll wait.
Round 2:
Complete all columns by finishing one column completely before moving on to the next column. (You’ll write 1, 2, 3 … 12 in the first column, then move on to the next column 3, 6, 9 … 36 until all columns are finished.)
This should take you about 60 seconds.
The result
Sorry to break it to you, but like billions of people, you are also bad at multitasking/task switching/context switching. In round 1 you paid the price of task switching by taking nearly twice as long to complete all the columns. Writing numbers and names of months on a piece of paper is not a difficult task. Imagine if you were task switching between refactoring, debugging a production issue and checking Slack 🤯
The second game: Proving you don’t have to write code to contribute
Now we’re going to fold some origami. Yes, the art of paper folding. This is going to require your whole team. So gather everyone ‘round. You’ll probably need between 4 and 8 people.
Here are the instructions:
We are going to make a production line to create paper boats. Divide the steps from the instructions among the team members like this (assuming 5 people):
The first person does step 1, the next person does steps 2 and 3, the next person does step 4, the next person does steps 5 and 6 and the last person does steps 7, 8 and 9. You can change these up if you have more people, but purposefully create a bottleneck by at least giving the last person more steps to do.
The objective: Make as many paper boats as possible in 3 minutes.
Round 1:
As soon as the clock starts, the first person does their fold, passes it on to the next person and immediately grabs a new piece of paper to fold. Everyone in the queue then continues to make their folds and pass it on to the next person as fast as they can.
After three minutes sound the airhorn and stop. Now, count three metrics: the number of finished paper boats, the number of unfinished boats (any paper with a fold still in the queue) and the number of finished boats of which the team is happy with the quality.
Round 2:
This time each person is only allowed to pass work to the next person if the next person is not currently busy with a fold. To signal this properly have each person sit with their hands in the air if they are not busy with a fold. When someone has their hands in the air, the person before them in the queue will know they can pass work on to them. Some people will find themselves with their hands in the air more often than not.
After three minutes sound the airhorn again and stop. Count the three metrics again: the number of finished boats, the number of unfinished boats and the number of quality boats.
The result
You should have the same number of finished boats after both rounds (or more after round 2).
However, round 2 will have significantly less unfinished boats and also the same number of quality boats (or more).
This is a nice practical example of the difference between a push system and a pull system. In round 1 everyone was pushing work into the system, regardless of capacity. In round 2 work is pulled through the system when there is capacity to perform the task.
Combining the results of the two games
Armed with the results of these two games we realised a couple of things:
- Writing more code and creating more pull requests were actually harming the amount of work we are capable of delivering.
- Having more open pull requests than we have people on the team slows down our “production system”.
- If we are constantly switching between writing code and reviewing code (without finishing either) we are increasing the time it takes to finish both tasks.
How we improved
We have limited the number of “allowed” open pull requests to six. If we submit a pull request and hit the limit (or pass it) we don’t continue to our next coding task without reviewing some pull requests first.
We have seen a dramatic reduction in review time for our pull requests which results in a very welcome increase in output and all of us have more time to review other pull requests.
Not only do we have more time to review, but reviewing has become a shared responsibility within our team.
As a bonus we feel more like a team than we ever did, since everyone is involved, collaborating and sharing knowledge on our open pull requests.
Try it out
These games and insights have made a significant difference to our development process. I hope it can inspire and help you to build great products. Like Over 😃
Further reading
Lean Software Development: An Agile Toolkit
A must-read about the concept of waste in a software production system — how to recognise it and how to avoid it.
The mathematical analysis of how work flows through a system with queues. The article explains how to avoid queues and how to implement work in progress limits (like we did) to avoid the pitfalls of unavoidable queues.
