- 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
Stop Drinking the Kool-Aid
Mike Cohn, a leader in the Agile/Scrum community, recently “criticized”3 Scrum teams for not being “focused on finding innovative solutions to the problems they [teams] are handed.” He wasn’t actually criticizing Scrum; rather, he was criticizing a mindset that has evolved among Scrum practitioners—a mindset that favors a safe approach to completing work over innovation.
I see a related phenomenon in my coaching engagements. The biggest impediment to improvement often lies with team members who are either unable or unwilling to think about improving the way work is done (or how their work is relevant to creating business value).
I believe the problem runs even deeper than this. A cult of Scrum has arisen that permeates the industry that has developed around Scrum. Not only are Scrum practitioners failing to pursue innovation in their work, but they are also failing to pursue innovation in the process. Scrum has evolved over the years as new information was discovered, yet there seems to be a growing resistance among its most ardent practitioners to reflecting on how to support its fundamental purpose.
I saw this reluctance most recently during a presentation to an Agile community in Boston. At the beginning of the presentation, I asked the audience how many of them were using Scrum in their environments. About half the audience members raised their hands. Then I asked how many had experienced challenges in adopting Scrum in their organizations. Not a single hand went down.
As I began describing some of the alternative ways Scrumban enables teams and organizations to achieve their desired purposes, debates erupted over whether prescribed or popular approaches associated with Scrum were ineffective. Despite my repeated emphasis that Scrumban simply represents alternative or additional paths when some aspect of the Scrum framework isn’t fulfilling its intended purpose in a particular context, the majority of people in the room—even those who acknowledged challenges with their Scrum adoptions—were more interested in defending their existing process than in considering whether an alternative approach could help them overcome a challenge.
This cult-like mentality is not limited to the Scrum community. Pick your method or framework, and you’ll find a lot of similar behavior—even in Kanban.
Fortunately, most day-to-day practitioners are pragmatists and realists. Simple pragmatism and a willingness to experiment are why Scrumban has evolved to become the framework described in this book. Unfortunately, there will always be a fringe set of “thought leaders” who perpetuate framework debates because they are unwilling to promote the benefits of an approach that “competes” with models in which they’ve invested significant amounts of both time and money. Scrumban may be somewhat less threatening because of its familiar elements, but they will criticize it anyway.
Scrumban is a framework that almost forces its practitioners to accept the reality that good ideas can come from anywhere. It encourages people to actively pursue this reality at every turn. The question readers must answer for themselves is whether they’re ready to accept this reality and embrace exploration, or whether they will remain trapped within a narrower perspective, justifying this mindset by the existence of a “debate” that is perpetuated more out of fear than out of fact.