Simulations reveal one’s default behavior. I have learned a lot about myself and my default settings when I have participated in simulations. (Shout out to AYE conference, PSL workshops, and many other excellent learning opportunities that have immersed me in uncomfortable, simulated project settings, enabling me to recognize and resolve personal dysfunctional traits that I was previously unaware of.)
Working within a distributed context can be challenging. Learning to cope with the physical separation and timezone differences is often a long, extended process wherein many lessons are learned the hard way. The Distributed Agile Simulation workshop simulates your distributed context so experienced coaches can observe your real-life situations unfold and provide specific feedback, coach on relevant distributed scaling structures, and demonstrably amplify your shift towards improved distributed product delivery. This is a 2-day custom workshop, wherein we do a deeper dive to unfold the many people, structure, and dynamic relationship aspects of your distributed delivery experience and provide you with relevant techniques, tools, and thinking models to navigate your product’s distributed delivery context.
During the Agile2012 conference in Dallas, Texas, Michael Tardiff and I facilitated a 3-hour Distributed Agile Simulation — a miniature version of the two-day workshop. We divided all participants into three roles:
- Builders: Those who contribute to planning and delivery of the project.
- Observers: Those who only reflect what they see, hear, and feel, and do not contribute towards building the project in any way. Maximum of 2 per team of builders.
- Managers: One per team of builders.
This group was further divided into four separate geographic locations — Seattle, Hollywood, Pune, and Hyderabad — and a timezone difference between the U.S. and India locations was simulated. We executed two full iterations under these conditions. This close-to-real-life simulation revealed many of the typical behavioral patterns, contrasts, and subcultures that we often see in real-world, scaled, distributed Agile delivery systems.
Many people who participated in the simulation expressed that it was realistic, and that it revealed to them how difficult scaled and distributed delivery can be. While there are no quick fixes for complex and dynamic human systems, in retrospect the debrief revealed what worked and what didn’t.
Process for processes sake?
At the start of the simulated iteration, the team in Seattle began crafting well-formed user stories with acceptance criteria, and struggled a lot. During the debrief they revealed how they abandoned user stories and started having high-bandwidth Skype conversations with other remote teams.
The team based in Hyderabad searched deeper and consciously abandoned user story writing since they were able to work out an agreement with their product owner that she would be available to provide the why and what aspects of any requirement, and be willing to negotiate the how with the team.
While one team was frustrated that their adherence to “best practices” of user stories did not work out, another team in the same simulated setting tailored aspects of a “good practice” –- user stories — to suit their context.
Managers – Who?
Manager meeting (black pinnies)
In the simulation, managers were assigned to each location, and almost all them at first struggled to find their function within an Agile context. While a couple sidelined themselves to inactivity and checking emails on their handhelds, the other two went above and beyond — one protected the team members, keeping the distributed telecommunication infrastructure up and running, while the other outdid everyone by demonstrating outstanding service to his team.
In the final debrief, the teams with dysfunctional managers viewed management as a roadblock, while the teams with serving and supporting managers viewed their managers as integral to their success.
Emergent Issue handling
Skype Box (green tape box) coordination meeting
Scrum of Scrums or similar late night coordination meetings to align work coordination between teams are common in a distributed context. During the simulation, a couple of teams had their representative stay online (on the Skype box) during all working hours to field emergent integration and coordination issues.
Such continuous attention to managing communications between distributed teams is crucial, and was an outcome of retrospectives from the first of the two iterations that the teams participated in.
Busy work –> Integration issues
A lot of work was completed by the end of two iterations — pages and pages of Web content. It was easy to see four distinct color schemes, four different layout patterns, and a hodgepodge of Web prototypes. With four different geographically-separated locations, the final product was pulled in four different directions.
This attention to busyness (local optimization) is often rampant in distributed contexts. Lacking a coherent mechanism to coordinate, throttle, and iterate on work produced by many locations often leads to an incoherent final product.
Scrum of Scrums, a coordinating mechanism between teams, is a scaling building block. But this simulation revealed that talk is cheap, often borne out in reality. Simple verbal communication is not enough — coordination around substance is also crucial. In real scaling situations, being able to merge, compile, unit test, and pass the full CI cycle every night/day with software from all distributed teams is the only validation of coherent product.
Observer Notes and Charts
Agile 2012 Distributed Agile simulation observers charts
Since our session at Agile 2012, many people have reached out to me for details around facilitating this session. Preparations for this are elaborate. If you are interested in facilitating this session or would like to amplify your team’s awareness and learning about their distributed context, please connect with me via email.
Finally, before I leave, I must thank my friend Tom Perry for his generous dedication of time, spirit, and energy.
This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 United States License.