Manifestations: Scrumban Demystified
- A Helpful Perspective
- A Framework for [R]Evolution
- Stop Drinking the Kool-Aid
- Let's Get Started
This chapter is from the book
This chapter is from the book
This chapter is from the book
- I estimate that 75% of those organizations using Scrum will not succeed in getting the benefits that they hope for from it . . . Scrum is a very simple framework within which the “game” of complex product development is played. Scrum exposes every inadequacy or dysfunction within an organization’s product and system development practices. The intention of Scrum is to make them transparent so the organization can fix them. Unfortunately, many organizations change Scrum to accommodate the inadequacies or dysfunctions instead of solving them.
- —Ken Schwaber, co-creator of Scrum
Scrum is an incredibly simple, effective, and popular software development framework; its value increases as teams and organizations develop their understanding and application of its core principles and practices.
Despite its simplicity, Scrum can be difficult to master. While it empowers both individuals and teams to discover factors that impede Agility and address how they should be tackled, it relies on their collective motivation, effort, and capabilities to make this happen. An entire industry now exists around delivering services to help individuals, teams, and organizations rise to higher levels of capability.
Scrumban is also a simple framework. It’s a relative newcomer to the world of software development and has yet to fully evolve; it’s also often misunderstood by people in Lean and Agile circles. Many people have never even heard of it. Some believe it to be nothing more than using virtual kanban systems within the Scrum framework, while others believe it to be a new software development framework that combines “the best” elements of Scrum and the Kanban Method. Neither of these viewpoints captures the true essence of Scrumban.
A Helpful Perspective
In the early 2000s, Alistair Cockburn introduced “Shu-Ha-Ri” to the software development world. It provided a way of thinking about the three distinct phases people pass through as they master a new skill or concept. Cockburn borrowed this concept from Japanese martial arts and believed it could be effectively applied within the context of improving software development processes and practices.
I invite you to embrace a learning style that is loosely based on Shu-Ha-Ri in learning to understand Scrumban. Let’s quickly review the three stages:
- Shu (Beginner): The first stage of learning. New learners seek to reproduce a given result by following a set of instructions that are practice focused. They focus on how to perform a task with a basic understanding of the underlying principles. Success in this stage is measured by whether a procedure works and how well the student understands why it works.
- Ha (Intermediate): Once a student has mastered basic practices, values, and principles, he or she begins to identify the limits of these practices and techniques. The student seeks to expand his or her awareness of alternative approaches, learning when an alternative applies and when it breaks down. Success in this stage is measured by how well the student learns to apply adaptive capabilities to varying circumstances.
- Ri (Advanced): The student has become a master. It no longer matters whether he or she is following a given procedure or practice. His or her knowledge and understanding are the product of repeated thoughts and actions. The master has developed a fully adaptive capability within the context of his or her experience in the environment. Success is measured by consistently successful outcomes.
Informed readers should not confuse the concept of Shu-Ha-Ri with something like Carnegie Mellon University’s Capability Maturity Model Integration (CMMI) process improvement training and appraisal program. Those who adopt and practice Scrumban principles would not be as inclined to direct harsh criticisms at the model as have some individuals in Lean and Agile circles.
Although I disagree that CMMI’s prescribed “destinations” or “characteristics” correlate with capability in all contexts, this model does present a menu of potential catalysts to employ in a Scrumban framework when pursuing desired business outcomes. Viewed from the opposite direction, the flow management capabilities that Scrumban enables may provide a useful catalyst for organizations pursuing prescribed levels of CMMI capability to achieve their desired outcomes.