Scrum and Kanban at the Enterprise and Team Levels

13 June 2014

Gene Gendel
Global Investment Bank


Scrum, as the most structured of all Agile frameworks, is a great way to ensure predictable, strategically planned, incremental product delivery. Scrum ensures good responsiveness to frequently changing market demands. Although nonprescriptive, Scrum clearly defines certain roles, responsibilities, and ceremonies.

Kanban, for the most part, is silent about certain aspects that Scrum suggests explicitly (e.g., team size, velocity, story point estimation, timeboxing, Scrum ceremonies, etc.). Kanban is less structured than Scrum. Being a true pull-based system, Kanban is a great work-flow visualization tool that can be effectively used for WIP management. It is a great tool to use in production support or the gradual redesign of legacy systems; business priority-driven new product development is not the main goal.

Writing by David Anderson on "ScrumBan" does not require any introduction. Neither do the concepts that he summarized in his article some time ago; here he swiftly summarizes how Scrum and Kanban can effectively complement each other.

This post describes two practical examples of how, by combining Scrum and Kanban processes, improvements can achieved at two levels: the individual team level and the enterprise level.

  1. Individual team level: Using Kanban pull-based work scheduling intra-sprint (Scrum)
    • As per Scrum:
      1. Maintain a product backlog that is prioritized, based on the business value assigned by the PO.
      2. Conduct regular sprint planning sessions to define the scope of each upcoming sprint.
      3. Forecast/commit work for a sprint based on established velocity trends.
    • As per Kanban (once a sprint is in flight):
      1. Start pulling work from the very first ("to-do") queue, based on the difference between the WIP limit and vacancy in downstream queues (pulling the initial few stories should be easy as vacancy would be always equal to WIP).
      2. Ensure that a team swarms around work (stories) in such way that in downstream queues, WIP limits are neither violated nor does the vacancy become too high.
      3. Treat an intra-sprint work flow as a "cyclic conveyor belt" that must never become too loose or too tight. Ideally, intra-sprint, throughput must be consistent at each queue (more complex, multiflow Kanban systems with various WIP queue limits are out of the scope of this discussion).

        To summarize, by using the principles of Scrum and Kanban together, teams achieve more precision in delivery forecasting. While Scrum's historical velocity helps in controlling WIP limits at the sprint level (sprint scope control), Kanban helps control WIP with more surgical precision at queue level. Effectively, Kanban helps optimize team swarming and therefore ensures gradual work flow from the beginning of a sprint to its end. Effectively, intra-sprint Kanban work flow management is the second line of defense to ensure the predictability of Scrum delivery.

  2. Enterprise level:
    • Visualize non-IT work using Kanban:
      1. Look holistically at the enterprise-wide activities that take place before a work request comes down to IT. Using queues, visualize all gates and decision points that the work request goes through before it comes to technology.
      2. Determine whether upstream queues are part of one common flow or represent distinct, converging flows (e.g., finance, legal, marketing, operations departments, etc.).
      3. Apply reasonable WIP limits to all upstream queues, paying particular attention to the point of converging flows. For example, if finance, legal, and marketing all flow into operations, then the WIP limit of the first operations queue must be high enough to accommodate three batches of work coming from finance, legal, and marketing.
    • Introduce a Kanban-versus-Scrum decision point before the work request comes to technology.
      1. If the work request is qualified as "new development," route it through the Scrum framework by having PO(s) review the work, enter it in a backlog, and prioritize accordingly.
      2. If a work request is qualified as "production support" (bug, improvement), have technology quickly triage it to understand its urgency and the cycle time required to complete it. If it is "quick kill" (depends on the definition of the "quick-kill cycle time" of a given organization), route it to a Kanban team or teams.
      3. If the work routed through Kanban turns out to be much more complex than initially expected and there is danger of the clogging Kanban flow, reroute it from Kanban to Scrum (channel it through the PO, backlog). This assumes that such rerouted work does not present "stop ship" urgency.

        To summarize, by using a Kanban-Scrum hybrid model at the enterprise level, a high degree of visualization and work flow control can be achieved much sooner than when work enters the technology space. This, subsequently, ensures a more predicable flow of work within the technology space itself. Once work enters the technology space, additional decision-making checkpoints can be applied to ensure that priority and complexity/size of work determine which Agile framework is being used for its completion. Rerouting should be an option.
More to come about how to optimize the use of technology resources to support both Scrum and Kanban models.


Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.



Article Rating

Current rating: 3 (1 ratings)

Comments

Hemant Gokhale, CSM,CSPO, 6/13/2014 6:04:23 AM
Nicely wriiten Gene. Thanks
Sekhar Burra, CSP,CSM,CSPO, 6/13/2014 6:42:26 AM
Gene..Well articulated..It is a good refresher

You must Login or Signup to comment.