This is a story about experimentation and decision making, about software development, about Scrum and Kanban. It’s the long-term roadmap and urgent needs. It’s combining predictable tasks and unexpected events. It’s also team optimisation and cross-team satisfaction. So, this is how it all began…

At Empathy.co, we have two very clear goals:

• Building the Product: a beautiful Search & Discovery Platform
• The Delivery of that product to the customers

From the product-owner perspective of a frontend team, both of them are equally important for success. We try to build the perfect frontend solution in the mid to long term. However, it is the customers who decide if the product fulfils their expectations and, ultimately, if it succeeds.

This turns into a Scrum board that holds both worlds together: the product tasks plus the delivery tasks referring to specific customer requirements. After some time, we detected that our common board stopped us from doing our best. These were the reasons:

• The delivery tasks showed up on demand. They were sometimes included during the sprint, changing the task priority and sprint scope more often than desired.
• It was necessary to reserve a certain number of story points to include unexpected delivery tasks, making the sprint less predictable.
• Product and delivery tasks were competing to be a priority in the same queue.
• There were multiple changes of context amidst a high number of product and delivery tasks.
• Time was wasted deciding priorities and the story points budget with Key Account Managers (KAMs) for each sprint.
• There was no clarity about the state of delivery tasks for key account managers. Because product and delivery had different DoD, there were lower environments for the product libraries. KAMs had to inspect every customer task to know in which environment it was deployed.

Let’s explore the Empathy X Frontend team topology to understand the nature of the experiment we created:

• One product owner and one Scrum master
• Seven frontend engineers
• One QA engineer

Since this was not a small team, the size also contributed to a feeling of many things going on at the same time. We had many product and delivery stories in each sprint, with too many changes in context.

Time to experiment

Realising that we were underachieving forced us to experiment. We knew we could do much better. We knew we couldn’t change the customer or product requirements. However, we could change the way we handled them by dividing and conquering, and, even more importantly, by focusing. So we decided to do the following:

The process

Kanban for delivery tasks

• Having a good number of clients means that tasks and requirements change every day. Kanban gives us the flexibility of not having a time frame (sprint) associated with tasks.
• We don’t disrupt product evolution and the product board. The KAMs have a clear view of what is being done in delivery so they can change the priorities on demand. They can prioritise the tasks themselves in Kanban with the help of the product owner.
• There is no need to calculate the story point budget for the delivery of each sprint (although we still use user stories to measure the outcome).
• We also have a staging state column, so we easily know if something is deployed in production or lower environments.

Scrum for product tasks

• The Scrum board for the product user stories and tasks will remain the same, but much clearer, with two-week sprints.

Team members

• Keep five frontend engineers focused on product evolution.
• Set two frontend engineers focused exclusively on customer delivery tasks during each sprint.
• Establish a rotation. At the end of each product sprint, the two members involved in delivery will get back to product tasks, and two new members will work on delivery.
• The QA developer will review all delivery tasks as a second reviewer and keep working on product tests. This is the only member of the team who pivots between both worlds within a single sprint.
• To minimise the damage of context change, a ‘state of the art’ meeting will be scheduled between the ones that go out and the ones that come in Delivery tasks.

Scrum events

All team members will attend all the Scrum events to maintain a feeling of teamwork. The first part of the standup will be for Product, and the last part for Delivery. Refinement, Sprint Planning and Retrospective sessions are open to all team members, even the ones included in delivery tasks. This keeps delivery rotation members aware of product evolution.

What will we measure to see if the experiment is a success?

Measuring success is key to evaluating if the experiment is here to stay. We need to think not only about the number of story points, completed tasks and analytics, but about team health, product evolution, clarity and customer experience too. Therefore, we decided to focus on:

• Team satisfaction
• KAMs’ satisfaction
• Customer satisfaction
• Productivity of the team in Product
• Productivity of the team in Delivery
• Reducing process complexity and wasted time

At the end of the day, we were facing the same input as before. We would deal with the same amount of product and delivery tasks, the same meetings with the stakeholders, and the same Scrum ceremonies. However, we were going to manage it in a totally different way.

I wanted to jump in a Delorean to see what was going to happen after three or four sprints, but Doc wasn’t around, so we had to wait! Luckily, you, as a reader, will only have to jump to the next section of this article….

The outcome

To understand the outcome, let’s check the Empathy X performance before the experiment.

The average speed was 82 story points (if story points can be seen as an accurate way of measuring speed…) combining product and delivery tasks.

The first sprint in which we tried the experiment was sprint W22. In that sprint, the team managed to:

• Close 80 story points in tasks only related to product (with two devs less).
• Close 38 story points and three bugs in delivery tasks that hit Staging (waiting for customer feedback) or Production column.

In the next sprint W24, the team managed to:

• Close 66 story points in tasks only related to product.
• Close 31 story points in delivery tasks that hit Staging or Production column. And, even more significantly, the team completed a total of 16 tasks, meaning that the more atomic the tasks, the better the experiment worked.

The team’s pace increased considerably, and we became even more focused, with subteams resolving specific issues.

By the end of the Sprint x-2021-w28, we had literally emptied the total amount of delivery tasks. There wasn’t a single customer waiting for a development piece from our team; we had cleared 90 tasks in five sprints. The rotation team, which was focused on delivery, felt proud of their achievements. Furthermore, the key account managers could satisfy the customer demands and work in a much more stable environment.

Now, some months later, we normally have just a few delivery tasks on the Kanban board. This lets us focus on the product and remove the rotation team in some of the sprints. But the most important part is that we have the solution when delivery is the priority.

You may take this article in two ways. There is value in this particular way of working, different frameworks to concurrent challenges, and you may use the same approach in your team if you feel you are facing the same kind of situation. But, in my opinion, the most important lesson is the value of experimenting. Don’t be afraid to try new solutions when the problems remain the same.