Combining Scrum And Kanban: The Best Of Both Worlds
Scrum and Kanban software development methodologies are the subjects of permanent debates and choice among programmers. Both are popular Agile approaches, however, both have their own practices, principles, and concepts.
In fact, these styles of Agile project management are often mixed to satisfy IT companies’ needs and requirements.
In this article, we define the key Scrum and Kanban difference, describe the proper definitions for both methodologies and try to understand how to make switching from one method to another painless and efficient. Let’s dive in!
Quick Kanban intro
Kanban methodology is a system that came from the manufacturing industry. It was invented in the 1940s by the employees of Japanese corporation Toyota. At that time, the company had lots of problems with product delivery, so its managers decided to invent a new project management system. It was based on three principles: consideration of customer demands, visualization of workflow, and limitation of work in progress.
These three principles are now applied to the software development industry. Kanban is considered one of the most applied Agile methodologies because it is based on strong customer involvement in the process of project realization.
According to the Kanban concept, a Product Owner is responsible for gathering user stories and prioritizing them in the product backlog. The team cannot influence him/her or reprioritize stories. In modern Kanban teams, digital Kanban boards usually visualize the work. Their columns depict all stages of task performance and convenient Kanban cards include all required information about each task.
The functionality of modern Kanban project management applications allows the developers to visualize their workflow in various forms, including charts, tables, and diagrams. It simplifies the work of the team and allows its members to forecast the results of their activities. The principle of work in progress limitation is also applied to modern software development. Kanban teams usually limit the number of tasks that are placed on the Kanban board at the same time. That allows them to perform all tasks more effectively and to focus on the quality of work.
If you need extra information to enhance your knowledge base, learn our Quick Kanban tutorial.
Quick Scrum intro
Scrum methodology is the most widely spread Agile methodology that combines the best Agile practices. Scrum teams are able to achieve the best outcomes when they use this methodology properly.
The method is based on iterative cycles, called sprints. Each sprint lasts 1-4 weeks and has its own backlog.
The sprint backlog is the number of tasks that should be performed during a certain sprint. The testing procedure is conducted after each sprint. That allows the Scrum teams to detect all defects in the early stages of work and to remove them before the product is delivered to the customer.
The range of customer involvement in the process of Scrum software development is very high. Product Owners participate in the team’s work constantly and prioritize the product backlog, providing advice on the future software. The customer can change the goals of the project or his view at the final software any moment.
Scrum or Kanban: How to Choose the Best Option?
For many companies, starting Agile means introducing a few new concepts and terms – without changing the way the work gets done, and then treat it as Agile. You should provide your team a possibility to follow a predefined agile procedure, and then – to monitor them about what items works and for whom.
A team that is adopting Agile may find it more useful to start with one model or framework, implement it as described, and then use retrospectives to evaluate where progress can be made. You should try to experiment with ideas from other frameworks and models instead of using just one. Agile development will enable you to uncover better ways to do your best work.
Choosing one of the most popular Agile approaches may be a real challenge. Actually, there is a smart way to find the winner into the battle Scrum vs Kanban – to combine both and perform in accordance with Scrumban concept.
Scrumban was created to meet team needs in minimizing the batching of work and adopting a Pull-based approach. The hybrid of two Agile methods provides software development teams with the flexibility to adapt and change to stakeholders and production requirements without overburdens.
This is a versatile approach to workflow management as it provides the full Scrum structure with the visualization and flexibility of Kanban.
However, let’s get back to choosing one of the classic methods.
Iterations Types
In some cases, Scrum may seem as not the best choice. The most common situations are the small projects when the number of team members is less than four, or when it is impossible to plan even one iteration in advance. It is often the case when teams are dealing with solving bugs, system maintenance or escalation by end-users.
For the teams that produce new product versions on pre-defined intervals, and which try to adapt to the dynamic marketplace, Scrum is an obvious choice. Scrum defines a clear number of roles, rituals, and artifacts that can be accepted and used instantly.
Scrum is flexible enough to support teams as small as 5 and can cover corporations consisting of several hundred people. It provides self-determination for the developers, transparency for the managers and responsibility for the entire company.
Scrum is optimized to produce product iterations (to the clients’ side) on a regular basis, and Kanban provides a permanent set of autonomous results and deliverables. The key advantage of Kanban is that it can control the size of work the team has in progress at any moment of time.
Both Scrum and Kanban prosper from well-defined user stories that can be accomplished and delivered separately, and Scrum leaves the decision to the team – how much to work on the same time while Kanban focuses on limiting the number of items the team has in progress.
A key difference factor is that Scrum measures the levels of teams’ productivity in terms of the team’s speed, and controls how many agile points a team will score during a sprint. Kanban controls for continuous work in progress and limits the number of stories the team will accept to working on at the same time.
Transparency
Scrum and Kanban have accepted the practice of daily stand-up meetings during which the team members will report on what they’ve done since the last stand-up, what are their plans for the next sprint and whether they have any problems that obstruct them from working to their fullest capacity.
In both methodologies, the developers are those ones who should report during the meeting, and product owners and managers make the attention and use the time immediately after the meeting to follow up on specific items.
Scrum will provide the team with a complete sprint to decide how to manage itself before the next stage while Kanban carefully observes the process through the team every time a new story is started. This has a large implication on the way that managers (masters), product owners and developers work combined. With Kanban, the team can adapt the work (its progress level) dynamically to avoid free or over-worked developers, and that is something that can be monitored by the management.
Scrum limits the changes during the iteration, and Kanban is open for scope changes at any time. Scrum limits the communication with the “business” and refers to the product owner while Kanban insists on the active participation of the “business”. Scrum defines roles in the system (SM, PO, Dev), while Kanban does not have roles, and is open to team extension at any time.
Self-managed teams
The crucial aspect of the success of Scrum and Kanban is that development teams direct their own work, guided by the business goals. Both methods promote respect for people, allowing them to do their best work, providing the leaders to help remove obstacles to ongoing progress. Team members of both Scrum and Kanban projects manage their own work packages. They define their own rules for determining when a user story is ready to put into production.
Both Kanban and Scrum teams ‘get the work’, rather than asking managers to assign tasks to team members. Scrum teams take the high – priority user stories from the corporate product backlog, separate them down into small tasks, estimating the tasks and stopping when they’ve reached the amount of work to which they can commit for that time period. Instead of planning the iteration in advance, Kanban teams define how many user stories they can work on at any given time.
Scrum will provide the team a complete sprint to decide how to manage itself before the next stage, while Kanban carefully observes the process through the team every time a new story is started. This has large implication on the way that managers (masters), product owners and developers work combined. With Kanban, the team can adapt the work (its progress level) dynamically to avoid free or over-worked developers, and that is something that can be monitored by the management.
Work packages
The most obvious difference between Kanban and Scrum is in limiting work in process, versus a clear number of roles, rituals, and artifacts that can be accepted and used instantly. In practice, though, there can be only a few differences.
Both Scrum and Kanban prosper from well-defined user stories that can be accomplished and delivered separately, and Scrum leaves the decision to the team – how much to work on the same time, while Kanban focuses on limiting the number of items the team has in progress.
Scrum does not limit the work in progress, but if you start too many stories – you may not produce useful deliverables at the end of the Sprint. A key difference factor is that Scrum measures the levels of teams’ productivity in terms of the team’s speed, and controls – how many agile points a team will score during a sprint. Kanban controls for continuous work in progress and limits the number of stories the team will accept to working on at the same time.
Scrum is optimized to produce product iterations (to the clients’ side) on a regular basis via user stories, and Kanban provides a permanent set of autonomous results and deliverables. The key advantage of Kanban is that it can control the size of work the team has in progress at any moment of time.
Planning approach
Scrum’s approach asks for estimating stories and tracking team velocity, and the number of user stories that are done in each sprint. However, all Agile teams need a way to help the business plan when some features should be produced, knowing that plans always change.
Some Kanban teams count how many features were produced in a week, or the average time to produce each minimum deliverable feature. Others accept a Scrum-like approach for estimation and measurement. Kanban teams may hold planning meetings as needed, to prepare more stories for development, or they may plan at a regular frequency, as Scrum teams do.
Scrum uses a product backlog of user stories, whose cost should be estimated by the development team, and which are prioritized by the company. If the backlog isn’t populated actively, the removing stories will never get to the top of the priority list, and it becomes a problem.
When the team is ready to practice Scrum for several years, you should plan two big boxes for the story cards, that are going to be pulled into a sprint. That’s not a way to make business value visible.
In Kanban, the team can adapt the work (its progress level – Lean approach) actively to avoid free or over-worked developers, in a way that can be monitored by the managers.
Agile bad practices worth to minimize
Of course, there could be some bad practices that you can personally face about Agile organizations and teams:
User stories in the sprint can be changed
Sometimes the user story has the same size and has increasing importance, but it should not be changed with a less important story. In some cases, the story could swap during the sprint, but not to entirely change the initial requirement.
When the sprint starts, the scope is sealed and a change in the needs will imply that the sprint is invalid, as the goals of the sprint have changed.
Regular team meetings
One of the bad practices is when the Scrum master asks for frequent status updates from the team members. This is very unnatural to Scrum since it looks like a micro-management. Scrum needs spontaneous, energetic, and involved participation from all team members, with the scrum master defining the time/content and product owner listening in for potential questions and unclearness of stories. A good way to abandon this practice is to make standup meetings optional until the team decides to meet and learn together.
Unclear, incomplete user stories
Agile methodology provides software with no defects, with the assumption that the product owner has expressed his/her intent completely and clearly. Stories that don’t have acceptance criteria – bring misunderstanding to everyone, or cause continuous arbitration throughout the sprint, thus lowering the quality and the speed.
A good way to prevent this from happening is to close the sprint and immediately close a story that has no acceptance criteria. Product owners should adapt, since their budget is limited.
Product Owner is also a developer/team lead
Product Owner should determine the objectives and goals of the project together with the client, and not directing engineering tasks. There could be cases where a product owner could be in the advisory board. Defining how to do the work does not only wastes the time of a product owner but also shifts focus away from the final goal.
Scrum master is the product owner. This case is similar to a pirate becoming a captain. Aside from daily dashing to the team and immediate lack of direction, the dictating nature of this role does nothing more than interruptions in the Sprint.
Automation is not always present
With no acceptance of testing running regularly, there is no proof that everything that worked so far is still working. Without testing, new development efforts will be unclear. Unclear results almost always float, disturbing the sprint. There have to be taken enough time and effort for automating tests and deployment.
Deliverables are not finished at the end of a sprint
Putting the product to production could be optional, but a deliverable that satisfies all user stories as a set is obligatory. Some teams, especially teams with short duration sprints, choose to have a consolidation sprint, before delivering the production.
Story points have a large duration. They are measures of the efforts, not in terms of time. Once you realize the abstract nature of software development, you will understand that work cannot be quantified in time, but only in complexity.
There are no software-oriented stories
This happens if the team has amazing technical capabilities or infinite hours in a day. Scrum allows patchwork, add-ons on existing software to incorporate new features. However, over a period, the team might end up with a fragile and uncontrollable product.
To prevent this from happening, it is important to have a consolidation sprint or have engineering stories in the sprint. However, aside to regular stories, these stories should have a well-negotiated purpose and the end.
Backlog cleaning is a weekly meeting
Product backlog cleaning (backlog grooming) is usually a non-interactive process, where development team uses the backlog as a knowledge base, permanently adding comments and updating story sizes, as they learn more about the product owner’s goals and intent.
There are some companies that disrupt the Scrum process, though few and far between. Scrum, or any similar Agile process, is a simple and Lean process that works for developing software. It also requires complete forgetting of traditional practices and willingness to accept it completely to make it effective.
Make an efficient Agile
It would be significant for your team to decide wisely which methodology will be most useful, given what is the type of your project. If you are creating products, you will find that Scrum is a more obvious choice. If you provide services, you will find Kanban is the better solution for you.
The basic feature of the Agile methodology is the possibility that your team will learn from the past work, so you can decide appropriately – what to maintain and what to change, as you adjust in an agile environment. If your team has worked effectively in an agile process long enough to know its own iterations, it is possible for a regular agile process to adjust to a wide spectrum of implementations.
It is recommended that you should define your desired type of Agile and use it in a predefined way for several iterations until you make a decision – it is good for you. In case that it doesn’t satisfy your needs, you can always take a turn and rethink your approach at the next Sprint.
