Scrum and Kanban – How Scrumban can help

Scrum and Kanban – How Scrumban can help

by Anand Suresh

Within any methodology that has been around for some time, it is inevitable that competing camps will eventually arise within the system. While as 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 larger flow.

Both have their advantages, particularly for different types of participants and projects, however each also has its drawbacks. In order to combine the best of both, a new hybrid of the two, known as “Scrumban” has begun to take hold.

To get an understanding of how Scrumban will work well for your organization, let’s first take a look at Scrum and Kanban separately and identify each of their strengths and weaknesses.

Scrum: What it is, Strengths and Weaknesses


Scrum Process

Scrum takes its name from 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 own advantage. In order 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 is unable to fill his or her 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. Goals are minimal and clearly defined. Whereas the scrum in rugby does not constitute the entire game, similarly each individual 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 members of the team 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 good for fast-moving projects
  • The 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 has also has 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 can be very difficult 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 difficult to control for quality unless aggressive testing is applied.
Kanban: Strengths and Weaknesses

strengths-and-weaknesses
Kanban Board

Based on the Japanese project management design known as “lean” or “just in time” manufacturing, Kanban emphasizes a continual delivery without overloading the development team.

In Kanban, there are no prescribed roles and 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 is generally gradual and non-disruptive in nature.

Measurement is structured in “lean time,” or the average time that a project takes from the time it is requested and the time it is completed. Each individual process is designed to minimize the amount of time for the entire project.

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 are designed to 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 of this is imagining the workflow as a stream, and a each task is a log floating down the stream. If too many logs get into the stream at one time, this can create a log jam, and no work is able to 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 how work can be accomplished accurately.
  • Standups are driven by the Kanban board. Unlike Scrum standups, they focus specifically on deliverables, and not only individual tasks.
  • Kanban has no need for 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 actually being accomplished.
  • In reality, it can be difficult 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

scrumban

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 which combines the best of both approaches while theoretically avoiding the individual flaws. Agile teams who regularly use Scrum can apply some of the principles of Kanban to gain a better view on how the entire process is working. Instead of keeping focus purely on the sprint, teams can spot places where there may be bottlenecks or blocks before they occur, and develop a 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 again at the biggest 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 into time boxes. It is iterative, and change occurs evolutionarily.

Roles

  • Scrums roles are defined as product owner, the scrum master, and team members. All members of the team must be able to share skills; cross-functionality is crucial, and all members have all of the resources to complete sprints.
  • With Kanban, cross-functionality is not necessary. While the flow is used by all teams in the project, generalists and specialists can be on different teams.

Board

  • In Scrum, columns are associated with time periods for workflow. More sprints can be added along the way. Final results are dependent on completed sprints.
  • In Kanban, columns are limited by number of stories within the workflow. The board does not need to be reset; new columns are added if more work is needed. 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 biggest 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 prior to working, this can cause a level of rigidity that can result in skipping problems that arise during the process, and which may never get addressed prior to release.

One of the greatest advantages of lean production (aka Kanban) is that problems are identified throughout the process and can be identified before getting to the end point.  The quality of the final output is generally better. However, as Kanban can leave too much up to team members to choose their own 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.

The way this is resolved in Scrumban, is by adding another column into 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 yet another column to the queue behind the backlog, and then control 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.

The advantage of this is it adds the flexibility that Kanban can allow, yet still push 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 the biggest issues in Scrum which is scope creep. Work is still being handled in scrums, but the flow is managed with a clearer guide toward the larger 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, once a sprint is in place, it’s difficult to make changes.  However, within Scrumban, if a developer during another sprint notices a problem, not only can he or she modify the current sprint, by adding important 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 having to wait 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 that are not necessarily shared by others in the group.   Often his work within a sprint may be minimal compared to others, but he has other tasks that need to be accomplished. In Scrumban, is no reason for him 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 own stream alongside existing sprints.

Conclusion

Scrum and Kanban both offered ways to drastically improve moving projects from initial idea to final completion over previous “waterfall” methods. While there are clearly positive features in both approaches, there are inherent flaws which can cause problems down the road. By combining the best of Agile and Lean models of project management to create Scrumban, many of these problems can be alleviated, and move toward a better method for creating not only efficient project management tools, but also effective results.

Anand Suresh is a Senior Technical Project Manager at Practical Logix. He specializes in bridging the gap between the technical and non-technical teams while maintaining budget, timeline and quality of projects.

Leave a Reply

Your email address will not be published. Required fields are marked *