V6 – Parallel Tasking
For some reason, as people start this exercise, they almost always do so with a single ball in play at a time. The Product Owner tosses the first ball to the first team member, who then tosses it to the second, who tosses to the third, etc…
If the product owner thinks of their role as 1) Sending a ball to the first person in the sequence, then 2) Receiving that ball from the last person in the sequence, then the Product Owner is constrained by the cycle time of the system. As shown in Figure V6.1, the cycle time for a single ball is 6 cycles.
Therefore, if the product owner waits until a cycle completes before putting another ball in play, then they would take 18 cycles to deliver 3 balls.
After the first couple tosses, what is the PO doing? What is the first team member doing? They’re watching and waiting. Idle. Since nobody in the sequence needs to ever handle the active ball again (except the PO, who will need to take it out of play), it is fair to say that each team member is idle, far more than they are acting.
Figure V6.2 brings the idle moments into sharper focus…
Think about it – each member of the exercise has only two actions, surrounded by waiting time. 1) Wait, 2) Receive a ball, 3) send the ball on, 4) Wait. What is stopping them from receiving/sending again? Nothing except the availability of another ball.
This pattern holds for everyone except for the Product Owner, who appears to 1) Send a ball, 2) Wait, 3) Receive a ball. And that’s all there is to it. Right? Maybe not.
Look at the transition between cycle 6 and 7, and also at the transition between 12 and 13. If you isolate those pairs of actions, the product owner has the exact same action structure as the rest of the team. 1) Receive the previous ball and 2) send the next ball out. Now the idle time doesn’t seem to make as much sense.
What if, instead of waiting until a ball completes the cycle to send the next ball, the PO instead sends a ball whenever their designated receiver is prepared to catch it? Team member 1 will receive a ball on cycle 1, then get rid of it on cycle 2, meaning that they could be ready for another one on cycle 3.
Now instead of 18 cycles to get 3 balls (delivered on cycle 6, 12, and 18), the new system will still take 6 cycles to produce the first ball, but new balls are delivered every other cycle after that until time expires! In the same 18 cycles, the team will have delivered 7 balls!
Reality Check: The perceived inefficiency of agile methods is that someone may be idle at some point in an iteration, and they’ll cite something like figure v6.2 as evidence of inefficiency. You now can counter with figure v6.3 to show that allowing the team to absorb work at their own pace produces superior throughput. And then you can show figure v6.4 to demonstrate that waste takes many forms. A team that has recognized its optimal velocity would know that they deliver 7 balls in an iteration, so the Product Owner should have prevented them from even working on the 8th and 9th ball… looking more like this:
