Scrumban The Agile Manifesto written in February 2001 has proven itself to be a powerful declaration of vision that is holding

for more than a decade and guides innovation into self-organized teams. The manifesto contains twelve principals with four attributes that are referred to more often, and these reflect the essence of the spirit and vision: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan

More, the Agile practitioners have noted two axioms that are central to the agility efforts and are separated from the costly practices from the point of view of the past: First axiom: It is possible to split the work intro small iterations that bring value and that can be individually planned. Second axiom: It is possible to develop an iteration that brings value in a continuous flow from requirements until delivery. With all these guidelines to the path of agility, the selection and using a methodology (Scrum) and a set of management practices (Kanban) are decisions that must be made in the context of the commitment and the culture of the organization.

Scrum

There are many texts and blogs about Scrum, with details for curious practitioners, beginners or more experienced people. A base description would be: Splitting the organization into small, cross-functional, self-organized teams Splitting the work in a list of small, clear deliverables Splitting the time into short iterations of fixed length (usually from one to four weeks) with a potentially demonstrated, deliverable code after each iteration Optimizing the delivery plan and updating the priorities in collaboration with the client, based on perspectives obtained after inspecting the delivery at each iteration Optimizing the process by having a retrospective after each iteration Organization: roles: Product Owner, Scrum Master and a cross-functional development team Practices: ceremonies: daily stand-up, functional product delivery in small iterations of fixed lengths (Sprints), Sprint Planning, Retrospectives

Kanban

Kanban can be characterized as an incremental and evolving work system. Derived from the Toyota Production System (TPS) and introduced into the world of software development, a Kanban system is in essence a powerful set of practices and simple tactics. The term Kanban refers to a work unit that moves through the organizational workflow only when there the necessary capacity exists for addressing that work at that step of the process. Almost every Kanban definition as an administrative tool and workflow optimization starts with the next basic elements: Visualizing the workflow: a visual representation of the process provides an exact view of the work status activity (e.g.: to do, in progress, done). A Kanban board is used that has a set of columns that reflect the steps of the workflow. With this tool, the work and the workflow are made visible in order to make the activities and problems more obvious.

Work in progress: Kanban limits work in progress (WIP) through an explicit policy set by the team to promote quality, concentration and finishing work (e.g.: the team does not accept more than two simultaneous work activities for a single member).

Scrumban

What is Scrumban? The name appears to offer a simple response it must be a combination between Scrum and Kanban. Some people think that the rules of Scrum are a little too strict and that Kanban does not provide enough guidance when it comes to roles and when the planning and retrospective should take place. So the solution would be combining the two.

Scrumban represents the best elements from Scrum and Kanban where the key concepts of a team that works together to finalize the work (Scrum) and the quantity of limiting the work at an optimal value (Kanban) are combined into a methodology for a higher efficiency and visibility in the development process. There is nothing in Scrum that is incompatible with adopting Kanban. Nothing except the rule that states that the rules cannot be changed. If you can validate the fact that it would be more efficient to make planning more frequently or more rare, or decoupling the frequency at which the retrospectives are made to the frequency the reviews are made, then Kanban says that you should make that change. Scrum could also say that it is ok to make the change, but if you do, you are no longer working in Scrum. This is the key to what Scrumban represents. It is a process that is enhanced with Kanban, which probably is no longer Scrum. A part of the Scrum framework that is wanted to be changed (or maybe never used) because it is believed that the change is more appropriate, it brings more benefits or supports less costs than pure Scrum. Such processes were used to being called, somewhat derogatory, Scrumbut. Scrum is the more acceptable alternative, less pejorative, and more positive because it implies the fact that you are using Kanban. So, to reduce the confusion in discussions around this topic, a more acceptable Scrumban definition would be: Scrumban is Scrum or a process like Scrum that is enhanced using Kanban.

Scrum vs. Scrumban vs. Kanban

Scrum Partial visualization (input, output and in progress) Backlog Iteration fixed in time Sprint Planning Estimated work for Sprint

Scrumban Total visualization Backlog Depends on the teams decision (Scrum / Kanban) Depends on the teams decision Depends on the teams decision

Kanban Total visualization Backlog Continuous flow Dynamic Planning Minimal work estimation (estimated for flow)

Resetting the Board after Sprint Burn-down (Burn-up) Charts Work in progress (WIP) controlled by the Sprints context Changes treated only in the next Sprint Impediments are treated immediately Conclusions

Depends on the teams decision Depends on the teams decision Depends on the teams decision Depends on the teams decision Depends on the teams decision

Persistent Board Accumulative flow Work in progress controlled by the state of the workflow Changes added on the board (to do) Impediments are avoided

By spicing the Scrum process with Kanban elements, therefore resulting Scrumban, can bring changes in the teams efficiency and using the Kanban board provides a higher level of transparency. But is Scrumban better than Scrum? The answer to this question may vary from case to case, depending on the nature of the work the team is doing and the environment in which they are working. Scrumban can be an alternative to the Scrum process, if it applies better on the needs of your organization/team.

References: What is Scrumban?, Andy Carmichael, 2013 Implementing Scrumban, William Patrick Swisher, 2013 What makes Scrumban, Scrumban?, Thomas Cagley, 2013 Kanban as a Tool in the Agile Toolbox, Cognizant Technology Solutions, 2012