I’ve been a follower of Scrum ever since I first heard Ken Schwaber present the subject at an XP user group meeting in Pasadena in ’04. Scrum has come a long way since then, boasting over 50,000 Certified ScrumMasters worldwide. Scrum is well beyond the innovator and early-adopter stages and firmly entrenched in the early-majority stage. People are no longer asking, “Will Scrum work?” but rather “How will Scrum work for me?”

Unfortunately, along with popularity comes dilution and permutation. Surrounding a core of solid, serious adopters lies a realm of half-serious adopters sometimes jokingly, but affectionately, referred to as “Scrum-buts.” You hear them say things like “We’re doing Scrum, but we’re not doing daily standup meetings,” or “We’re doing Scrum, but we can’t track velocity because the iteration work keeps getting interrupted with support calls.” Scrum purists would say that these people are missing the point of Scrum. That the full measure of benefit from Scrum cannot be realized by adopting it piecemeal.

I used to be that kind of a purist, but I’ve changed. I still say that the full measure of benefit from Scrum cannot be realized by adopting it half-heartedly. But I do allow for the thoughtful substitution of the parts of Scrum that don’t work for your environment/situation. Be sure to notice that I said “substitution” and not “elimination.” This is where Scrumban comes in.

Followers and promoters of Scrumban have noticed that one particular Scrum practice seems to be particularly hard for many organizations to adopt: the fixed 2-week, 3-week, or 4-week iteration. It may be that it’s hard to commit to work at the beginning of an iteration because the work is hard to estimate, or because it constantly gets interrupted with support and maintenance work, or because it’s hard to sync up with other parts of the organization. In such cases, the reactionary thing to do would be to simply to stop planning work in iterations and instead perform the work when and as resources become available. Scrumban says, that’s okay, but don’t throw out the baby with the bathwater. Don’t just drop iteration planning, but substitute in another way to track and manage the workflow — Kanban, in particular.

Kanban is a management technique that focuses on optimizing flow. It does this by monitoring “lead time” and “cycle time” and placing limits on work in progress (“WIP”). It was invented with assembly-line manufacturing in mind, but it is turning out to be well-suited for monitoring creative processes as well, including software development.

I used to advocate Scrumban for development teams that are charged with maintaining existing systems, while still recommending pure Scrum for new projects, but I’m backing down on that. I’m becoming more and more convinced that Scrumban is a better way to go all around.

Further Reading:

	Scrumban – Essays on Kanban Systems for Lean Software Development — How to develop software using Scrum, but by substituting Kanban for the fixed-iteration aspect of Scrum.
	Kanban: Successful Evolutionary Change for Your Technology Business — The seminal work describing how Kanban has been adopted from assembly-line manufacturing, to become suited for monitoring creative processes as well, including software development.
	Succeeding with Agile: Software Development Using Scrum — This book is the current “bible” for how to adopt Scrum. This, or the two seminal works by Ken Schwaber would be a prerequisite to reading “Scrumban.”