My last blog article incited a riot among the Scrum purists.. Well, maybe not a riot, but it certainly invoked emotions and passions which I love... but what I don't love is how the Scrum faithful are increasingly resistant to critical thought and debate... so let me attempt to clarify my motives and objective in writing my last article entitled "Nokia Demise: More Proof that Agile and Scrum Are Merely Tools, Not Solutions."
The stream of comments I received prompts me to reference one of my favorite quotes from F. Scott Fitzgerald:
"The test of a first-rate intelligence is the ability to hold two opposing ideas in mind at the same time and still retain the ability to function."
Unfortunately, some who have posted critical comments may have missed the point of my blog post and, in doing so, have underscored why I wrote this intentionally provocative article.. to make us think, reflect, and if necessary course correct.
Interestingly, most who were critical demanded “proof” that Scrum is being promoted as a solution for innovation and organizational success. Proof enough for me is a simple web search… google the words “Scrum and innovation” and navigate the messages our clients are receiving around the implied and explicit promise of Scrum’s influence on innovation, and corporate success.
Some will dismiss my first proof point, ok.. fair enough, then consider this: our team at Gear Stream has conducted over 300+ in depth technical and behavioral interviews with experienced Agile and Scrum practitioners (averaging 4+ years of active Agile/Scrum adoption experience) during the last year of which, over half the candidates exhibited two or more of the following attitudes and skill deficits:
- “Scrum guarantee’s that teams will produce better software products and/or solutions... and in doing so the company will enjoy better business results”
- An Agile / Scrum candidate attitude that promotes the presumption that Scrum is the best "solution" for a client before seeking understanding around the context of how and why Scrum could or should be used by a client organization
- A resistance to ideas or thought that might place Scrum in a less than a positive light
- A lack of interest in quantitatively correlating Scrum execution to organizational success… “it’s about people, not process or tools..."
- A lack of process and organizational design skills.. specifically, the inability to recognize organizational constraints and demonstrate an ability to facilitate designs for introducing new work and organizational models for improving how work happens.. “If all you have is a hammer; then everything looks like a nail”.
At Gear Stream we assume perfection in human collaboration is elusive and that every new “collaboration model” we design, however improved, is merely a constructive step in a better direction. We LOVE Scrum and Kanban… we actively use, promote and coach clients through the application of both models (as well as custom process models and hybrids), but NEVER without considering the alternatives and certainly never with a promise that the implementation of these models will automatically improve overall corporate outcomes.
Rather than defending Scrum or challenging trivial facts, why don’t we debate the premise of my argument… Namely that Scrum is merely a tool, NOT a solution and that putting clients and organizational outcomes first means seeking ways to discover and deploy models for change that best fit a clients constraints, challenges, and goals and not assume there is one single, monolithic model that serves all equally well.
Posted by: Brad Murphy, Founder & CEO of Gear Stream. You can reach Brad via LinkedIn.
Interesting but...
Author Name: Craig
Brad,
Interesting points you make. And yeah, we all agree with you but there are just theoretical arguments.
Scrum, for example, is an integrated model that does what it says it does.
So if you need to increase customer interaction, increase developer focus on value, break down some ossified bureaucracy, etc, then scrum is your friend.
If you don't really know what your problem is, you can sill pull scrum out and yield operational benefits.
Cargo cults suck, yes.
But what better models have you found that are more widely beneficial than Kanban and/or scrum?
Scrum or an Elegant Alternative?
Author Name: Brad Murphy
Richard, I completely agree that anything that reduces the cost, time and risk associated with acquiring actionable insights is desirable. I also agree that when Scrum has the benefit of “ideal conditions/circumstances” that Scrum is likely to produce improvements to these outcomes. We both seem to agree that these outcomes don’t automatically lead to innovation and business success… this was a key point I had hoped to make in my article… I wasn’t attempting to marginalize the Scrum framework, but was simply pointing out that there isn’t an automatic correlation between cost/time/insight and innovation and success… they potentially influence each other, but they don’t guarantee these outcomes.
Additionally, I want to bring focus to the position many in the Scrum community take regarding an “all or nothing Scrum”… I actually agree with them… if companies are unprepared or Ill equipped to support Scrum as it was intended to be used, then companies shouldn’t expect the benefits of Scum… the response to this reality is where I diverge from Scrum evangelists.. when circumstances make Scrum unlikely to succeed, do you force change that will allow Scrum to flourish (especially if there is high risk of failure) or do you design a potentially more effective model based on the specific conditions present in a company, guided by Agile principles, organizational, human and process design skills. For us, designing an elegant, Agile aligned model for transformational execution that reflects the unique culture, strengths, weaknesses, constraints and market dynamics of a specific client always strikes us as the better thing to do… the all or nothing Scrum proposition strikes us as arrogant, lacking empathy and frankly , lacking the imagination and skill our clients hope that we bring to complex problems.
YMMV :-)
Scrum works - evidence please!
Author Name: Matt Evon
Petri, you have wide experience in implementing Scrum. Please, give dependable evidence from five companies that Agile, specifically Agile and nothing else, has
a) increased productivity, i.e. with same effort Agile produces more outcome compared to some other approach
b) improved quality, i.e. defect density during development and after delivery has decreased compared to some other approach.
I repeat: dependable evidence, not anecdotal, thanks.
If Agile does not improve productivity and quality, why bother?
Cut iteration cost to innovate
Author Name: Richard Leavitt
"...putting clients and organizational outcomes first means seeking ways to discover and deploy models for change that best fit a clients constraints, challenges, and goals..."
This seems very mom & apple pie, and easily defensible. So why all the hubbub, I wonder? Brad, I read your desire is to challenge anyone selling a panacea. Makes sense. Also, that solutions are context dependent. Right. Are there really lots of disagreements on these?
For my part, I DO believe there a couple of development behaviors that also are easily defensible:
- Cut the time and cost of producing a working iteration.
- Innovation comes from customer interaction.
Of course, these two behaviors support each other. Recall Apple started the Newton in 1987, and took 20 years before innovating the iPhone, seemingly "overnight."
If you accept my premise, then a fair question is, does Scrum cut the time & cost of iterating, so leading to more customer interaction, and therefore more innovative products? Seems like an easy "yes." Can other processes (custom, hybrid, etc.) do the same? Absolutely.
Will doing all this save a company with a faulty business model, tenacious competitors, poor market timing, etc? Maybe not, but if I'm laboring under these burdens anyway I'd want to
You're right, but your case is wrong :)
Author Name: Petri Heiramo
Hi Brad,
I fundamentally agree with you on your points here, but the reason I found your _first_ article "faulty" was because the case is wrong.
Nokia Phones has never been Agile, nor really tried to be one (there is lip service to Agile in there, but management doesn't approve Agile for real). So saying they failed despite of it is just wrong, because there is no "despite". I agree with you message, but you must choose a case that actually supports your point. Nokia Phones isn't it.
Yes, Scrum is just a _framework_ (not even a tool), so whether it helps you to solve your business problems is really up to how the organization uses it and if it chooses to fix the impediments revealed by Scrum. It doesn't _solve_ _anything_. The skill deficits you mention are good examples how Scrum (and Agile) can be understood in a fundamentally wrong way.
