In the mid 80’s and early 90’s when Information technology revolution started in India, IT engineer were providing service to a vendor in North America, Europe, etc. During this period, we use to see team providing services located across multiple geographical locations on the globe.
Whether we were using Waterfall model, PRINCE 2, ITIL, Agile Software Development, Scrum, Kanban, Scrumban, XP etc. process/mythologies/frameworks for software development or software services we all were used to work in distributed team. Except few, who were lucky to have collocated teams.
Irrespective of the process or methodologies used for software development, planning was/is a challenge for team locations across geographical locations. My intention is not to find out why these teams are located across locations on this planet.
My intention is to share my learning. Hence, the title “SPRINT PLANNING IN DISTRIBUTED SCRUM TEAM”.
In the end of 2013 and early 2014, the product I was working was merged in to a single team. Prior to that, development was separate team and sustaining was a separate team. Team was excited to hear about the team merger decisions made by senior management of business unit. Excited!! Because whole team will work on development and Level 3 Customer Support work. More excited!! Because development team is following scrum for software development. Scrum team is a distributed team. Members are in Baroda, Bangalore, Boston, Florida, New York.
In 2015, I was lucky enough to take Scrum Master role of the team.
Every aspect of scrum was/is a challenge with distributed team. Especially Sprint Planning. And being Scrum Master of a distributed team is another big challenge to me, personally. I am sure, many of us felt this!! (Scrum Masters do you agree? J J)
How I Resolved: Being facilitator of sprint planning meeting I/You (as a Scrum Master) need to make sure the timing of the meeting doesn’t conflict with other meetings, timing of the meeting should work for whole team and for stakeholders (If they are attending planning. Sprint planning meeting and its cadence is very important to have an effective planning meeting.
For my scrum team, we as a team has chosen evening time in India. This helps members in North America and India. We choose to meeting 4:45pm IST twice in a week. 4:45pm?? Little odd, right? This works for team to avoid conflicting meetings. Recurring meeting invites for whole year are sent out to team. This is another important aspect. This helps team to follow the flow.
How I Resolved: During early planning meetings, it used to be chaotic!! Multiple people speaking at same time, many people giving their views on the story, unable to hear due to technical problems in the conference equipment, diverting from the topic, etc. This was, The Most Challenge. Everyone in the team, management, stakeholders, PO all felt planning meeting wasn’t productive. I used to be stressed out after planning meetings.
Then I worked with my then then Agile Coach (not official title in company) Nilesh Kulkarni . We have taken multiple steps to bring this in order.
Step 1: Pre-defined agenda. Agenda of the planning meeting should be shared with distributed team at least one day in advance. I followed below format.
|Feature ID||Feature Title||Owner||Comments|
This helped team to do high level review of the feature before attending the planning meeting. My team is a R21 team.
Step 2: Ownership. Once the story or feature(s) is understood by the team, someone in the team does the technical and functional research prior to the planning meeting and share their research in the planning meeting. As and when writing this article, we are still follows this.
Step 3: Small group discussions. Small group discussion is always productive. The moment I as Scrum Master see that the discussion of story or features is going beyond time box, discussion is helping team or when all team members are not on same page, then we as a team make a consensus decision to refer to this to small group within scrum team. Then the small group will discuss offline and bring it on to table. By reading this, I know you might be wondering that as per Scrum guide “Scrum recognizes no sub-teams in the Development Team”2. But, this Step was required for my scrum team to be productive. And my scrum like this very much.
I am very excited while writing all this. If you think this is boring, I assume few tips for Scrum Master(s), for people who aspire to be Scrum Master will be helpful.
Even if 80% of the team is active in the planning meeting, I would rate it as successful planning meeting.
Find out what works for your team and do your sprint planning accordingly.
I would like to end this article with a quote by Eisenhower “Plans are worthless, but planning is everything”.