An interesting side effect of doing more ensemble programming — you find yourself waiting less. Also, the people that are not in the ensemble find themselves waiting more. Especially if they need someone who happens to be in the ensemble.
Why is this a good thing?
It uncovers incorrect thinking about how your team(s) are organized. This is a balancing act — being able to produce value (doing) balanced against growing your capacity to produce value (learning).
When everybody has their own task in an area that is unfamiliar they are guaranteed to have time waiting. Waiting for help from someone else, or for clarity about what a customer may want, etc. And waiting is the enemy when you want to deliver value as quickly as possible.
So, if everybody you need is right with you all the time, there is no waiting. You are able to deliver what is needed immediately.
On the flip side, if someone needs something from someone in the ensemble, their wait time necessarily increases. You can’t rely on everyone having lots of wait time so you can distract them with your need. This local optimization can cause social pressure on folks in the ensemble, either to constantly be interrupted or to abort the experiment entirely, not realizing that the fault isn’t with them but with the system that contains them.
Therefore, while it is good to practice programming in an ensemble, there must also be time reflecting on how to adapt your structure and practices to your new reality. This means that everybody involved, those experimenting with ensemble programming and those who aren’t quite on board with the idea, must cocreate a reality where everybody’s needs are met.
This might be a periodic meeting where everybody promises to be available to everybody else to get them “unstuck.” It could be a rotating role of “interrupt handler” on a team that rotates — someone who isn’t tied into the ensemble and who protects them from distractions while helping those outside get moving again. Even having mini conferences a couple times a year would also break up the delivery mindset and create intensive learning opportunities.
At the team-of-teams level, it can also be useful to notice which teams tend to wait on which other teams. More waiting in one direction can imply that there are imbalances in knowledge and/or authority. If the whole tribe is more dynamic and allows people to move around more freely (ideally with consent), this can also alleviate the waiting.
The point here is — it’s easy to focus on all the benefits of being in an ensemble. But that doesn’t obviate the need to work on how all the ensembles and individuals interrelate to create a more cohesive delivery system. And that requires intentionality as well as high level coordination between teams.
As the focus time increases, the intensity increases. When the intensity increases too much for the rest of the system, it can experience strain. Rather than giving up on ensemble programming altogether, it behooves those who work “on” the system to create the mechanisms to relieve that strain while allowing everyone to work at their maximum comfortable intensity.
When you can do that, everybody benefits.