3

It seems to me that scrumban is just a form of Kanban with additional tools like the cadence, planning, retrospective, and daily standup thrown in. Why is scrumban turning into another branded methodology?

It doesn't seem to me that scrumban is taking anything away from the Kanban philosophy, its just a hybrid of scrum and kanban tools. What does scrumban do to differentiate itself from these other 2 models both in practice and theory? Perhaps another way to phase the question; how is scrumban different from any other Scrumbut approach?

4

What Scrumban Really Is

Fundamentally, Scrumban is a management framework that emerges when teams employ Scrum as their chosen way of working and use the Kanban Method as a lens through which to view, understand and continuously improve how they work.

Scrumban is distinct from Scrum in the way it emphasizes certain principles and practices that are substantially different from Scrum's traditional foundation. Among these are:

  • recognizing the important role of organizational management (self-organization remains an objective, but within the context of specific boundaries)
  • allowing for specialized teams and functions
  • applying explicit policies around ways of working
  • applying the laws of flow and queuing theory
  • deliberate economic prioritization

Scrumban is distinct from the Kanban Method in that it:

  • prescribes an underlying software development process framework (Scrum) as its core
  • is organized around teams
  • recognizes the value of time-boxed iterations when appropriate
  • formalizes continuous improvement techniques within specific ceremonies

Perhaps most importantly, the principles and practices embedded within Scrumban are not unique to the software development process. They can be easily applied in many different contexts, providing a common language and shared experience across interrelated business functions. This, in turn, enhances the kind of organizational alignment that is an essential characteristic of success.

A Framework for [R]Evolution

When Corey Ladas introduced the world to Scrumban in his seminal book, Scrumban: Essays on Kanban Systems for Lean Software Development (Modus Cooperandi Press, 2009), he boldly defined it as a transition method for moving software development teams from Scrum to a “more evolved” software development framework. In actual practice, however, Scrumban has itself evolved to become a family of principles and practices that create complementary capabilities unique from both Scrum and the Kanban Method. These capabilities have led to three distinct manifestations:

> As a framework that helps teams and organizations effectively adopt Scrum as a development methodology.As a framework that helps teams and organizations overcome a variety of common challenges scaling Scrum across the Enterprise.

As a framework that helps teams and organizations develop their own set of Scrum-based processes and practices that work best for them -- not to accommodate inadequacies and dysfunctions Scrum exposed, but to resolve them in a manner that was most effective for their unique environment. I believe these different manifestations have arisen because teams and organizations are acutely aware of all the great things an underlying Scrum methodology brings to the table. These include capabilities like: * fostering a team-based focus to facilitate the alignment of purpose and vision * enhancing performance and the adoption of change through cadence and rhythm * helping to enforce a focus on shorter term planning as compared to more traditional methods * emphasizing customer participation and the delivery of value from customer’s perspective * enforcing a focus on smaller sizes of work * enabling collaboration * promoting shared ownership and cross functional capabilities

On the other hand, too many of these teams and organizations face challenges in effectively adopting Scrum for which the framework lends little guidance. These include challenges like:

  • effectively managing around the variability and unpredictability inherent in the nature of our work (especially, in many contexts, around its arrival)
  • deliberately addressing longer term considerations such as architecture
  • overcoming psychological barriers to change and implementation
  • achieving uniformity in the effectiveness of the Product Owner role and how to scale the function performed by this role across larger enterprises
  • relating market risk to Sprint Commitments
  • eliminating traditional reliance on deterministic planning
  • minimizing reliance on top down/vertical buy-in with affirmations of servant leadership

http://www.informit.com/articles/article.aspx?p=2431512&WT.mc_id=Author_Reddy_Scrumban

2

Scrumban is a slang term, not an codified process, so it's hard to say exactly what it is. However, I can say that I see a lot of success in Scrum teams that adopt some of the principles and practices of Kanban. Some of those that help Scrum teams include:

Visualize Your Process: Many Scrum team task boards simply read Ready-Doing-Done. This rarely reflects the complexity of how many organizations develop their product. Creating a more accurate representation of how work is done will allow you to see bottlenecks and areas for improvement easier.

Implement WIP Limits: Many studies show that there is an optimal number of items that can be in progress at a time. Trying to have the whole team work on one thing can lead to everyone stepping on each other's toes, but having too many things in progress means nothing gets quite done until the end of the sprint. WIP limits help the team find and enforce that balance.

Measure and Monitor Flow: I see more and more Scrum coaches suggesting you measure cycle time. I don't think this is as important in Scrum as it is in Kanban, but it can tell the team a lot about what's happening in their work. Lead time can also be really interesting for the product owner in thinking about how they are managing their backlog.

'Agreeing to Pursue Incremental Change' and 'Leadership at All Levels': These are two of the core principles in Kanban and are very compatible with Scrum. Scrum has a ceremony for self-reflection and continuous improvement, but it's pretty open-ended about how you do that. Kanban can provide some guidance here - especially for new teams.

I'm sure there are others I'm not thinking of at the moment. If I remember any, I'll edit the post and add them.

2

I'd put it slightly differently. Scrumban is the (by now) fairly well-established term being used by many experienced/ respected thought leaders in the Lean/ Agile industry for work done by teams when they apply Kanban principles to their Scrum-based software development work. The basic premise of Kanban is to help teams improve, whatever be their method of software development planning and delivery. Teams may choose to continue to call it Scrum or may switch to Kanban or Scrumban.

Besides the article Ajay Reddy pointed to, here are some good references to Scrumban -

The most well-known and respected one - "Scrumban - Essays on Kanban for Lean Software Development" by Corey Ladas (http://www.amazon.com/Scrumban-Systems-Software-Development-Cooperandi/dp/0578002140)

Another good article is by Yuval Yeret - "So, what is Scrumban?" (http://yuvalyeret.com/2012/04/28/so-what-is-scrumban/)

A couple of articles with our own take -

"What is Scrumban?" (http://www.swiftkanban.com/kanban/what-is-scrumban/)

Also, here is a blog post I wrote when I asked pretty much the same question at a Lean Coffee session at the LKNA 2012 conference - http://blog.digite.com/scrum-kanban-scrumban-or-kanban-lessons-at-lean-coffee/

Hope this helps!

1

Scrumbut is not a methodology it's a term used when people pretend to be doing scrum or are unable to implement it properly due to organisational issues.

You could also think of Scrum but as a way of working whilst you are transitioning to Scrum

Any way don't get too bogged down with the methodologies concentrate on the agile principles and create something that works in your organisation.

1

Besides the differences mentioned before, I find that what really separates Scrumban and Kanban are the several rules that it takes from Scrum. While Kanban is loose and Scrum is strict, Scramban braces the middle and provides an option for a somewhat controlled Kanban process.

Instead of having no ceremonies whatsoever, Scrumban keeps the tradition of a daily scrum and an option to add any sprint meetings that the team feels necessary. The same goes with the process planning and while it is not mandatory to have sprints within Scrumban, the teams can opt out for them as they see fit. So while Scrumban is still a pretty loose process it brings in more control compared to Kanban and can be a great transitional point after Scrum.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.