Until a few years ago, Scrum was considered the most efficient way of software development, but the method has started losing popularity, especially in its pure form (without elements taken from other methods, such as Kanban). As the world of software continuously evolves, it is becoming clear that the engineers of today need something different. The three main culprits that push programmers away from Scrum are:
The roles in Scrum. Some Scrum advocates will point out the roles as one of the great benefits of the method, but, in reality, they can be extremely limiting. The software industry is one of the most innovative and advanced in the world. It attracts some of the greatest minds of our time and such people are most productive when they are not limited by specific allowances and distinct roles. A person does not need to be a Product Owner to generate fantastic ideas about the future development of the product nor to be a Scrum Master to take the principles to heart, apply them, and share knowledge about the method. Assigning the full responsibility of something to a single person, or even a few people usually contribute to the forming of a “that’s not in my job description” attitude.
Commitment. Committing work and making fulfillment necessary is one of the heaviest burdens that dev teams applying Scrum experience. Although a successful sprint containing a record number of new features can be quite motivating, a few consecutive failed sprints can have the exact opposite effect. Formally, commitment has not existed in Scrum since 2011. The word was changed to “forecast” in the Scrum Guide, but the meaning and its implications remain the same.
Inapplicable in remote teams. In the 1990s, when Scrum was developed, distributed teams were not a common practice, but today’s reality is quite different. The Agile Manifesto states that “the most efficient and effective method of conveying information to and within a development team is face-to-face conversation”. Most Scrum teams prefer to stick to this principle, but a large part of them end up misinterpreting it. Face-to-face can very easily be achieved with the help of various communication tools and yet, the common Scrum practice is in-house development style.
Since the Lean revolution, more and more professionals are turning toward a new horizon, represented by the Kanban method. Scrum and Kanban are similar to some extent but, have some major differences. Both methods are empirical, focus on delivering software early and often, use pull scheduling, use transparency to improve the process and limit WIP (in different ways). The significance of their differences, however, is what defines their respective benefits and pitfalls. Differences include:
Unlike Scrum, Kanban does not have specific roles.
While Scrum relies on time-boxed iterations, Kanban allows teams to choose whether to do the work in regular cadences or deliver the finished goods as soon as they are completed. Each Kanban board has its own Takt time, a regular interval that defines the rhythm of delivering completed work.
Scrum WIP limits are applied for each sprint while, in Kanban, work is limited in each board.
Scrum boards are reset after each sprint, while a Kanban board is continuously used, which allows continuous improvement of the Takt time and clarity in the process structure.
Estimation is an essential part of Scrum, while in Kanban it is not a governing factor. In Scrum, teams fall into the trap of expanding the work so it can fit in the estimated time for completion, even if it can be done faster. With Kanban, there is no allocated time for a given task and the goal is for it to be completed as fast as possible with maximum quality. This approach motivates the team to perform at their full capacity all the time.
Last but not least, Scrum resists change on many occasions, while Kanban embraces and accommodates it. In Scrum, once the team has committed stories to a sprint, no member can add additional stories later on. In Kanban, you can add or change stories as customer demand changes, assuming that it’s within WIP limits.
It can be argued that Kanban is a natural continuation of Scrum that has adapted to an even more flexible, liberal way of development. Usually, the transition between the methods goes through a hybrid system using a mix of principles from both Scrum and Kanban. It is widely known by the name Scrumban. It is meant to apply the optimal, compatible traits of both methods. Although the hybrid is very customizable, it usually looks more like Scrum on a technical level and applies the cultural elements of Kanban and the Kanban board. Some of the following attributes, in various combinations, are incorporated in both Scrumban and pure Kanban implementations:
Iterations become optional, and, in many cases, are replaced with the continuous workflow that is a significant part of Kanban.
A Kanban Board is introduced to the process. Many Scrum teams apply Kanban boards to breaks down the steps of their workflow and act as radiators of information.
Roles are defined as needed by the team in order to reach maximum efficiency, but they are not as prescriptive as in the Scrum method.
Commitment becomes a personal notion and the need for consistent time estimation is removed. Development is not constrained in time-boxed iterations and the aim becomes one for maximum efficiency and quality of work.
WIP is limited to the available resources in each sprint. Unlike pure Scrum, Scrumban does not require for all of the work to be defined and planned at the beginning of each sprint. Instead, the team tries to finish as much work as possible, without compromising the quality of the end product.
Meetings continue to be an essential part of the team culture but, are simplified. The daily meeting between all members is adopted in Scrumban, but there are no planning and retrospective meetings. Instead, the work is planned on demand.
Change is reactionary to customer demand. In Scrum, when changes to the product are required, the actions for applying them are planned and worked on in a subsequent sprint. In Scrumban, reaction to changes is a matter of available resource, and the team can take action quickly depending on the priority of the requested change.
Scrumban introduces a metric other than velocity for measuring process efficiency. It is called cycle time and defines how much time a story takes to be completed from step one to the moment when a feature or product part is ready for shipment. The metric provides a better estimation of the project duration and resources necessary. In addition, cycle time helps in identifying problems and monitoring any deviations that indicate if the team is having difficulties with the story.
The hybrid method may be implemented differently in various development teams and sometimes may end up resembling Kanban more than Scrum. However, there are components that are typical only to Kanban in its pure form. For instance, in Scrumban there is a definite team and usually its members have specific roles like they would in Scrum while, in the pure form of Kanban, roles are allowed to be in flux. In addition, Kanban does not require meetings, but in Scrumban the daily stand-ups would be a mandatory practice.
Scrumban is a good halfway point on the way towards adopting pure Kanban. It allows Scrum teams to work with few time limits and achieve better results, if the method is applied correctly.
Scrumban and Kanban are both a perfect fit for Scrum teams who are struggling to complete their user stories on time, often feel that they sacrifice quality, or show indications of being overworked or underworked.
There are a number of common reasons that usually push teams to adopt Kanban over Scrum. Here are some wrong reasons for adopting Kanban that are not a good basis for your expectations.
Scrum does not fit the organizational structure of the team/company that adopts it. Scrum was never meant to cope with organizational structures to begin with. The method was designed with the idea to bring rapid change and increase efficiency on the foundation of the new structure it encourages. Although Kanban might seem easier to adopt because it does not require a significant change to the organizational structure, companies that struggle to cope with structural shifts might have trouble with the culture of Kanban itself.
Kanban does not require planning. Although planning is not a key success pillar in Kanban, it is necessary to some extent. Teams are not required to plan two months ahead, but without a clear idea of what needs to be done and without a realistic view of the Takt time of the flow, the pull system will end up getting blocked.
The Product Owner is not а suitable role and the team needs more freedom. This could very well be true, but there is one very important condition for Kanban to work in this case – motivation. The PO keeps the team in check and, although they might hold the members back in some cases, they generally contribute for the discipline and velocity of the work process. If the team is not motivated, the additional agility that Kanban provides my prove to be a downfall.
There is a single right reason for a team to betray Scrum for the sake of Kanban:
The desire to improve efficiency and deliver more. Kanban could really help you improve the efficiency of your workforce significantly, but the method will be powerless if there is no desire and effort from the team.
Scrum is an amazing method that has helped countless teams improve and achieve better efficiency. However, the method has started to lose popularity as some teams discover other approaches work better for them. The limitations on time and roles that come with Scrum are becoming a problem for more flexible teams as the software industry demands that teams be as adaptable to change as possible. The new star in the software sky is called Kanban and the number of teams gravitating towards it is increasing by the day. If you are considering to betray Scrum, be sure to understand the differences between the Scrum method and Kanban and, perhaps, opt for a middle ground between them initially. Last but not least, be clear why you would want to change and think carefully before making this decision with your team.