How and why did I work with both Scrum and Kanban at the same time?

Scrum vs Kanban

When working in squads in agile methodology, many ask themselves with which framework to work: Scrum or Kanban? I worked with both at the same time for more than a year and a half, and both worked very well. Here I will try to explain how did I get to this position and why I think it was successful.

What does ‘Scrum’ and ‘Kanban’ mean anyway? In the most general way, these are two frameworks of Agile software development. Scrum is based on boxed time units called ‘Sprints’, usually two weeks each. Each sprint has a well-defined sequence of ‘Ceremonies’ that aim for selecting what to execute in the sprint and then making sure it is executed as planned. Once the sprint has started its content should not be changed. Kanban is a continuous method in which team members constantly pull tasks from the To-Do list and execute them. The only limitation in Kanban is how many tasks can the team execute in parallel. You can read more at this Atlassian blog post, or just Google both terms.

Spinning a new squad

Soon after I joined the company, Duda, the Product-R&D organization went through a deep organizational change: starting to work in squads. Each squad had a product manager, a technical lead, developers, QA persons, and a designer. Each squad was asked to choose how they want to work and to manage their work autonomously. We could choose Scrum, Kanban, or anything else we wanted.

I was assigned as the product manager of the Platform squad. This squad was responsible for multiple domains: an emerging product, an app store where third-party products were integrated into Duda’s product; the Widget Builder, a small platform for our users to develop their own website widgets and reuse them on multiple sites; the company’s billing systems; and the APIs and webhooks not related specifically to any other squad. 

About two months down the road, me and David, the squad’s tech-lead, came to the understanding that the squad cannot be owning the billing systems together with the other domains. We articulated the reasons and approached our managers, and the result was spinning off a new squad owning the billing systems, titled ‘Pricing Squad’. One of the experienced billing developers, Fabio, was promoted to lead the new squad, and I was now a product manager of both squads.

One squad Scrum

There were several reasons to spin off a new squad. One became very apparent soon after: that each squad needed a different framework. The Platform squad continued to work with Scrum, while the Pricing squad turned to Kanban, meaning I practiced both. The reasons for that are rooted in the traits of each of the squad domains. The Platform squad is a product-centric squad, which at that time was very focused on delivering Duda’s new App Store. We had to make tangible progress towards a working product each week. We did not have a lot of distractions, as the other domains we were responsible for were well established and in maintenance mode.

Moreover, as the App Store is an integrative product with third-party teams developing into our infrastructure, we aimed for predictable timelines that can be communicated to our app-partners. The Scrum framework fits these considerations very well. The two-week Sprint cycles allow us to make product progress, to estimate it ahead of time, and to communicate expected progress to partners. Developing a new product also means fewer technical constraints, meaning developers can design the solution of each requirement very close to the execution. With Scrum, it is very much possible that developers are becoming familiar with the details of a requirement just a few days before the in which this task is to be executed. If most tasks would require a few weeks of detailed research, running with Scrum would be quite difficult.

One squad Kanban

The Pricing squad is almost a mirror image. It is a very operational squad. Since the billing systems are key operational systems and are very complex, the squad needs to pay constant attention to bugs, alerts, and escalations from support. Product focused teams can decide not to fix many kinds of bugs or not to address many feature requests - if the squad finds that investing in other areas will better support the company. In product-focused squads, it is very likely that even though a specific user flow crushed the system occasionally or is not clear enough, there are other product improvements and features that are expected to have much greater returns to the company. But this is not the case with billing operations. If a client is over or undercharged, it must be fixed soon, even if the underlying cause will be addressed later on. One of the main difficulties we experienced before spinning off the Pricing squad, was that in each Sprint we had to keep a ‘black box’ placeholder for pricing escalations that will come up during the two weeks of the sprint. More often than not, there was no connection between the efforts we planned to invest in these placeholders and the actual time the squad spent on them.

Also, many times the Pricing squad is required to support initiatives of other business departments outside the product-R&D organization such as A/B test on the pricing plans, marketing promotions with coupons, and more. Lastly, the technical nature of the tasks is much different. As billing systems are very complex, sensitive, and interdependent with external services such as credit-card processors, most tasks require a long research and design phase before execution can actually start. Giving all these traits, Kanban is a natural choice. It allows high flexibility and quick response to incoming issues and business initiatives. It supports execution driven prioritization for long development phases and continues integration, both allowing developers to manage execution following technical considerations. It allows conducting research in parallel to execution, a long time ahead as needed.

My personal split continued for about a year and a half. For me, it was in fact very easy to work in both frameworks in parallel. With time, I also got confident in the fact that each squad chose a framework for the right reasons, and not following a convention or some other form of groupthink.