This experience report narrates the journey of my team to scale up as a customer-focused team in a new Agile Release Train. It describes the effort and various steps that we adopted and hopes to inspire others going through similar journeys.
1. INTRODUCTION
Customer centricity is a necessity for any organization that wants to stay ahead of the game in today’s highly competitive business landscape. It involves placing customers at the heart of everything you do. However, achieving customer centricity is easier said than done. In this report, I will share my experience of forming a new customer-focused agile team and the challenges and benefits that came with it. Trust and collaboration were key aspects in forming the team and personally, it was a very enlightening experience. Together, we learned that consistent collaboration, experimentation, and effective use of tools, practices, and data to understand customers are central to the forming of and continuing as a customer-focused team, especially in a large organization.
2. Background
Tryg is the largest non-life insurance company in both Denmark and Scandinavia and offers insurance to private customers and companies in Denmark, Norway, and Sweden. The Claims department in Tryg began the digital transformation journey in 2018 to replace a legacy system with the implementation of new claims handling system and corresponding ecosystems. The transformation program was executed leveraging SAFe, and the focus was to enable faster claims handling, increased automation and reduce claim handling costs. By 2022, with the final stages in the claims transformation program, there was a need to analyze the Target Operating Model, TOM, in the claims department and how to set up the most efficient digital claims experience. To decide on the TOM, a series of workshops were held with participants from various roles (Product Owner, Scrum Master, Business Owner, Product Manager, Architects, etc.). We saw an opportunity to implement a model which focuses more on customer experience and digital claims handling. After a series of brainstorming sessions, intense talks, and many debates, the model was finalized to execute as an Agile Release Train, ART, and the structure as below:
Figure 1. Target Operating Model
This also presented an opportunity for the team, where I was both the Scrum Master and Business Analyst, to transform into an actual customer-focused team in the new ART.
3. Your Story
Before the transition to the new ART, our team who was handling the customer portal was fairly new and we handled mostly small tasks and improvements on the portal for the claims pages. All the developers were located in India and we did not have a dedicated PO. We were not part of any ART and the ownership of the portal was with another ART outside the claims department. The team was not motivated enough to keep on working on minor maintenance tasks handed out to them and wanted to be part of feature exploration and be aware of the generation of value to customers. The TOM envisioned enabling individual teams in the ART with capabilities to cover the Claims operational value stream and drive customer focus. Being part of the TOM workshop, enabled me to understand these aspects. It was a great learning experience and gave me an opportunity to think about the bigger picture and all factors that we have to consider in setting up a model that will take into account all aspects of digital claims handling. From being a very team-oriented person, I learned to reach out to the leadership team and convince them of the importance of this team and how it could elevate the customer experience. Taking this step was important for me because it allowed me to broaden my perspective and become more proactive. Since the goal of the organization and the department had the main focus on improving customer experience, our team also became part of the new ART as a system-focused team with a long-term vision of becoming an end-to-end feature team. Many steps followed to embark on this journey.
3.1 Team capability assessment
Once the decision was made to incorporate our team in the new ART, our team conducted a self-assessment for mapping the competencies needed in the team to be able to deliver on the vision and responsibilities of the TOM. We had multiple workshops to accomplish this and was facilitated in MIRO to actively involve the distributed team members.
Figure 2. Team capability assessment steps
Personally, it was challenging for me. I had to let go of my multiple roles in the team and make up my mind to share responsibilities and knowledge and embrace my new Scrum Master, SM, role. A few key decisions to move forward in adopting the new TOM included:
- Include User Experience, UX, and capability in the team
- Have a dedicated Product Owner for the team
- Have only an SM role for myself
- Have a dedicated Business Analyst and Lead Developer
All these positions were decided to be onsite to enable closer collaboration in the team and in the business.
3.2 Team formation
Once the team roles and competencies were mapped out, the next step in the journey was to hire missing people and to upskill and cross-train the existing team members. There had to be an extensive onboarding plan for the new members and had to make sure that they all got the same idea about the goal we envisioned.
The onboarding plan was a place where the newcomer could find important links, information about the team, the plan for the initial two weeks, and a place to record 90-day milestones. The initial two weeks plan focused on the following:
- Introduction about Organization and initial setup: The TOM summary was shared with all members, and a session was planned with the Product Manager to share the mission and focus of the ART.
- Ways of working
- Tools and Technology: The team was familiarized with the tools used in the ART, and the new team members also received a portal walkthrough, code walkthrough, and further onboarding through code reviews and pair programming.
I could relate the onboarding period to the J curve effect that is often associated with a change in an organization. It is relatable that the new team members cannot start contributing from the beginning, and the existing team members need to spend their capacity to share knowledge. These were accounted for in the team backlog and velocity to enable transparency in the ART.
Figure 3. J curve effect diagram
It was an intense month for me as I was the only one co-located, and the rest of the team was distributed. I found the experience emotionally draining also, as collaborating with individuals from different working cultures and distributed across regions required navigating through inherent differences. To create a feeling of trust in the team was tough, but being open in meetings and giving a positive vibe was important. I learned that two traits were essential in this situation: patience and active listening. It is significant to consistently lend ears to every team member to listen to their experiences and feedback when there are ongoing changes in the team.
3.3 Ways of working
The team also adjusted and formed ways of working that suited us at this initial phase of team formation, and I would like to describe a few of them.
Daily stand-up
The team decided that the daily stand-up meetings need not be strictly timeboxed to 15 minutes. The team was in the initial forming phase and needed time to understand how we should work together. The new members required time to gain knowledge from the existing team members and used the daily stand-up to plan the work for the day. This was hugely efficient for us and evidently reduced frustration among members because everyone could discuss a bit in detail how to proceed with the tasks in the team. We had it for 30 minutes in the beginning and saw that it gradually shortened as the team became more mature.
Including UX in stories
This was the first time the team was working with such an approach. It was difficult for the developers to understand this style of working and for the UX’er to be part of an agile team without prior experience in agile/Scrum. This was an exciting experience for me to have discussions with the team as a whole and individually to figure out differences and how to guide them to bridge their communication and work together. Along with effective communication, I used some basic tools also to achieve this. For example, it was greatly beneficial to have a working agreement in the team and retrospectives focusing on this aspect for the team.
Refinement and readiness of user stories
We thought we could try out the approach of having little prior refinement and completing user stories within a sprint. Here, the team decided to experiment with the idea and find out how it worked. This experimentation did not yield the result that we expected. The team struggled a bit, not knowing the new ways of working and how to collaborate with the UX aspects. This resulted in conflicts in the team and the tasks not getting completed as planned. But this was a great way for us to learn and identify what was best for the team. The retrospectives during this period were very fruitful, and we could produce concrete action items to overcome this challenge. The most important aspect that we came up with was an agreement that we needed to fulfill some factors to plan the sprints and to determine the sprint backlog. The most effective way to do this was to have a clear understanding of the definition of ready, DOR, for a user story. I wanted to make the DOR and definition of done DOD, workshops in the team as engaging and informative as possible. So, I included some check-ins and videos and also involved some team members in facilitation, which led to very effective discussions, and we were able to land some good consensus for these. We could see commitment being met, less confusion, and more happiness in the team.
Figure 4. Comments after a sprint of implementing DOR and refinement cadence
Gherkin syntax for acceptance criteria in user stories
We decided to experiment with this approach to bring more clarity to the user stories and to use the refinement sessions efficiently. This was a really good way to think about the scenarios in a story and to visualize what the end user will experience as a result of delivering this story. We found this technique useful in multiple ways: to bring customer focus to the stories, to enable the splitting of larger stories into smaller ones, and, most importantly, to trigger discussions in the team about the stories.
Communication
Communication is key to working in distributed teams. Efficient practices can help team members collaborate effectively, build relationships, and achieve shared goals. We documented simple working agreements to enable effective and open communication. Two of the most important among these are:
-Keeping video on as much as possible in online meetings, at least during stand-ups and retrospectives.
-All the team ceremonies are to be conducted online in the first half of the day to respect the time zone difference between Denmark and India. We also use the collaborative tool MIRO to enable active participation from everyone.
Social agreements help in such a way that the team shares responsibility in defining how they work together and creating clarity. Since these were agreed practices, whenever there was a case where it was not followed, it was discussed in retrospect. We observed that although it was agreed by the whole team, sometimes gentle reminders were needed to make it a practice. Social agreements are a great way to enhance trust and cooperation in a new team.
4. How did we consistently keep customer-centricity alive?
The main focus of the team was to incorporate and maintain customer-centricity. We were already aware that we needed to find ways to know the customers and to collect and work on their feedback. We investigated and collaborated to find several ways to do this.
Metrics
We started looking at various kinds of metrics from other departments and stakeholders (power BI/Adobe analytics reports) to make quantitative assessments on areas that needed attention with regard to customer satisfaction.
Customer interviews
This is indeed an exciting initiative being taken to set up interviews with customers as part of an iterative process to collect feedback faster. This includes identifying the scope, defining the problem statement, making a question guide in the form of a moderated study, conducting interviews, and analyzing the insights afterward.
Knowing the customers
Apart from metrics and interviews, another easier step that we take is visiting the claim handlers department and listening in on calls with customers. This helps us to understand the pain points of customers and identify potential improvements. As part of the introduction of new products, we also ensure to have a dialogue with claim handlers on claims perspective with the customers in mind. This practice started off as a curiosity from the members located in Denmark to learn more about the domain and customers. Although there was no specific agenda in the beginning, it created motivation for the team members and closeness to end customers through the internal customers. This kind of interaction has helped the team to understand the customer journey when working on another feature. We plan to continue these interactions as it gives a good understanding of customer behavior.
Qualitative analysis
Alongside getting direct feedback, we also look at customer comments on the digital platform through surveys/forms that gather continuous feedback. All of this extrapolates into Qualtrics a.k.a Voice which enables us to gather a holistic view of the overall experience of customers with their respective intents. We then do affinity diagrams to further group comments into larger themes that help in identifying the intensity of the problem and digging deeper. While doing this, we also realized that establishing personas could improve the categorization and prioritization of features. This is an initiative that we aim to complete in the future, but there is a lot of work involved in this due to the large customer universe and the identification of factors to establish these.
Collaboration with other teams inside and outside the ART
Our scope is not limited to only the claims pages of the portal, but we aim to make customer satisfaction better by collaborating and contributing (whenever required) with other layers and departments in the organization and wish to enhance customer centricity across all layers. For example, we started looking at optimizing customer journeys by collaborating with different Lines of Business departments to help in the navigation of filing claims online.
5. What We Learned
There were two powerful learnings during this journey that should be emphasized.
- Consistent effort is required to keep customer-centricity alive in the team. It is easy to say that you are a customer-centric team, but it takes constant effort and focus to stay on the path. Two key practices that help to assure customer centricity are knowing the customers and focusing on customer metrics and data.
- Trust and collaboration are vital in the formation of a new team and it can best be achieved by fostering an environment of openness and feedback. Working agreements are a great way to start. I feel strongly that showing openness, honesty, and trust from your side is a great way to encourage the team.
Others who have similar focus and aspirations are urged to continuously explore and find ways to harness customer feedback to keep the customer focus alive. Although it requires more investment, time, and effort in the beginning, you too will enjoy benefits as the team matures, execution improves, and focus on customer outcomes increases. Every organization thrives on happy customers.
6. Acknowledgements
I would like to thank all the members of my team, without whom this experience report would have been impossible. I admire them for being part of this challenging journey and supporting each other throughout. I also wish to thank my organization and various people in the ART who have helped me with inputs during this journey, especially Signe Pedersen and Viviana Holm. I express my sincere gratitude to my shepherd, David Bacon, for helping me with insights, suggestions, edits, and feedback throughout this report. Finally, I would like to thank Niels Harre for introducing me to Agile Alliance which gave me the opportunity of writing an experience report for the first time.
