Tips for Release Planning with Distributed Scrum
- Share
-
- |
Read later
Reading List
Rajesh Velliyatt has two moderately experienced Scrum teams, one in the US and another in India. He’s not able to get everyone on an audio/video conference bridge because of the time zone difference. Nor does he have the travel budget to fly one team to the other. So he asks how could one do release planning in that case?
Don MacIntyre suggests giving each team their own backlog and goal, just do their planning separately. The PO would meet with the remote team by coming in either early or late. However, he notes that face-to-face communications would be better while at start.
Vikrama Dhiman says he has seen the following things work well:
1. Minimize dependencies between teams - easier said than done, especially for legacy architectures
2. See if you can get some time overlap between India and US Teams [staff India teams appropriately]
3. Create channels for communication like Internal Wikis, Mailing Lists, Microblogs and make Sharing a Habit - including the smallest details like daily sprint burn down charts [photos of whiteboards etc.] and an internal podcasting/ video sharing [and recording] apps. Reiterate: Make Sharing a Habit across the board.
4. Keep teams at both sides stable. Do not chop and change frequently.
He also notes that with flex time and telecommuting these issues are not a problem only for offshored teams.
Ted St.Clair mentions that he faces the same problems. The teams have a single backlog and PO, work in one week sprints have a weekly backlog grooming session. The grooming session has participants from both the US and India along with the PO. The US team has one team member in India who also acts as their coordinator. Both this coordinator and the US ScrumMaster participate in the Indian planning and retrospectives. Finally during release planning they try to indentify Epics that can be worked on to completion by one team.
Based in his experience, Hubert Smits says it works best when each team has its own set of features, working mostly independently from each other. However he’s found it's still best to bring them together to discover dependencies and solve the problems they create.
In practice Eric Lefevre has found that web cams and video conference calls were just too cumbersome for his team to setup. As a result the teams stopped using them.
Personal Opinion: Aside from the obvious benefit of generating a plan, release planning serves other purposes: To build trust between team members (a real issue in new or distributed teams) and to build a common understanding. It's not clear to this reporter how any of these suggestions contribute to those to two points.
Previously on InfoQ: Case study: Distributed Scrum Project for Dutch Railways, Agile Distributed Development Done Right Using Fully Distributed Scrum and sPlanning and Maintaining the Rhythm of Distributed Scrum
Rate this Article
- Editor Review
- Chief Editor Action
Submit
Submit
Hello stranger!
You need to Register an InfoQ account or Login or login to post comments. But there's so much more behind being registered.Get the most out of the InfoQ experience.
Tell us what you think
Community comments
Distributed Scrumish
by
Kosala Nuwan Perera
Posted
Re: Distributed Scrumish
by
Dennis Gautreau
Posted
Distributed Scrumish
by
Kosala Nuwan Perera
I guess applying Scrum for a distributed development teams has become a very famous common problem now. I guess these approaches might have worked for their environments. However, I was in the same seat when I was working for a Swedish company few years back. There were 3 teams. out of those 3, 1 team was in Colombo, Sri Lanka. I was assigned to work with PO and SM at Sweden coordinating with dev team at Colombo. The main problems that dev team were having; getting clarifications and finishing story points within the given time period. We were always behind and there were a huge backlog items moved to next sprint at the end of each sprint.
In each retrospective we identified few problems and started adding different features we have in other models such as RUP, XP etc.
We already had a SM at Sweden, so very first we thought of appointing another SM at Colombo to make sure scrum happens in Colombo. And the team Colombo will do their scrum with Swedish PO, SM and I.
To speed up things and we decided to have a shadow developer. Few tasks were assigned for this developer and sometimes we did peep programming as well.
To share things, we started using whiteboardwiki as a scrum board and the Swedish SM sync their scrum board with whiteboardwiki. It was the same for the SM at Colombo.
We started using sketches, use case diagrams as well but none of these were softcopies or visio diagrams. We used a whiteboard and took a snap and emailed to Colombo team.
Skype conf was the official communication channel. It was always helpful to explain things the diagrams, sketches, for planning poker and retrospectives.
It did not solve all the problems but it did help both Swedish and Colombo teams to get things done.
In each retrospective we identified few problems and started adding different features we have in other models such as RUP, XP etc.
We already had a SM at Sweden, so very first we thought of appointing another SM at Colombo to make sure scrum happens in Colombo. And the team Colombo will do their scrum with Swedish PO, SM and I.
To speed up things and we decided to have a shadow developer. Few tasks were assigned for this developer and sometimes we did peep programming as well.
To share things, we started using whiteboardwiki as a scrum board and the Swedish SM sync their scrum board with whiteboardwiki. It was the same for the SM at Colombo.
We started using sketches, use case diagrams as well but none of these were softcopies or visio diagrams. We used a whiteboard and took a snap and emailed to Colombo team.
Skype conf was the official communication channel. It was always helpful to explain things the diagrams, sketches, for planning poker and retrospectives.
It did not solve all the problems but it did help both Swedish and Colombo teams to get things done.
Re: Distributed Scrumish
by
Dennis Gautreau
My organization has been working with Scrum practices for over two years now. We currently have 6 teams in the US and 3 in India. Each of the teams, their members and their Scrum Master are co-located. Product Owners are in the US. One thing that we implemented in India was the concept of a Proxy Product Owner. Their role is to
- meet with the US-Based Product Owner to get an understanding of the product backlog,
- meet with the co-located teams frequently as part of sprint planning
- raise any issues to the US-Based Product Owners that the Proxy can not handle
This reduced the need for daily interaction of US-based employees with India-based teams.
- meet with the US-Based Product Owner to get an understanding of the product backlog,
- meet with the co-located teams frequently as part of sprint planning
- raise any issues to the US-Based Product Owners that the Proxy can not handle
This reduced the need for daily interaction of US-based employees with India-based teams.
