Enterprises are becoming more distributed as technology facilitates global collaboration. People start working from home and projects are distributed over different locations. To orchestrate the work, across locations, agile principles help. Interaction between team members and stakeholders are frequent and based on patterns. The stakeholders, users or customers are close to the development teams. Organizations create roles, events and artifacts according to the scrum framework. But it's not always easy to decide what role to place on what location or how to coordinate events with people in different time zones. Not seeing each other in an office creates challenges in alignment. It's also not necessarily visible how each team (member) is performing. The following questions can be asked on the organizational level:

Questions

• What software development framework(s) do we adopt? (scrum, LeSS, Kanban, SAFe, etc)
• How do we modify the framework to fit our distributed setup?
  • Roles: what role where? (e.g. proxy product owner)
  • Events: what's different in the events we organize? (e.g. video recording if timezone difference doesn't provide overlap)
  • Tools: what tools support the framework distributedly? (e.g. JIRA versus sticky board)
• Do we create dispersed teams (everyone remote or split teams) or collocated teams?
• How do we measure success? What are our kpi's?
• How do we share knowledge effectively across all team members?
• How do we share product vision, roadmap, user feedback?
• How do we align on strategic, tactical and operational level if we work in partnerships?

One of the main challenges in distributed agile teams is the availability of the product owner and the stakeholders. Teams are often in the dark, because they are not available. Product people are among the most busy in every organization. They need to balance their time between development teams, stakeholders and management. They are often part of multiple product teams. Teams that are collocated with product owners have a higher chance of interacting with them. But a remote team lacks that opportunity. What's more, remote teams hardly speak to users of the software they create. They don't have access to product vision, roadmap and related plans. Hence, they have no 'emotional bond' with the product they make and this influences motivation and quality. Organizations need to think through the distribution of key roles and the way development teams can engage with users and stakeholders. We also need to think how to share knowledge and product information throughout the distributed organization.

To create productive distributed organizations, the following virtues help.

Virtues

• Agility: keeping an open mind in respect to models; avoid bureaucracy
• Self organization: let teams figure out stuff
• Collocated teams are simpler
• Direct access to stakeholders: avoid the middle man (a product owner facilitates team-user interaction instead of being 'in between', no team leads, no hierarchy)
• wiki is key; sharing knowledge, visions, feedback using the right tools
• Cross-functional teams at different locations
• Aligned agile transformation vision at different locations
• Kaizen instead of Kaikaku

Applying these virtues to the 'being in the dark' example described above: we can use agile principles to organize. Instead of creating strict rules and reporting systems, we move authority to teams. Through retrospectives, teams can find what blocks them. Empowered, self organized teams can openly communicate those blocks to product owners and stakeholders. Through good product ownership and iterative improvement, teams will find ways to share product information, roadmaps and user feedback.

Business people and developers collaborate on a daily basis. This avoids the product-owner-becoming-middle-man problem. Using video conferencing software or collocation, developers can interact with the users and stakeholders. It helps if organizations stimulate teams to use wiki-like tools. Making those freely available, it becomes easier to share product visions, roadmaps and related documents.

Another key organizational area to be aware of in distributed Agile is not trying to do too much too fast. In Japanese this is known as Kaikaku or radical change. This may mean upending all of your teams and changing all of their job titles and roles just to try and fit into an Agile framework. This can often cause change fatigue in your organization and prevent teams from being effective, and rather trapping them in a constant cycle of "forming" and "storming" (teams typically go through a cycle of forming, storming, norming and performing - the preference is to be in the norming and performing as much as possible).

In a recent case John is familiar with a large bank tried to adopt Agile across its locations using a kaikaku approach. Renaming all of their managers to Agile coaches (though they knew little or nothing about Agile), and making many other large and traumatic changes in one fell swoop. While the bank initially felt that they were making great progress with Scrum, it was a matter of about 18 months before the organization and teams hit the wall in terms of change fatigue. After that significant resistance to the change became apparent and forced the bank to significantly roll back the aggressive pace of its changes. The bank thereafter moved to a healthier kaizen (continuous improvement) pace in its adoption of enterprise Agile. As far as John knows this has been much more sustainable in the bank and continues today.

A recommended approach is rather to try and use a kaizen (continuous improvement) approach to changes. Rather than attempting to change everyone's role and title in the organization make small incremental changes that improve the distributed Agile team as you go. Your team's will appreciate this, and it shows respect for people (a frequent pillar in the"Lean Thinking House"). As a general rule of thumb the primary scenario where Kaikaku or revolutionary change is effective may be in a new organization or start-up where there is no or very limited organizational "baggage" to deal with