Souma Chatterjee (Souma) was the Scrum Master in a project to develop the next generation of a product called ProClaims which supported her organization’s operation as a Third Party Administrator (TPA) in the medical insurance industry. TPAs process claims on behalf of insurance companies, working with patients and hospitals. Insurance companies would pay the TPAs based on the number and value of claim transactions handled by them.
Key success criteria for the insurance companies were the speed & accuracy of claim settlements and the satisfaction their customers (the claimants). So, the insurance companies were always pushing their TPAs for reduction in cycle time and manual effort in processing claims. So, the business of the TPAs was extremely competitive, with everyone going after insurance companies trying to displace incumbent TPAs with promises of reduced transaction cost and improved service. Hence, TPAs were constantly looking for improvement and innovation in their operations and software platforms in order to protect and expand their customer base of insurance companies. Souma’s organization was a TPA providing a comprehensive solution comprising a BPO service supported by their own software platform, ProClaims. ProClaims was a key differentiator for the organization and had helped win deals with some of the biggest insurance companies in the country.
Souma was a developer in the ProClaims team that had delivered several releases of the product over the years. The team was making three-month releases typically comprising defect fixes and enhancements. Each release comprised six two-week iterations. Over time, the team had achieved a fairly stable velocity and the product management team and the Product Owner Dhananjay Sen (Dan) were quite happy with the team and its performance. In the ProClaims team, the practice was to rotate the role of the Scrum Master among team members in every release. Team members volunteered for the role and went through an under-study phase for one release (if needed) and then took up the role for the next release. Souma had been trained in Agile Scrum and mentored by previous Scrum Masters. She had also taken an active interest in studying servant-leadership which she thought was key to her success as a Scrum Master. Souma had been the Scrum Master for some of the earlier “easier” releases and quite liked the experience to practice servant-leadership. Souma was now the Scrum Master for the current release which had completed three of the six iterations that had been planned.
The current ProClaims release had run into problems right from the first iteration. Out of a team of nine, three had resigned and left without notice. The rumor was that they had been lured away by big money from an upcoming TPA trying to establish itself as a serious player in the field. As a result, the team velocity had dipped. Souma’s management was asking her how best to address the situation given the higher criticality of the current release. The release had become more critical due to the integration of a third-party Rules Engine, an AI based component that promised to reduce the manual effort from one hour to ten minutes for certain claim categories. There were several significant technical issues to be resolved in the Rules Engine integration in the current iteration. Iteration goals and even the release goals seemed to be at serious risk.
To add to the woes, Palash Jain, a team member involved in the Rules Engine integration had to frequently take time off to support his wife and newborn twin girls. Souma has been very empathetic and encouraged the team to rally around and make up for Palash’s absences but the impact was still very much there.
Under the circumstances, the Product Owner, Dan was very unhappy. Souma described the various challenges including the situation with Palash but Dan angrily retorted: “Souma, if you can empathize so much with the team and Palash, how come you don’t empathize with me and my situation? Do something about it – don’t you know that our Business Head has committed the Rules Engine features for one of our major customers?” Souma was surprised by this bit of news from Dan. Dan’s outburst also got Souma to think whether she was at all being an effective servant-leader for the whole team.
Exercise:
1. As Souma, what are all the things that you could and would do to address the situation? Assume there is no designated Agile coach for the team.
2. Re-visit 1 above and identify how the presence of an Agile coach would make a difference.
Suggested solution:
On what Souma could have done under the situation and how the presence of an Agile coach could have helped. Also, this solution is not meant to be the last word – you, as the S Curve reader, may have additional perspectives which we would surely like to hear – so, please post your comments as well.
1. Souma as the Scrum Master for the current release
Souma without an Agile coach:
It appears that the choice of a Scrum Master has proceeded on a rotation basis without perhaps a full realization of the release attributes and whether a new Scrum Master would be able to cope well. It should have been obvious to Souma and the rest of the team that there were some specific challenges in the current release relating to the Rules Engine. While volunteering for the Scrum Master role, Souma could have considered this and chosen not to take it up in favor of a more experienced Scrum Master. Or, she could have discussed it in the team and the outgoing Scrum Master for additional support & guidance right from the start of the release.
Souma with an Agile coach:
Had there been an Agile coach, he could have asked the team to think about how the Scrum Master rotation process is working. Other than volunteering, were there not other aspects of the release and people’s readiness to be considered? Without imposing his own views on who should be the Scrum Master, he could have made sure that whoever was volunteering (in this case, Souma), was doing so with eyes fully open. Subsequently, he could have also had a one-on-one session with Souma and asked her to think about the release challenges and what support she would need.
2. Team attrition
Souma without an Agile coach:
It appears that there was serious staff attrition right in the first iteration of the release. After three iterations (six weeks), it is not clear if any remedial action was taken either by Souma or her management. One should also consider whether the attrition should have come as a complete surprise if Souma had had her ear to the ground and sensed what was brewing in the external job market and in her own team.
Souma with an Agile coach:
Under the circumstances, the Agile coach may not have much of a chance to prevent attrition. But he could help Souma to retain the rest of the team in various ways. The Agile coach often has a reach & influence with the senior folks in the organization and could use that to alert the leadership for some immediate actions at the team level and at an organizational level (such as salary benchmarking / corrections, recognition & reward etc.)
Team member availability (Palash Jain)
Souma without an Agile coach:
The fact that Palash Jain had a personal situation (wife giving birth) impacting his availability surely could not have come as a surprise! This is assuming Palash had been open with Souma and the team – all the more so, when he had apparently volunteered for working on the critical stories involving the Rules Engine. If not planned for, only some rear-guard actions are possible for the team to consider & implement.
Souma with an Agile coach:
In this case, my personal view is that the Agile coach could not have made much of a difference. I do not think he would have had a role in who gets to work on what stories and be aware of personal situations of individual team members as much as the Scrum Master. This ought to have been addressed by Souma and the development team, bringing in the Product Owner as early as possible for discussion of alternatives vis-à-vis the iteration goals. Now, after the fact, the Agile coach may at best facilitate salvaging the situation working with the entire team.
3. Shared mission and goals / Servant-leader & empathy
Souma without an Agile coach:
Towards the end of the CHOW, there is mention of the Product Owner (PO) telling Souma that the Business Head had committed to a major customer that the Rules Engine features would be available from this iteration ahead of the final release. If so, a basic Scrum rule has been broken – that an iteration goal had been pre-committed by the Business Head seemingly without discussing with the Product Owner and the engineering team. However, even now, Souma, the PO and the team need to work together on what best can be done just so that the organization does not lose or face adverse business consequences.
Empathy on the part of the servant-leader makes sense when goals are clear and agreed. Then the servant-leader enables the team to serve those agreed goals. In this case, when a key iteration goal does not seem to have been discussed / agreed with the team, surely, empathy of Scrum Master cannot work any magic. So, Souma should realize that the plea from the Product Owner to be empathetic was just a way to pressurize her and the team. However, Souma can explain to the Product Owner as to why she was being “unempathetic” and what best can be done.
Souma with an Agile coach:
The Agile coach perhaps could not have helped prevent the situation that has arisen. However, he can help in generating options for the development team and Product Owner to consider – mainly around identifying the core of the Rules Engine features that could perhaps be accommodated in the current iteration.
He could help Souma with better understanding the empathy characteristic of servant-leadership.
The Agile coach can also bring up this incident with the leadership at some appropriate point hopefully to prevent recurrence.
