Fully Distributed Scrum: The Role of Local Scrum Meetings
Posted by Jai on June 2, 2009
This post cover the role of local scrum meetings in a fully distributed scrum. You don’t want to turn fully distributed scrum, the single team concept to the scrum of scrums by rigorously following the scrum meetings. Here we will see where each of the scrum meetings help you to have the local version and do where it fits you best.
It is always a challenge to make it work. Some time back Jeff and Guido covered the topic Fully Distributed Scrum: The Secret Sauce for Hyperproductive Outsourced Development Teams, have a look at the presentation based on the prorail case study.
In case of Distributed scrum of scrums the teams more or less remain separated out and that is where the fully distributed scrum plays bigger role. The communication from single point of contact moves to whole team. In case of Distributed scrum of scrums the teams do their own scrum meetings but in case of fully distributed scrum, it acts as single team.
In case of distributed teams, the time difference is the biggest challenge. There may be cases when you have no overlapping time (like US & IN) or half the overlapping time (like Europe & IN). Some time back I did a write up on Sprint in Action: Typical vs Distributed Team that how a typical sprint looks like in case of distributed teams and how you can make it work more effectively.
If you have already gone through the above presentation, you don’t want to have scrum of scrums and would definitely try the fully distributed scrums. But the problem is that due to all the time difference issues you still want to local team to go ahead with the work with out any delay or impediments.
Local Scrum Meetings:
You do the scrum meetings only with the local team to make it work more effectively. You don’t want to turn up fully distributed scrum into scrum of scrums. But still adopt what works and help the team. Lets have a look at how the local scrum meetings can help you and what role each play in day to day work.
Local Stand up: To get the kick start, start the day with the local stand up. Do discuss the progress and any impediments with the team and if any local team member can help to resolve it. If there are multiple teams, you can plan for combined local stand up to resolve dependent user stories etc. but do keep in mind to keep the whole meeting short.
For teams with some overlapping time period, have local stand up first and then distributed stand up with the rest of the team.
For teams with no overlapping time period, share the pain and on rotation basis from both sides figure out some common time. One side have local stand up and other merge it with the distributed stand up.
Watch out: The local stand up are not substitute for the distributed stand up. Do have the distributed stand up regularly.
Local Planning Meetings: To take the things a bit pro-actively and to over come the time difference issues the local team start having the local planning meetings. The on-site team talks to the product owner and comes with the initial list and the local team does the initial planning of the items for the next sprint during the current sprint only.
Some teams use wiki for this purpose for the initial discussions on the user story and update the initial estimates and then whole team sit together to do full sprint planning meeting. This approach help the team to minimize the time lost in sprint transition and to over come the time difference issues to tackle it more effectively.
Watch out: The local planning meetings are not replacement of the full team planning meeting. When you have full team together you have better idea of things and help in estimations also. Use this meeting to pro-actively eliminate waste and to minimize the time spend on irrelevant discussions in full team meeting.
Local Retrospective: Some issues are related to local team only and the team needs some forum to focus and resolve such issues. Some times in full scrum retrospective these issues are forgotten or given less priority because these are not of much relevance to team on other side. Having local retrospective can help to overcome such issues and can help the team to handle in a more formal way.
ShriKant Vashishtha, mentioned in Augmented Distributed Agile Teams – The Need of Local Retrospective that how it worked for their team to resolve local issues more effectively by having these local retrospectives.
We realized that having local retrospective helped the team a lot as we could focus on many local points of improvements like “how to gain domain knowledge quickly, how to improve on pair switching etc” which otherwise wouldn’t have been possible and could have lost somewhere.
I am still a bit skeptical about this,
Why do you need it?
local team issues: The team have some local issues which needs to be addressed.
to impress team on the other side: The local team come together to impress the team on the other side to prove that the distributed development work.
to impress the client: If the client is part of the team, you keep local issues hidden and not to expose to the client.
Watch out: Well and good if it works for your team. But I would still suggest to be more careful about this as it should not lead to team-up of local team on issues. Having whole team together can give you broader picture and new ideas.
Local sprint demo: This does not fall exactly in the sprint demo category and is not applicable to all scrum teams but sometime it happens that on-site team is more dedicated on lets say fixing production issues because they have direct access to client or may be few other reasons also. And the local team is working on the new user stories. Having local sprint demo help you to continue with the sprint and to get the team on other side to get up to the speed on new user stories.
Apart from these typical meetings there are many more general meeting which you can have on both the sides in distributed scrum and share the mom with the team on the other side.
Local Design Discussions: Have initial discussion on one side and share it with team on other side
Local Knowledge Sharing Sessions: Have these sessions to share knowledge among all if not adequate with pair programming.
Feel free to share your experiences on handling or working with fully distributed scrum teams.