Within any methodology that has been around for some time, competing camps will inevitably arise within the system. While scrum is easily the most popular method used for moving projects through to their completion within an Agile environment, an older idea, taken from the Japanese model of Lean production, or Kanban, has seen a resurgence. Whereas Scrum breaks projects down into small pieces allowing a team to focus on one task at once, Kanban sees projects as part of a more significant flow.
Both have their advantages, particularly for different types of participants and projects. However, each has its drawbacks. To combine the best of both, a new hybrid of the two, known as “scrum-ban,” has begun to take hold.
To understand how Scrumban will work well for your organization, let’s first look at Scrum and Kanban separately and identify their strengths and weaknesses.
Scrum: What it is, Strengths and Weaknesses
Scrum Process
Scrum takes its name from the game of rugby. In rugby, when there is a restart of a match (usually after a penalty), the players from both teams all lock together at once into a “scrum” and attempt to gain control and move the ball to their advantage. For a scrum to be successful, all players must coordinate very closely with each other, and only by cooperation can they achieve success in moving the ball down the field. It is, by definition, an extreme example of team cooperation. All players work together, and if one player cannot fill their role, others should be able to perform the same task to make the process functional.
Scrums in Agile are comprised of small self-organizing teams. Members have multiple tasks, and cross-functionality is crucial. A scrum is divided into small, deliverable project segments, known as sprints. Every team member works cross-functionally where goals are minimal and clearly defined. Whereas the scrum in rugby does not constitute the entire game, each project sprint in an Agile scrum refers to only that particular part of the project. It is discrete and defined. The goals are clear, and there is no variation within that sprint until a specific task is completed.
Each story (or task) within a sprint is separated by effort, priority, and expected length of time to complete, with individual sprints defined by the project owner. Much like the scrum in rugby, the entire team focuses on this element together, with a set time duration. Communication is maintained through required daily standups, where each team member reports on their process so that all team members can be aware of the process as it continues.
Scrums in Agile are designed to enable teams to work effectively and efficiently based on ongoing and changing project needs. The components of Scrums involve the following
- Creation of project backlog – A wishlist of tasks waiting to be prioritized
- Sprint planning session
- Sprints – Reusable and potentially releasable product increments
- Sprints are organized into 1-4 week long fixed-length development cycles
There are some clear advantages to the Scrum approach:
- They enable quick completion of deliverables
- They are designed to make effective use of time and money
- Projects are divided into easily manageable segments (sprints)
- They are suitable for fast-moving projects
- They provide good awareness among scrum members about what is going on with a project by the entire team (through standups)
- They are designed well for adopting feedback from stakeholders and customers
However, Scrum also has a few disadvantages.
One of the flaws in Scrum is ironically similar to the game from where it takes its name. In a scrum, if one team member fails to live up to their role, while theoretically other players can cover for this weak link, the entire project can fail if it is not executed perfectly.
Here’s a brief list of problems reported by people using Scrum
- Because of no clearly defined end date for an entire project, there is some danger of scope creep
- Uncooperative individuals can increase the risk of project failure
- As sprints do not allow contributing new stories to a sprint unless they are completed, and other sprints cannot begin unless the previous one is completed, this can stall a project
- It cannot be easy to implement for large teams
- It is only successful if everyone is up to par and experienced
- Daily standups can become irritating for some members, as they can become repetitive
- It can be challenging to control quality unless aggressive testing is applied.
Kanban: Strengths and Weaknesses
Kanban Board
Based on the Japanese project management design known as “lean” or “just in time” manufacturing, Kanban emphasizes continual delivery without overloading the development team.
In Kanban, there are no prescribed roles; work is pulled through the program in a continual piece, and the entire project is delivered as one. All planning, work, review, and measuring of outcomes is a constant process. Kanban is designed to recognize problems that occur along the way and can change based on any flaw identified. As a result, it is theoretically less chaotic than other processes and generally gradual and non-disruptive.
Measurement is structured in “lean time,” or the average time a project takes from when it is requested to be completed. Each process is designed to minimize the entire project’s time.
Flow within Kanban is managed by WIP (Work in Progress) limits, which are limitations controlling the number of task items being worked on by a team at any given moment. WIP limits help complete single (or smaller groups of) tasks faster. The WIP limit on the Kanban board helps identify process blockers.
A good way of thinking about this is imagining the workflow as a stream; each task is a log floating down the stream. If too many records get into the stream at one time, this can create a log jam, and no work can be continued; you get a block. In Kanban, WIP limits prevent new tasks from entering the stream until previous ones are completed.
The advantages of Kanban include the following:
- It provides a model of how work can be accomplished accurately
- The Kanban board drives standupsrd and unlike Scrum standups, they focus specifically on deliverables, not only individual tasks
- Kanban does not need formal stories; the intent is to keep the flow going
- Compared with Scrum, there is less formality/ceremony and overhead
Some disadvantages reported about Kanban include the following:
- It is tactical and not strategic and can result in a poor long-range view
- Kanban doesn’t have a good way of tracking well against goals
- Kanban has more focus on how tasks should be done rather than how they are being accomplished
- In reality, it cannot be easy to enforce WIP limits
- It doesn’t work particularly well if teams have remote members, as they cannot see the board (note: this is not difficult to resolve using some excellent online tools)
- It is poor at breaking down tasks into usable chunks
Scrumban: Best of both worlds
We can see some definite advantages for both Scrum and Kanban; however, as we can see, there are problems with each. The solution to this may be Scrumban.
Scrumban is a process that combines the best of both approaches while theoretically avoiding individual flaws. Agile teams who regularly use Scrum can apply some of the principles of Kanban to understand better how the entire process is working. Instead of focusing purely on the sprint, teams can spot places where there may be bottlenecks or blocks before they occur and develop better predictability for the entire project, reduce the amount of time required to complete a project, and reduce the chances of scope creep.
To get a clearer picture, let’s look at the most significant differences between Scrum and Kanban.
Scheduling, iteration, cadence
- Scrum is rigid and very schedule oriented; individual sprints must meet the preset timeframe by the scrum master
- Kanban is not limited to time boxes; it is iterative, and change occurs evolutionarily
Roles
- Scrumms roles include product owner, scrum master, and team members. All team members must be able to share skills; cross-functionality is crucial, and al,l members have the resources to complete sprints.
- With Kanban, cross-functionality is not necessary. While all teams in the project use the flow, generalists and specialists can be in different groups.
Board
- In Scrum, columns are associated with periods for workflow. More sprints can be added along the way. Final results are dependent on completed sprints.
- In Kanban, columns are limited by the number of stories within the workflow. The board does not need to be reset; new columns are added if more work is required. The flow will continue as long as the project is still in process.
The Scrumban Process
Given the advantages and disadvantages of each, we take the prescriptive nature of Scrum to keep it agile and easily divided into workable pieces, including the cross-functionality of team members. We then combine it with the process improvement method from Kanban, which will allow continual improvement of the process as the project progresses.
The most significant difference is in the board itself. We change the pull order of items. While in Scrum, the order of the sprint planning process and all tasks are pre-set before working, this can cause a level of rigidity that can result in skipping problems that arise during the process and, therefore, may never get addressed before the release.
One of the most significant advantages of lean production (aka Kanban) is that problems are identified throughout the process and can be identified before reaching the endpoint. The quality of the final output is generally better. However, as Kanban can leave too much up to team members to choose their workflow, this can result in pieces not getting completed in a timely fashion, particularly if one task is awaiting the completion of another. However, it does allow a smoother transition to a final goal without getting bogged down in individual sprints.
The main trick with Scrumban is to increase the pool by adding a new area into the existing Scrum workflow.
This is resolved in Scrumban by adding another column to the board. The structure is maintained, but the option of adding in more items is handled by creating a “ready” pool after the backlog. As Kanban limits the WIP, this requires adding another column to the queue behind the backlog and then controlling the backlog with WIP limits. Items move from the Backlog into a “ready” pool.
The new “ready” column should also have a WIP limit, as it can reduce the likelihood of making mistakes for each iteration of work within individual sprints. If a sprint is completed faster than in the time initially designated, it makes it possible to move on to the next one without a lengthy planning process; the items already exist in the backlog as soon as space has been made by adding others into a sprint.
This advantage is that it adds the flexibility that Kanban can allow yet still pushes sprints efficiently toward a product release. As a result, it increases the number of items that can be processed at one time, and it is a lot easier to manage the team’s capacity versus the need and to be able to monitor the lead time.
Work can be done together, but this helps resolve one of Scrum’s most significant issues, scope creep. Work is still being handled in scrums, but the flow is managed with a more straightforward guide toward the more extensive project end.
Major Advantages of using Scrumban
Allows continuous improvement of the workflow by learning from the past.
Whereas Scrum is focused on pure workflow, making changes is challenging once a sprint is in place. However, within Scrumban, if a developer during another sprint notices a problem, not only can they modify the current sprint (by adding essential pieces into the flow), this knowledge can be shared across other sprints to improve the entire process.
No limits on the size of stories brought in to the board.
In Scrumban, stories can be larger than the normal one, two, or five-bar size; this allows bringing in stories that may have come from another sprint or epic, even if it wasn’t planned.
Ensures continuous flow of work.
Work no longer needs to stop if a developer has completed her part of a sprint. She can move on to the next task without waiting for a new sprint to begin.
Allow for Specialists
The team can remain cross-functional; however, there is also space to allow for specialized resources. Sometimes a developer or Ops professional may have skills not necessarily shared by others in the group. His work within a sprint may be minimal compared to others, but he has other tasks that need to be accomplished. In Scrumban, he has no reason to sit on his hands while everyone else finishes their roles. By bringing this person’s tasks outside of the individual sprint, he can work in his stream alongside existing sprints.
Conclusion
Scrum and Kanban offered ways to drastically improve moving projects from initial idea to completion over previous “waterfall” methods. While both approaches have positive features, inherent flaws can cause problems down the road. By combining the best Agile and Lean models of project management to create Scrumban, many of these problems can be alleviated and move toward a better method for designing efficient project management tools and effective results.
Also Read: WHEN TO CHOOSE BETWEEN KANBAN, SCRUM OR BOTH
