Some PMs wait until end-of-sprint to review and approve stories. This small behavioral pattern has an outsized impact on output for the engineering team.
Software manufacturing is manufacturing. And like any manufacturing process, if WIP (the manufacturing term for “work-in-progress”) builds up, it will constipate the process. Yes, that visual is appropriate.
For example, let’s say you manufacture custom racecars and only a dozen exit your labor-intensive manufacturing process each day. The exit criteria includes a QA review to make sure everything is perfect: no thumbprints in the paint, the engine runs smoothly, the electronics are working. If a car fails e.g. the electronics test, it is set aside and the electronics team comes to fix it.
Do you see the problems with this normal, logical approach to manufacturing QA?
- The electronics setup happened midway in the process. After that other components were added, like the dashboard, that are dependent on and covering up the previous work. It will be much more time consuming to fix the electronics now.
- The person that did the electronics setup has already moved on to working on the next car. For them to come look at the QA-rejected car, they need to stop their work on the current car in the process. Meanwhile cars before them will pile up, and the manufacturing step after them will go idle.
- If someone else troubleshoots the QA problem they will not be familiar with the details of that custom car. It will take them longer to identify the problem and they run a risk of fixing it poorly or introducing another error.
In general, the better solution would be to identify errors close to the relevant step rather than recycling finished product back into the process.
Let’s get back to software. The same issues arise with the common scenario where a PM reviews, accepts and rejects software stories near the end of sprint.
- The work may be obfuscated by other work that has been done on top. For example, a second story which adds a feature to the output of the first. Changing the first story will impact the second as well.
- That engineer moved on several days ago to working on a new story. The old story is no longer in their biological RAM because they are mentally deep in figuring out the new story. Asking them to revisit and tweak/change the old story code requires them to break flow and lose momentum on their current work, spend time to load context for the previous work, and then re-immerse in the interrupted project. Lots of switching cost.
- Reviewing at end of sprint likely means the team is also integrating and deploying at end of sprint, once the stories have been approved. A batch process like this often centralizes the deployment (and invariable troubleshooting!) to a senior engineer, who while senior was not the same person that initially wrote the code.
What is the overall impact of reviewing at end of sprint, instead of inline as work is done?
- Reduced output, because engineers have to break flow on their current work when old work is returned into the process
- Increased time to fix, because returning work has accumulated dependencies, or is being fixed by a different engineer
- Increased risk, because fixes will be done less-than-ideal in order to get the batch out the door
The solution? A simple behavioral change for PMs. Attempt to review stories within two hours, i.e. before starting the next batch of meetings. And have a firm SLA to review everything before end-of-day, so that you can use a late evening to catch up if necessary. No days should begin with a story up for review.
While simple, the decision to review inline versus at the end of the sprint will do wonders to un-constipate your software manufacturing workflow.