Squads Involved 

The solution was built by Customer Frontend and Advice & Decide Backend II squads. Customer frontend squad builds user interface and customer experience layer using Typescript, React.js, and node.js, and Advice Decide Backend squad builds the process layer using C#, .NET Core, and API Gateways.

The current Customer Frontend squad consists of:

Current Advice & Decide II squad consists of:

Both squads need to work in synchronization to deliver customer value. Our tribe architect Vaidas points out that this setup reflects our target architecture where the customer experience layer is responsible for the overall customer experience and chooses efficient ways to collect and display data and options, while the processing layer is responsible for implementing and exposing capabilities needed by the experience layer. Having well-defined boundaries between services of both squads, the integration layer is thin and easy to mock to reduce dependencies during development. We are also aware that the setup of split frontend and backend squads may potentially introduce two silos where boundaries become walls and issues become items to throw back and forth over the wall. To prevent this, having a common vision, a strong sense of responsibility, mutual respect, and well-aligned ways of working are crucial to success.

Collaboration Enablers

Two key elements are must-haves for efficient and smooth collaboration in our setup. 

Priority Alignment Sessions 
Priorities must be aligned across both squads. If the Change Loan Terms solution is our #1 priority at a certain point in time, then both squads must take all user stories and tasks related to this solution as first-priority tasks. To ensure the alignment, we have a short common session (usually 15 minutes long) at the very beginning of each sprint planning for both squads, as well as have bi-weekly alignment standups at the end of the first week of the sprint. 

Common Chat Channel on Microsoft Teams 
A fast feedback loop between squads and each squad's ability to adjust its work according to the other squad's needs is essential. In the beginning, we attempted to align and solve ongoing tasks by having bilateral talks among squad members and organizing meetings when needed, but we realized that it is not sufficient. Then, we introduced a joint Microsoft Teams chat with members of both squads. The chat was the place to indicate blockers, update on the progress or celebrate small successes. This way, we have minimized individual discussions and alignments between different squad members and achieved better overall awareness and transparency of work progress. 

In addition to the chat, we have also been adding buffers in the sprints to address potential issues. For example, if a new backend endpoint was exposed, and both squads knew that Frontend Squad would start consuming it, we include some time buffer in the Backend squad sprint to address potential bugs or changes. This "buffer" may not be a number of hours or story points, it is more mental readiness to address issues raised by another squad.  

We have asked a few members from both squads to share their thoughts. 

Greta (backend) says that having a common goal helps, and both squads usually have the capacity in sprints to address the other squad's requests, so each side can react fast. She also noted that common Teams chat eliminates pinging individual people and whoever has time or knowledge can pick up the request. Additionally, the knowledge is spread across all squad members. One of our learnings was that it is not enough to agree on some adjustment on the Teams chat, and we need a corresponding Jira ticket to be created, otherwise, agreements tend to be forgotten. 

Justinas (backend) adds that it helps a lot that both squads have similar views on best practices, e.g., REST API principles, as well as both squads are willing to make changes on their side if needed (no pushbacks like "we don't want to change on our side, please adjust to us"). 

Ruta (frontend) highlights the "magical" Teams chat and fast actions from both squads when reacting to the other squad's message and trying to "unblock" the other squad. We still face some difficulties though, for example, in one sprint, the Frontend squad started to use some of the newly exposed endpoints, and it appeared that their structure needed to be changed. The changes were not trivial and took some time to implement, so the Frontend squad could not continue working on consuming them. In this situation, the Frontend squad used mocked responses: since it was possible to quickly get clarifications on to-be response details in the chat, switching from mocks to real APIs went smoothly.

Sprint Events Cadence

Both squads have the same sprint cadence and Sprint events (daily scrum, planning, review, and retrospective), but some specifics differ as displayed in the diagram below.

Solution Development Timeline

3. Finalization

As you can notice in the chart below, the three stages overlapped: main planning and estimating were done during Sprints 23 - 25, and the development started on Sprint 24. (Actually, the first story-points were completed on Sprint 21, but that was just project initialization on a code level and implementation of authentication mechanism). Finalization was done during Sprints 29 and 30. During Sprint 29, testing and bug-fixing took place. It is important to mention that we test each user story, however, for bigger releases, our business analysts do one more thorough pass-through of all use cases to make sure we are up and ready for going to production.

Backlog Refinement

Backlog refinement is a common practice in an agile setup, to achieve a shared understanding, estimation, and prioritization of upcoming work. Even though refinement process goals are clearly defined, implementation details may vary across squads. Frontend squad has weekly early refinement sessions (55 mins) where business analysts and UX specialist present upcoming stories to developers and collect questions and feedback. In this meeting, the story might not be refined 100%, but feedback/questions from developers help the story to become "Ready for development". We also hold a backlog of topics the squad wants to address and discuss. If the early refinement finishes early, we use the remaining time for the topics from the backlog. Then, Frontend Squad has weekly refinement sessions (55 mins) where the squad goes through the prioritized backlog and estimates stories. 

Backend squad's refinement practices are slightly different. One short 15 minutes session is held biweekly, where user stories and priorities for the next sprint are being reviewed. A separate ad-hoc refinement session is being held if a story needs clarification. The estimation of stories and refinement is done during sprint planning session. 

Estimation

Frontend squad estimates stories using story points and uses Fibonacci sequence values 1, 2, 3, 5, up until 8 with an additional "0.5" - if the task is minor (e.g. adjusting text value is a good candidate for 0.5). Story points are units of measure that indicate the size of a work item in relation to work complexity. We try to avoid large stories, as they tend to spill over onto the next sprint. If the story is estimated at 8 story points, then we try to find a way to break it down into smaller atomic chunks. Story points are not associated with time spent on the task - we measure this by complexity. At the very beginning, not associating story point value with "how many hours it will take" was a challenge for the squad, but 2-to-3 sprints in, we got more comfortable looking at the task from the viewpoint of "how complex it is" instead of "this will take me x amount of hours to implement". Additionally, we use the concept of "relative complexity" which helps when estimating. We start with estimating one story, and in the following, we are comparing the complexity relative to the already estimated ones. 

Backend squad initially were estimating stories in hours, but gradually hourly estimates started to resemble story points. At one point, the squad decided to forget hours and switch to story points entirely. Currently 5 story points reflects "one ideal day of work". One of the key elements in estimation is to achieve that squad members understand what needs to be done, so developers spend time together in the planning session to break down user stories and tasks. To reach a common understanding is more important than to precisely hit the correct estimate. 
 
The reasoning behind the measuring in story points is that everyone's pace is different. Each team member in practice has a different velocity, depending on seniority, experience, familiarity with a specific domain and code area. At the end of the day, it's the team velocity that matters. For example, Frontend squad has average velocity of 42 in the last 6 months, and 44 in the last 12 months, which is stable enough. Velocity chart is a valuable tool for measuring team's pace, planning the upcoming sprint load, and forecasting upcoming deliveries.

Sprint Planning

At the start of Sprint planning, Frontend squad already has story estimates from the refinement sessions. During sprint planning, they select stories to be included in the coming sprint, agree on the sprint goal and name the sprint. The planning event takes around 45 minutes.

Meanwhile, Backend squad's sprint planning takes longer (around 2,5 hours) and includes alignment of priorities, estimation and refinement of stories, agreement on sprint scope and goals, and naming the sprint.

In the Sprint backlog, stories must be ranked from the most important one to the least important one. Whenever a squad member is looking for a new task to pick up, he or she chooses the first not started task from the top of the Sprint backlog.

When deciding how many items to take into the sprint, squads base their decisions on past-sprints velocity and squad availability during the coming sprint. The availability may vary because of days off, vacations, or specific trainings and events in the squad or tribe.

We try to be "ambitious enough" but not "overconfident" when estimating how much we can take into the sprint. We try to ensure that all user stories that are critical for the sprint goal have the highest priority ranking on the Sprint board. It is also handy to have a few non-sprint stories prepared at the top of our product backlog so that we can take them into the sprint if we are short on tasks during the sprint.

Sprint Goal

Having Sprint Goal is one of the crucial elements in our sprints, because a clear goal helps the squad to know the main focus of the sprint at all times. Whenever a squad member is in doubt about what to do in the middle of the sprint because of too many options, take the one that contributes to the sprint goal the most. Both Frontend and Backend squads have them, and usually it is around 2-3 goals per sprint in order of priority.

It is very important to align the goals between Frontend and Backend squads, and to enable this, we have common 15 minutes alignment session before starting each squad's planning.

Sprint Name

How sprint names influence team spirit and results could be separate research on its own.

Frontend Squad were "Patient zero” of this viral initiative. From the outside, naming sprints may look a bit "random", however, the squad has been carefully choosing the name of each sprint, depending on the events happening in the squad. For example, Sprint 21 was named Spreading the Smiles because we have successfully validated proof of concept which enabled customer feedback. We call it a smiley index and the main theme of the sprint was scaling the feature across our other solutions that we will be working on. Sprint 29 name CoL Mic Drop signified the ambition to complete the testing, fix remaining bugs and release to production.

The Backend squad was a late adopter of this technique - they started to name sprints after the frontend squad has been doing it for more than one year. In a similar way, they try to pick up the topic depending on what is on the squad's mind during the given moment. For example, one of our recently used names was Hi Scrum Assistant, which indicated the start of using internal planning tool developed by our neighbour Fulfilment and Use squad in our Tribe.

Deployments

Our default release cycle is 2 weeks and, if there is a specific need, we deploy more frequently. Each sprint we deploy to production the code of tasks completed in the previous sprint and we tag the tasks using Jira fix versions. Some tasks build upon functionality that is already running in production, while other tasks may build a functionality that will be deployed but not yet launched for use.

Learnings

• To achieve synchronized delivery of customer value by two squads, aligned priorities are a must-have, and communication channels and agreements must be in place.

• "Service-first" mindset towards your colleagues in your squad/other squad needs to be built and nurtured by having the same sprint events cadence, alignment sessions between squads, and communication channels.

• Details of how squads run sprint events such as planning or refinement may differ and it is fine to leave the decisions on those details to squads themselves.
  

Authors of the article