Agile Zone is brought to you in partnership with:

Software Developer, Mentor, Architect and UX/UI craftsman. Also, a psychology nut that loves curling. Zac is a DZone MVB and is not an employee of DZone and has posted 66 posts at DZone. You can read more from them at their website. View Full User Profile

Can Scrumban Work?

05.08.2014
| 12612 views |
  • submit to reddit

Scrum is an iterative and incremental Agile development methodology with consistent timeboxed "sprints" between 7 to 30 days.  A few artifacts from scrum include roles (scrum master, product owner, development team, etc.), backlogs, taskboards, burndowns, and velocity.  Before the initiation of a sprint, the team determines the items to be consumed from the product backlog.  During the sprint, the team absorbs the sprint work and carves out time to groom the product backlog for future sprints.  When the sprint ends the team demonstrates the work completed, discusses process improvements and begins the process of implementing another sprint.

Kanban focuses on continuous flow guided by the Lean methodology.  It has five core principles, which are: visualize the workflow, limit work-in-process, manage the flow, make process policies explicit, and improve collaboratively.  The last three principles are built on the first two.  A vital piece is the visual workflow, commonly implemented as a "card wall".  This can be a physical or digital wall displaying index cards or sticky notes with columns representing different states of the workflow.  Limiting the work-in-process is also essential in maintaining order and balance within the columns.  Kanban's encouragement of continuous flow lends itself to small, continuous, incremental changes.

Scrum and Kanban lead to the evolution of Scrumban.  Combine the two approaches and receive a sum that is larger than its parts.  When implementing Kanban it stipulates to "respect the current process, roles, responsibilities, and titles."  This lends itself to simple integration with existing systems; furthermore, Scrum and Kanban both champion continuous process improvement and self-organizing teams.  The big question is, "Can these two ideas coexist?"

Scrum is built on the foundation of specific roles and workflow.  Kanban's primary focus is continuous flow without interruption.  This can encourage the cannibalization of scrum.  A Scrum sprint backlog is not easily changed, while the queue of items in Kanban do not have any inherit restrictions (outside of WIP).  Yoval Yert provides an excellent article on "So what IS Scrumban?"  The end of the article documents how Scrumban has evolved in companies.  Yoval compares Kanban to a pit-stop in motor racing and states "the aim is to minimize the time it takes [between refuels]."  This focus clashes with the "clear the table" approach of Scrum cycles.  Teams have a tendency to shift towards Kanban's continuous output philosophy.  Additionally, Kanban's streamlined approach to limiting work-in-process helps teams achieve a higher level of focus and therefore most teams choose to eliminate sprint commitments.  Selecting Kanban over Scrum in these ares create less of a hybrid and more of a modified Kanban atmosphere.

The rise of Scrum and Kanban in recent years is part of a continuous journey by the software development industry.  Its quest is to find the best solution to increase output and decrease waste while providing better visibility and higher overall success.  Other methods such as waterfall, prototyping and unified process strive towards the same goal.  Each company's staff and culture are different.  A one-size-fits-all approach to product management is unrealistic.  The success of a methodology lays within the people and implementation.

Published at DZone with permission of Zac Gery, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)