Having a Ball – Variant 6 : Parallel Tasking

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.1 illustrates delivery cycles when the team sends out one ball at a time. Assuming the iteration is limited to 18 cycles, only three balls will be delivered in the iteration.

Figure V6.2 brings the idle moments into sharper focus…

Figure V6.2 – That’s a lot of idle time!

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.

Figure V6.3 – Keeping everyone busy…

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!

Figure V6.4 shows this pattern carried on until cycle 18. If we stop the simulation at this point then 7 balls are delivered. There is one troubling aspect to this scenario. Note that energy is expended on passing Balls 8 and 9 into the system when there are not enough cycles remaining to achieve delivery.

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:

Figure V6.5 – If the team knows their limitations, the PO would have only set aside 7 balls for them to work on.

Author: Michael Marchi

Michael Marchi CSM, CSPO, SA4 Co-Founder and Board Member @ APLN Chicago (michael.marchi@aplnchicago.org) Manager, Management Consulting / Chicago Agile Practice Lead / Agile Coach & Trainer @ Strive Consulting (mmarchi@striveconsulting.com)