Pragmatic Agile Process for Distributed / Mixed Teams
As organizations are going global, onsite-offshore team mix is becoming the norm. The usual plain vanilla agile process does not work when multiple scrum teams are geographically spread with time difference to boot. For instance, given the time/geo difference, members who usually attend a ceremony like daily standup cannot do so.
Over the course of executing multiple such mixed team projects, we have settled on a customized agile process that works well. This defines in fine granularity
– the roles and responsibilities of onshore, offshore team
– day by day milestone of the sprint cycle
– new perspective on the sprint ceremonies and who should attend what
– a git flow with integrated CI/CD to support this
We do further customize this model for each project. Here is a representative agile process for a team of 20+ offshore resources and 30+ onsite, split into 4 scrum teams.
We have typically 2-4 week of sprint cycle. Even within every sprint cycle, stories with complex story points are split into simpler ones.
Backlog grooming achieves 3 things:
– flushing out of the functionality and making sure everybody including dev and QA understands the requirement. If this is not well,team will build something different than what the business expected. As Yogi Berra once famously said
“If you don't know where you are going, you'll end up someplace else.”
– priority of the stories by product owner
– rough estimation (Tshirt sizing) of the stories. This helps for relative prioritization of tasks with cost benefit analysis
The above should not be attempted in the backlog grooming meeting. Both product team and tech team should use the preparation week to decorate the stories. The grooming meeting is only for quickly reviewing and fixing relative priority.
Once this is done, sprint planning is just a matter of de-queuing stories from the head of the queue to fit the velocity of the team. If the team can handle 40 story point, just de-queue 40 story points worth.
Goal should be to keep the backlog queue atleast a couple of sprints ahead.
(How does the ceremony work?)
Offshore team does the Technical specification during the later phase of sprint cycle when the development tasks for the sprint is completed.
Guidelines for story-point estimation
Clear guidelines for story point estimation is laid out and agreed upon between the Client team and Offshore team. The number of story points to be completed for each sprint cycle is agreed upon between both the teams before starting the sprint cycle.
Based on the story-point estimation guideline, the sprint tasks are estimated and added to the sprint backlog.
Review of Technical Specification
Completed technical specification is sent to technical team at the client end for review. For clients who do not have a technical team, offshore technical lead does the review and technical specifications is added to the Sprint backlog post review. Incase of any review comments, the technical specification is sent for corrections.
Product owner, Client Lead and Onsite Lead do the Sprint planning. Story points are assigned for the prioritized tasks and added to the sprint cycle and assigned to the team. We use Jira for tracking most of our agile projects.
Most of the development work is completed in the first-half of the sprint cycle and sent to QA for testing. The second-half of the sprint will be pre-dominantly used for Technical specification and correcting the defects reported by the QA team.
Daily Scrum Meeting
10-15 minute stand-up meeting is held on all days of the sprint cycle. The scrum master updates the meeting details in Jira which can be viewed by the client at any point of time. For client not participating in the daily scrum meetings, we have a weekly status call.
Test plan preparation
While the development team is coding, the QA team will complete the test plan in parallel.
Test plan review
The test plan prepared by the offshore QA team is sent to the client end for approval before starting the testing.
Jenkins is used for continuous integration. The code freeze day is fixed and happens two days before the sprint cycle for the tasks approved by QA. In case of any sprint task that does not undergo QA approval, the task is pushed back to the sprint backlog and discussed as part of next sprint planning and sprint retrospective meeting.
Code Merge and Push to production
For clients having technical team, they do the second-level of code review, code merge and push to production. For clients not having technical team of their own, offshore team does the code merge and production push upon getting the client’s approval after UAT.
Sprint Demo & Sprint Retrospective
Sprint Demo happens on the last day of the Sprint Cycle followed by the Sprint retrospective meeting. All the stakeholders – product owner, Client lead, onsite team, offshore team, QA team are involved in the sprint retrospective meeting. The retrospective meeting helps the team to brainstorm on what went well and what need to be improved based on the completed sprint cycle.