Agile emphasises the importance of co-located cross-functional teams. Cross-functionality is important as we want teams to be as independent as possible which often requires the utilisation of the full experience and knowledge of the group. Co-location helps unlock the cross-functional expertise across the team to increase speed and improve the quality of work. As an Agile coach, I typically advise against breaking a team into groups which become sub-teams, creating mini-silos. The reason for this is that all the delays, misunderstandings and lost opportunities that come from work spread across different teams become replicated within the team on a smaller scale.

When team members are not co-located or working the same hours we have to acknowledge there are trade-offs. In this case, the frustration of not being able to contribute value outweighs the downside of working independently within the team. Breaking the work up, to specifically enable task assignment to individuals or groups based location and working hours, empowers people to work with a degree of independence resulting in getting more done.

Redesigning the work for people

The individual worker

This person may work different hours for flexibility, be in the same city or a different country but not frequently in the same office. This kind of worker can effectively contribute through:

• Reviewing work – often the ability to not have the interruptions that come with working in a dynamic team space provides the opportunity to read thoughtfully. Not being part of the creation process for a piece of work, enables fresh insights which test the concepts in a new way.

• Documentation or calculation – separation from the core team, can sometimes help with work where concentration is more important than collaboration and can result in faster turn around of iterations for review by team members and stakeholders.

• Follow the sun – people working later in the day can often pick up urgent work, enabling the team to progress more work in each 24-hour cycle.

The split team

Sometimes teams are located by skill set. Allocation of work where most, but not all the skills exist at a location, often provides the opportunity for team members to develop more T shaped skills, the broader knowledge (the broad top of the T) to complement their speciality knowledge (the narrow vertical part of the T). Peer review of work by swapping between locations can help teams stay aligned but be realistic of the physical separation.

The remote product owner

A typical scenario is for Product Owners to sit with the team stakeholders, rather than the team. The Product Owner is an integral part of the overall team and is accountable for their own work to propel the team forward. This output takes the form of a prioritised backlog of Epics, Features and User Stories. The highest priority work should be refined with clear descriptions of who the work is for, what the need is and why that is important. Additional to this, there should be a description explaining the elements which would make it complete:

• Plan to plan – Agile models detail a Product Owner responsibilities to include interpreting the needs of the business into a prioritised work backlog. This description can lead people to believe that there is little difference between collocated and remote Product Owners. In practice, it represents a change from informal and continual work design to a more structured approach. An effective remote Product Owner has a plan on how they will gain feedback from the team to inform the work they prioritise. 
• Redesign the work rhythm – A collocated Product Owner absorbs and shares information with the team almost seamlessly through ongoing conversation, ensuring that everyone enters planning sessions with a clear understanding of the work to be discussed. A remote product owner will need to introduce enough structure to let people be prepared for planning discussions, mitigating the absence of the side conversations. Achieving this may involve creating a rhythm where they have regular discussions with team members to test their ideas about what is possible and gain information about dependencies, technical debt and unrealised opportunities. It would not be unreasonable for a team to ask the product owner to have frequent check-ins to test the direction of the work throughout the sprint.
• Clear expecations – Being remote increases the importance of having clear expectations of any help the Product Owner is looking for to build the backlog, and any information the team may need while doing their work.