Tips for Release Planning with Distributed Scrum

Posted by Mark Levison on Oct 20, 2010

Sections

Process & Practices

Topics

Agile in the Enterprise ,

Teamwork ,

Scrum ,

Agile ,

Distributed Team

Share |

RELATED Research

 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

RelatedVendorContent

The Agile Tester

Agile Maturity Model Applied to Building and Releasing Software

Agile Practices to Improve Project Management Organization (PMO) Effectiveness

Improving Software Delivery Cycles: Pre-requisites and Inhibitors

Branching & Merging Efficiently: A Guide to Using Process-Based Promotional Patterns

Related Sponsor

In today’s hyper-competitive world, later may be too late to adopt Agile development and this Roadmap for Success will help you get started. Download "Agile Development: A Manager's Roadmap for Success" now!

1. Back to top

   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.

   Reply

2. Back to top

   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.

   Reply