Wellness For You Inc. is a leading Healthcare solutions provider headquartered in Cambridge, MA with development teams divided between Cambridge and Pune. Their flagship product has most of the development and all of QA happen with a 10-member team in India and some development with 2 developers based in Cambridge. While the QA team does the QA for development happening in India, they are also responsible for final integration and end-to-end testing for work done by the two developers in the US.
One of the problems that this team has run into since they moved to Agile 4 months ago has been their unpredictability to deliver on commitments made in a sprint. As a result, stories have got carried forward from one sprint to the next with testing invariably as the pending activity in most cases. They have also found that the US developers invariably deliver their code on the last one or two days of the sprint and the QA team in India is left with insufficient time to test and qualify the code developed. To add to this, the team has also found at times, mid-sprint changes in scope of stories or occasional new stories which the PO believes are crucial for the product deployment. All of this has invariably led to wild fluctuations in velocity of the team – sometimes the team delivers as low as 7 or 8 points while in some of the other sprints, they deliver 30 to 35 points. The Product Owner and Product Manager are at their wits end to figure out how to make a commitment to the end users on what will go in an upcoming release based on such performance from the team. The team works hard, most team members stay late on several days to sync up with their US counterparts but the outcomes don’t necessarily match the intent and commitment from the team members.
How can you help this team achieve better outcomes?
Suggested Solution:
First of all, if you are a Scrum Master, this situation is something you will be very familiar with and would have encountered some time or the other – even if you did not have distributed teams to work with.
Let us first list the two major challenges the team is facing in their quest to achieve predictability:
1. US developers deliver code on the last one or two days of the sprint.
2. Mid-sprint changes in scope / occasional new stories which the PO considers as high priority
When you look at challenge 1, while there is no mention about the Indian developers, there is a possibility some of the Indian developers are also delivering their stories for testing towards the end. Addressing challenge 2 is perhaps slightly easier – as it involves the SM primarily working with the PO on the right process that will help the team achieve predictability (which is a win – win for both).
If there are changes in scope mid-sprint, it is possible that the story was never ready for being picked up by the team in the first place. A good Definition of Ready (DoR) for a story which is mutually understood and implemented by the PO and the team would go a long way in avoiding this issue. If the story has not met the INVEST criteria (which should be part of the DoR) then it should be deferred to a future sprint. Similarly any new stories that the PO brings in should be evaluated to check if it can wait till the next sprint (which could be at the most 2 weeks with a 2-week cycle) so the team is not disturbed mid-sprint. If it is unavoidable (which should perhaps happen once every 3
or 4 sprints in the worst case), then the team swaps the new story for a story not yet taken up.
The first challenge of developers delivering code at the end is a common problem and happens due to many reasons. Here is an analysis of the common reasons and possible ways to address them:
a. There is a strong separation of responsibility between the development and test teams.
While testing could require some specialization, most of the testing (such as at a unit level, component or functional level) should be done by all and be a shared responsibility – so if there is a separate testing or QA role, they are clearly responsible only for end-to- end or some of the non-functional requirements testing such as performance or reliability testing.
b. There is relatively low collaboration between development and testing on every story at the beginning of the sprint (with most collaboration happening at the end when there is a need for closing out stories). Dev and testing should be collaborating on their respective stories right from day one and on a constant basis right through. There should be more shared responsibility and no rigid boundaries between roles.
c. The team is working on all stories from day one simultaneously with individual developers taking responsibility for one or two stories each. This invariably leads to a situation where there is nothing complete for majority of the sprint duration and stories start getting completed (after testing) only during the last few days. This increases the risk of incomplete stories due to incomplete testing. One way to overcome this problem is to have the team swarming in on stories so they take up only one or two at a time, as a team, and complete them before moving on to the next one or two stories, again as a team. This leads to better team work with the test team actively involved in testing and closing out stories right from the beginning of the sprint. In the process it also greatly reduces the risk of incomplete
stories at the end.
