Strategies for Enhancing Communication and Training in Distributed Agile Teams Across Time Zones and restricted time
I’m currently serving as the Scrum Master for a distributed team developing a banking payment platform. Despite having a structured schedule with 90-minute planning sessions, 45-minute retrospectives and reviews, and daily 15-minute standups, within 2 week sprints, we struggle with maintaining a stable velocity, and each sprint ends with carryover. Our stakeholders are concerned about this inconsistency.
One of the causes of this carryover is that our product planning is subject to fixed dates on a product roadmap, which is first discussed with the business side and then with IT. The team has met almost all release deadlines, but often the work exceeds what can be completed within a sprint, leading to continued efforts to achieve the release. However, the business side desires a stable velocity for better predictability.
Coming from a background where I had ample time for workshops, live training sessions, and discussions on estimation, predictability, and Agile maturity, I now find it challenging to implement these in a remote setting with significant timezone differences. There's a lot of management against "distracting" the team from the work.
hould I consider recording sessions for asynchronous learning, or focus on one-on-one meetings to address specific needs? How can I foster better communication in a highly bureaucratic environment with timezone barriers and barriers to training and working on the processes and team culture?
Any insights or shared experiences would be greatly appreciated.
Are you meeting your Sprint Goals?
Instead of thinking about the work being finished or not finished, think about if the goals are being met. By doing the work to achieve the goal, you may find that some work is unnecessary and can not be done, and you may find that you've missed some work. The important thing isn't getting each piece of work done, but moving closer to the Product Goal by achieving the Sprint Goal and then getting actionable feedback from stakeholders on the remaining work and next steps.
we struggle with maintaining a stable velocity, and each sprint ends with carryover. Our stakeholders are concerned about this inconsistency.
Scrum.is about innovation, and learning to build the right thing at the right time. A Sprint is a learning experiment for that purpose, for which a Sprint Goal is formulated and which mitigates a significant risk or uncertainty.
There's no carryover in Scrum -- the concept does not exist. Any remaining work which has not been finished, for whatever reason, is re-estimated on the Product Backlog for possible consideration in future Sprint experiments.
Let the Developers monitor their own progress in terms of velocity and predictability. What stakeholders should be concerned about is not velocity, but the value they are getting each and every Sprint. That's where I suggest you start.
That's maybe a topic for another forum, but it's not consistent for the team to meet the sprint goal.
However, the current sprint goals are something like "Complete epics/features X, Y, and Z because they are planned for this month's release," "Achieve code complete for this Epic," "Reach QA Tested for Epics/features A and B."
Currently, we have a Product Roadmap with release dates that come from the business and stakeholders before being analyzed by the development and engineering team.
In fact, in many sprints, while the Sprint Goal is "Complete X or Y," the product team applies some pressure to "advance" another epic/feature since there is capacity. This phenomenon leads to WIP/Carryover between sprints.
It's been challenging for me to guide the team to focus on the goal, pivot with value and increment, and innovate. Tomorrow we have Review and Retrospective, and I'd like us to discuss what could have been different to achieve the sprint goal (which was to achieve Epic X, Y, and Z in Code Complete). But stakeholders and business are pressing and making noise to see velocity so they can use it as a forecasting tool.
And having QA Testing on another board, another sprint, with the DoD being Code Complete instead of delivering value into the hands of users and customers... that's another topic for another forum. I think it's a topic for another forum, but I'm sharing it with you.
Velocity is going to change between sprints for a number of reasons. Unforeseen complexity, people on leave etc. Also does the team estimate their own sprint capacity? It seems the sprint backlog is already decided by the "business" roadmap?
Just a bit on Distributed teams. As simple as it may sound, these teams need centralised communication mechanism, a MS Teams channel for example. Shared repository of knowledge; Confluence for example. Encourage the use of these. Encourage people working together, even pair programming to share knowledge. Encourage people to connect on overlapping time in different time zones between teams.
You never mention how you measure velocity. You do mention that it is used as a tool for forecasting. I suggest you read the book "When Will It Be Done" by Daniel S. Vacanti. You should also follow it up with the book Actionable Agile Metrics for Predictability by same author. They provide guidance on how to use metrics to such as cycle time, lead time, and throughput as tools in forecasting work. These books have been very useful for me and I have seen them mentioned many times in these forums (and not just by me). Read the books and then educate the stakeholders and business on how to interpret and use those metrics.
Insisting on not being able to meet up with Spint goal is something else and can be as a result of the following:
- Poor planning - tasks not estimated correctly or are not broken down correctly
- No clarity - either sprint goal is not well defined or not well understood by all team members
- Capacity/Resource issues - Team not at full capacity due to sickness, vacation,....
- Technical challenges - team not fully cross-functional
- Lack of motivation, ......
Note that many more points could be examined to find out why the team is unable to meet up with their Sprint goal. My advise will be to organize a fact finding workshop of what may have been the issue. And together with the team, come up with actionable items that you will include in your backlog.
Best regards,
Mathias.