Success Story: Winning with Joint Story Sessions

31 January 2014

Ritesh Gupta
Tata Consultancy Services

Nichervan Fazel
Lloyds Banking Group


This is our journey of how we achieved a state of zero functional defects (mostly) by implementing joint story sessions in a multicultural, geographically distributed, multi-vendor environment. It also covers how we propagated change by making small bets with big gains.

We saw improvement in following areas:
  • Reduction in functional defects (almost zero functional defects)
  • Direct reduction in effort because of scope clarity
  • Indirect reduction in effort (attributable to time saved on clarifications, test data issues, incident logging, defect fixing, defect closure)
  • Improved quality
  • High team morale

Approach

Background: A humble beginning
We have a distributed team working across geographies and teams, supported by different vendors for build and test, working for a very large U.K. bank. Most of the project team is sourced from different functions (technical or business) to deliver a project. Given the constraints, the organization has been experimenting with various Agile models with customizations that meet the current needs.

Once the scope is established, we follow the Scrum framework for project execution. Given the situation, we are part of a large project team. This team is relatively new to Agile concepts; only few people have worked on Agile projects before. What follows describes our project journey and our experiments with joint story sessions in the environment described.

Identifying the problem
Sprint after sprint, we were noticing huge number of functional defects being raised. This was attributable to many reasons, but it was mainly because the test team and build team were working in silos and not talking to each other. In addition, a lot of time was getting wasted in sourcing the data and testing scenarios that subsequently were identified as outside the system boundary. Further, our distributed environment and multi-vendor situations did not help in any way. Everyone knew they had to work for a common goal, but it was still not falling into a routine.

Because we follow the Scrum framework, in one of our retrospectives the team agreed to try something different. The journey that followed over the next six months had to undergo multiple tweaks, but the results are promising. We have now adopted this as a best practice for us.

Our solution: Forming a habit -- joint story sessions at the beginning

Iteration 1
Reactions before implementing: The test team was anxious. They didn't want to share the test cases with the build teams, saying the build would have already tested it and then they would not find any defects! The first iteration was guided and the teams coached on what to do. The only major change in the teams' work was having a half-hour discussion between the developers and testers on what the story was from the business perspective, what was to be developed and tested, and how we would show that it was complete. What also followed was sharing and review of test scenarios across the teams.

Result: Marginal reduction in defects but still a high number of defects.

Reactions after implementing:
Pigs: The team believed it actually resulted in improvement. They had a better understanding of what individuals were doing and, more important, they had an understanding of what others were doing to achieve the common goal. Some people on the team were skeptical, but some wanted to try it further.

Chickens: Result of Hawthorne effect.

Iteration 2
The team now had self-organized and had a better understanding of things to cover in the session and had a good idea of the questions they wanted to ask each other.

Result:
  • Zero functional defects
  • Indirect reduction in effort (attributable to time saved on clarifications, test data issues, incident logging, defect fixing, defect closure)
  • Improved quality
  • High team morale

Reactions after implementation:
Pigs: Team had high morale and wanted to try more. It agreed to do so for every complex user story subsequent sprints.

Chickens: Would like to see more data.

Iteration 3 with more tweaks
By now the team was following joint story sessions and we were not seeing any functional defects. In one of the sprints we had a very complex change that the team didn't have full understanding about. It was not clear what needed to be done or how it was to be achieved. By now the business analyst was more involved with the team and was taking part in the joint calls.

Result: The session resulted in a few checks that the development team had to perform on existing functionality. It was realized that the requirement needed further discussion and enhancement before it could be taken for development. The business team went back to the drawing board and returned with a refined requirement, which was implemented with zero functional defects.

Iteration 4
By this time, the business analyst was also part of the team doing the joint sessions. The key takeaways were that the team was able to identify what was to be developed and what was to be tested. With the business analyst in the call, the team was able to decide some of the scenarios that were not required to be tested and were overkill. It became a highly collaborative environment. The result was:
  • Zero functional defects
  • Direct reduction in effort because of scope clarity
  • Indirect reduction in effort (attributable to time saved on clarifications, test data issues, incident logging, defect fixing, defect closure)
  • Improved quality
  • High team morale

Here is how the results stack up from various tweaks to the joint story sessions for our project:


Conclusion

In a multicultural, distributed environment, joint story sessions have helped bring the teams closer and make them more collaborative. The benefits for the practice are absolutely clear. Best results were achieved when the team self-organized to implement this as a practice. Eventually, every team will need to find what works for them in the joint story session.


Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.



Article Rating

Current rating: 3.5 (6 ratings)

Comments

Grégory FONTAINE, CSP,CSM, 2/5/2014 5:06:19 AM
Thanks for the story guys. It's great that you wrote this article together, the client and the supplier!

I think you should go even further than that now. Communication should happen during the whole day, not only during those "sessions". And you should consider yourselves as one team, not two (developers and testers).
Cheers.
Hemant Gokhale, CSM,CSPO, 2/9/2014 1:20:26 AM
Thanks for experience sharing. It is always very challenging to work in multi site/multi vendor environment for Agile implementation . Apart from geographical time zones difference, trust within team also becomes a very big impediment in such environment. Definitely you have tried successfully removing this impediment iteratively to significant extend.

You must Login or Signup to comment.