Simulations reveal ones 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 may other excellent learning opportunities that have immersed me in uncomfortable simulated project settings that have enabled me to recognize and resolve personal dysfunctional traits that I was previously unaware of.
During the Agile 2012 conference in Dallas Texas, Michael Tardiff and I facilitated a full 3 hour Distributed Agile Simulation. At the conference we facilitated this 3 hour miniature version of a two day workshop on Distributed Agile delivery.
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 learnt the hard way. The Distributed Agile Simulation workshops simulates your distributed context so that the experienced coaches 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 the 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 products distributed delivery context.
For the Agile 2012 Conference simulation, we divided all participants into three roles.
- Builders – Those who contribute in planning and delivery of the project.
- Observers – Those who only reflect what they see, hear & 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. Finally a timezone difference between US and India locations was simulated.
Under these conditions we executed two full iterations
This close to real life simulation revealed many of the typical behavioral patterns, contrasts and sub-cultures that we often see in real world scaled distributed agile delivery systems.
Many people that participated in the simulation expressed that this simulation was realistic and 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 location began crafting well-formed user stories with acceptance criteria and struggled a lot. During the de-brief they revealed how they abandoned user stories and started having high bandwidth “skype” conversations with other remote teams.
Another team based in Hyderabad, searched deeper and consciously abandoned user story writing since they were able to work out with their product owner an agreement that she would be available to provide why and what aspects of any requirement and be willing to negotiate the how with the teams.
While one team was frustrated that their adherence to “best practice” 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?
In the simulation, managers were assigned to each location and almost all the managers at first struggled to find their function within an agile context. Where a couple sidelined themselves to inactivity and checking emails on their handhelds, the other two out shined in their service to the teams. One protected the team members, maintained distributed telecommunication infrastructure up and running, while the other outdid everyone demonstrating outstanding service to his team.
In the final debrief, the teams with dysfunctional managers viewed management as a roadblock and the teams with serving and supporting managers viewed their managers as integral part of their success.
Emergent Issue handling
Scrum of scrums or a similar late night coordination meetings are common in distributed context to align work coordination between teams. During the simulation a couple of teams had their representative stay online ( in the skype box ) during all working hours to field emergent integration and coordination issues.
Such continuous attention to manage communications between distributed teams is crucial and was an outcome of retrospective from the first of the two iterations that the teams participated in.
Busy work –> Integration issues
At the end of two iterations a lot of work was completed. So many pages and pages of web content, And it was easy to see four distinct color schemes and four different layout patterns and a hodgepodge of web prototype. With four different geographically separated locations, the product final product was pulled in four different directions.
This attention to busyness (local optimization) is so often rampant in distributed contexts. Lacking a coherent mechanism to coordinate, throttle and iterate on work produced by many locations often leads to 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. Simply verbal communication is not enough, coordination around substance is also crucial. In real scaling situations being able to merge and compile and unit test and passing the full CI cycle every night/day with software from all distributed teams is the only validation of coherent product.
Observer Notes and Charts
Many people since our session at Agile 2012, have reached out to me for details around facilitating this session. Preparations for facilitating this workshop are elaborate and it is best to leave details and aspects out of this blog entry.
Finally, before I leave, I must thank my friend Tom Perry for his generous dedication of time, spirit and energy.