Retrospective Timings :
To be effective and timely, distributed teams should call joint retrospectives as soon as possible after having their own team meeting. Depending on the no. of teams involved in a joint retrospective, teams may want to limit the number of participants from each Scrum Team to keep the meeting productive.
- Team Composition – Teams >=9 people should consider geographic closeness and proper distribution of skills as well as team size so as to build self-organizing teams
- First level of Sprint Planning – The PO, SM will use a screen-sharing tool to display the vision, sprint goal, user story, the estimates the team provided, and the acceptance conditions for the user story.
- Answering the 3 questions: Team members should communicate information that brings value to others on the team. They should also try to identify team members that can help them resolve their issues.
- Documentation helps to Overcome Distance: Because of language barriers, distributed teams often need more written documentation than collocated teams. Another approach is to record the demonstration before the meeting to allow the developers to create the recording at their own pace in the language of the meeting or to have a fluent speaker speak over the recorded demonstration.
- Hold Joint Retrospective – The Distributed Teams working together will conduct their individual
- Sprint retrospectives at the end of each Sprint and then will conduct a joint retrospective.
- The benefit of this approach is that it promotes communication between the various teams involved in a project
- Individual Scrum Teams should aim to have the lowest distribution level possible encouraging feature teams over component teams.
Dealing with Incomplete Stories
The PO takes the impact of dependencies into consideration when reprioritizing the Product Backlog due to work the team did not complete during the Sprint, highlighted in Scrum of scrum Coordinating the Team on a Daily Basis – Priorities can change daily. The Daily Scrum meeting provides a daily synchronization point for the team and allows them to revise their plans regularly. Using the Right Tools : In a distributed environment, tools and good practices can help team members communicate more effectively, but it is more important to make sure the tools the team introduces will help them get the job done.
Scheduling for Teams with Overlapping Work Hours – Make sure all team members of distributed team, regardless of the time zone, can complete their work and prepare for the demo within overlapping work hours.
Larger Retrospectives
Distributed team members can reflect and comment on release quality and capability. The team talks about the project, and then defines and records the various milestones within the project to improve on or continue in future releases.
Enterprise planning tools for distributed team members, PO & SM to develop more than one feature to address a single solution so as to disaggregate the higher-priority features into user stories that can fit within a Sprint.
Checking Estimates from Preplanning Teams
In scaled environments where teams send representatives to help with preplanning, it is important
the teams who are going to be doing the work revisit the estimates
Committing to the Team
Team members are making a verbal commitment to their team when they state what they are going to do today, creating an opportunity for the rest of the team to confirm they met their commitments yesterday.
Valuing the Whole Team
SM should focus on an “us” versus “them” attitude in the distributed team, due to more delays in communications & fewer opportunities to work together Scheduling for Teams with No Overlapping Work Hours.
Alternate meeting time
The distributed team holds one Sprint Review meeting during the normal workday for part of the Scrum Team and holds the other Sprint Review meeting during the normal work hours of the other part of the Scrum Team.
Building Trust
SM needs to develop a sense of trust and honesty with one another, which in turn will lead to a wider degree of openness.
- Single Backlog for Multiple teams – The different skill sets in the team needs to deliver user stories that are available across each distributed location
- Separate Backlog for Multiple teams – The Scrum teams work independently from one another and have their own individual Sprint backlogs, but the Sprint dates are the same marking their interdependencies and risks in the Sprint preplanning sessions or in a Daily Scrum of Scrums.
- Reviewing Changes Based on Stakeholder Feedback – The team would review changes made since the preplanning meeting, and the PO would confirm the priorities of the Product backlog.
- Verifying Progress – Tasks not opening and closing regularly are an early sign the team may be going off track. Team members not showing regular progress may be facing outside distractions the SM should reduce or remove.
- Transparency – Distributed agile teams should use project management tool to identify tasks that are open, in progress, and completed so everyone is aware of the current status.
More on the Sprint Review and Conclusion next!
Ideas on Managing Distributed Teams Using Agile [2/3] – The Retrospective