Even when managers try to create cross-functional teams, the teams still have dependencies. Dependencies slow and make finishing the work more difficult. Too many teams have a built-in dependency creator—code review. When we take time to perform code review after we write the code (or the tests), we create dependencies between the people on the team. Instead, we can consider a more holistic approach to code review and abolish those dependencies.
Here's what happens with code review (see the image):
We have a cross-functional team, Jane, Peter, and Tim, along with a product owner, Allan. Jane and Peter are developers, Tim is a tester.
Person 1, Jane, “finishes” the story. But because code review doesn't occur with the code writing, Jane has to wait for Person 2, Peter. Peter is busy with his own work, so he waits until the next day to review that code. Luckily, he doesn't find anything wrong. Now, Peter can tell Tim, Person 3, that code is ready for test. But Peter can't get to it until the following day. Luckily, he doesn't find anything either. Allan is busy when Tim says the story is done, but 20 minutes later, Allan marks the story as done.
Notice how little time the team spent working on this story: just 5.3 hours. And, notice how much time the team spent waiting for each other: 72 hours.
The team spent most of its time waiting for each other—interdependencies.
But, you say, these people are working on new stories. Yes, they are. That's one of the reasons Tim is not yet available. He's still working on tests for the stories from the last sprint. While the team marked them all as “done,” they weren't really.
Some Choices for Inside the Team Dependencies
Instead of treating people as individuals (resource efficiency thinking), what if you looked at the team as a harmonic whole? In that case, you might have at least three choices for managing these inside-the-team dependencies:
- Pair on all the work. Pairing offers continual code review. You'll still have test dependencies, but you'll eliminate the development dependencies.
- Mob on all the work. Mobbing also offers continual code review, with the added benefit that the team will integrate the tests with the code.
- You might dedicate time each day to code review. For example, every day, at 2pm, the team reviews all the code that is ready to review. You might even have a guideline that any code over two days old gets a code review, because the person working on that code might not realize they're confused.
The question to ask is:
How can we reduce our wait time on all our work, so we don't interrupt ourselves with dependencies?
If your team and organization are willing to go beyond resource efficiency to flow efficiency, you can probably develop your own alternatived/
If you want to see a cool animation of this problem, see Dragan Stepanovic's Two Parallel Universes. He also includes problem reports.
The Series
The series so far (which arose from A Common Tool Trap: the Tool Will Help Your Delivery and Planning Problems):
Pingback: Dew Drop – February 24, 2022 (#3629) – Morning Dew by Alvin Ashcraft