Slow CI and/or Code Review makes concurrent work a bit of a necessity. Context switching certainly has a cost, but it's cheaper for my employer than paying me to wait for tests to run.
I've had this exact problem (~30min CI and slow CR) on my current project. For a while I've sucked it up and did concurrent work as you say.
After a while it becomes apparent that this concurrent work is making us lose a lot of time:
- PRs still aren't merged several days (2 on average, regularly more) after being open. The longer they stay the more expensive they become (regular rebasing, context-switching, CRs being more and more exigeant and enlarging the scope of the PR)
- Bugs appear. Doing several things in parallel leads to a loss of quality.
- We're not improving, this unideal situation becomes the norm.
So I'm trying something else: we're not starting a new ticket before the last one is done. That means waiting for CR, waiting for the CI. That means having times where my employer pays me to wait for tests to run. Well, the result:
- We're actually faster. The context switching + rebasing cost is far higher than waiting 30min for tests to pass.
- Now, the problem that the CI and the CRs are slow is visible (I'm visibly not doing anything), which means that we can work on it and improve! That's a basis of lean manufacturing: make problems visible.
- We chase people to get reviews, so the lead time of each ticket significantly decrease. Also I'm automatically available to help people review my code (if it's a complex bit or it's a junior reviewing).
- We take tickets to improve our CI and our testing perfs
All in all, doing one thing at a time was already more efficient, and in addition we can make our process more and more efficient.
The main pushback on this is generally "but we need to context-switch to review PRs", but in the end you do way more context switching when working on several things at once.
Say I'm multiplexing my available hours among three things, but I get blocked sometimes. So in an effort to avoid ever having time wasted because I'm idle, I switch to having five active things instead.
Now it takes longer for me to cycle around among those things. So the people who are waiting on me for code reviews have to wait longer. They also decide to switch from having three things on their plate to five things on their plate.
Now I'm waiting even longer for their code reviews because it also takes them longer to cycle back around. I start thinking about switching from five things on my plate to seven things on my plate.
It may not really spiral out of control this bad, but it does have a bit of a tendency to self reinforce.
Sometimes it really is a good idea, but the point is there is a trade-off. In some cases, a little idle time can cost less than the problems caused by everybody juggling more stuff.
In real life, things are complicated. Not everything I'm blocked on is another person. Some tasks I need to get done don't block someone else. If I submit my travel expense report a week later, I'll just get reimbursed in a different pay period, so turnaround time doesn't matter there like it does when someone else is depending on me to unblock them.
I've had this exact problem (~30min CI and slow CR) on my current project. For a while I've sucked it up and did concurrent work as you say.
After a while it becomes apparent that this concurrent work is making us lose a lot of time:
- PRs still aren't merged several days (2 on average, regularly more) after being open. The longer they stay the more expensive they become (regular rebasing, context-switching, CRs being more and more exigeant and enlarging the scope of the PR) - Bugs appear. Doing several things in parallel leads to a loss of quality. - We're not improving, this unideal situation becomes the norm.
So I'm trying something else: we're not starting a new ticket before the last one is done. That means waiting for CR, waiting for the CI. That means having times where my employer pays me to wait for tests to run. Well, the result:
- We're actually faster. The context switching + rebasing cost is far higher than waiting 30min for tests to pass. - Now, the problem that the CI and the CRs are slow is visible (I'm visibly not doing anything), which means that we can work on it and improve! That's a basis of lean manufacturing: make problems visible. - We chase people to get reviews, so the lead time of each ticket significantly decrease. Also I'm automatically available to help people review my code (if it's a complex bit or it's a junior reviewing). - We take tickets to improve our CI and our testing perfs
All in all, doing one thing at a time was already more efficient, and in addition we can make our process more and more efficient.
The main pushback on this is generally "but we need to context-switch to review PRs", but in the end you do way more context switching when working on several things at once.