Can Kanban scale for teams of over 50 developers? When should you consider moving to Scrum?

Although Kanban and Scrum are both Agile development frameworks, they are very different in nature. Kanban is considered less formal and structured than Scrum. It has fewer meetings (and “ceremonies”), no formal roles, and doesn’t require team members to provide estimates on the tasks before taking them on. 

Scrum, on the other hand, is much more structured, and to some extent, more predictable. It has roles, ceremonies and structures that increase visibility and predictability, but at the same time they inherently add substantial overhead. Scrum requires more management, reporting, and interactions, which some say can slow down development efforts. That is why Scrum teams need a Scrum master to guide the team and ensure that everyone adheres to the scrum framework. Kanban is extremely flexible and can accommodate constant changes at any time. New tasks can be added to the backlog and existing cards can get blocked or removed based on prioritization. Scrum teams strive to avoid scope changes during a sprint. If changes arise during the sprint retrospective, Scrum teams should discuss how to limit change in future, as changes put the potentially shippable increment at risk.

In this blog post we will examine the differences between Scrum and Kanban, discuss when teams should select one or the other, and finally provide real-life statistics on the methodology elements that teams have adopted after implementing them.           

 The difference between a “commando team” and a “regular unit”

Kanban methodologies are continuous and more fluid, whereas Scrum is based on short, structured work sprints. In many cases the decision to use one methodology versus the other is made at the organizational level, while in other cases management will ask each of the dev teams to decide on their own. Either way this needs to be an explicit decision. But figuring which one to choose can be daunting at times.   

To help figure which of the two methodologies would suit your team(s), let’s examine the following military metaphor: Military forces often have a small commando elite team (special forces) operating alongside a regular army unit/division. The small elite team includes highly trained members that can take on special high-demanding tasks. Since the commando team has trained together for years, they can coordinate their moves without communicating; everyone knows what they are supposed to do, when to do it, and they get the job done extremely quickly (even before the enemy has sensed their presence). 

On the other hand, the regular unit/division comprises soldiers of all levels that can climb the command chain as they become more experienced and/or accomplished. Unlike the commando team, the members of the division/unit don’t necessarily know each other that well, but they make up for it by following a chain of command, strict rules, many meetings/briefings, ceremonies, etc. 

The lack of rigid structure and little to no ceremonies and rules allows the commando team to be nimble and move fast while focusing solely on completing their tasks. They know that all members are highly trained so they do not have to double-check them, manage them and guide the less experienced members. On the other hand, the division/unit needs this structure because not all members are experienced, and even if they are, they need to have trained together to be able to coordinate their efforts with little to no communication. In order to compensate for the variation in the experience and coordination, they have a rigid structure, rules, ceremonies, etc. All soldiers have to constantly report to their superiors, who in turn report to their superiors, etc. Although this creates substantial overhead, without it there would be chaos and lack of coordination. 

Back to the dev teams 

The same reality applies to the development teams. Typically small dev teams operate like a commando unit. This is common during the initial stages of startups, where the founding team has had previous experience working together in a previous capacity. If the team members are all A+ developers, they can simply create a backlog of tasks and then each member takes on another task, while indicating on the Kanban board what they are doing. They can move forward very quickly from one task to the other with minimal overhead. Since everyone knows each other well, and they can rely on their excellent abilities, there shouldn’t be any surprises in terms of the time it takes to complete a task. If something is challenging or there is a problem that requires the assistance of the other team member, they will ask for it - and get it. 

When you start scaling the dev teams, for example to teams that are larger than 50 developers, you lose the close familiarity between the members and will probably see variations in their experience and capabilities. Although everyone likes to think otherwise, let’s face it, you will never see a team of over 50 A+ developers. In this case, like in the example of the regular unit, you start to see the need for more structure and predictability. You need better coordination of efforts and to be able to constantly remove blockers and issues that are holding some members back. This is where Scrum provides the most value. 

Scrum advocates argue that working in constant iterations, in which developers commit to a certain deadline, causes the dev teams to try and meet this deadline. On the other hand, in Kanban there are no deadlines and therefore it relies on their “best effort”, assuming that they will put in their best effort to deliver the most output. In terms of human nature, committing to a “best effort” approach offers less of an incentive than committing to a specific scope to be delivered in a certain deadline. So even if the Scrum team ends up being wrong, it is better than not providing them at all. In a larger team, without these scopes and deadlines, meetings and official roles, it is more likely that you will see some members fall behind, as challenging tasks could take longer. etc.

Finding the right balance 

If you are worried about the overhead, you shouldn’t be, because in most cases dev teams adapt the Scrum methodology to their own team dynamic. You don’t need to follow the entire methodology. You can select a subset that works for you. For example, hold daily standup meetings but not other Scrum meetings, or vice versa. Many teams implement hybrid models influenced by both Scrum and Kanban: Scrumban, an Agile development methodology that is a hybrid of Scrum and Kanban. Scrumban emerged to meet the needs of teams who wanted to minimize the batching of work and adopt a pull-based system. You can start with basic elements and then add more to see what works and what is holding you back. 

As an Engineering Intelligence Platform, Acumen offers a unique perspective on how dev teams from around the world have implemented the various Agile development methodologies. Talking to hundreds of Scrum teams, our conclusion is that Scrum can and should be flexible. A team can choose the best out of each world as mentioned above. To reflect this, below you can see some interesting data that we have gathered from our conversations, around the elements of the different frameworks that were adopted by dev teams around the world: