Scrum Fails?

Category Scrum 66 Comments

Last night an old friend from the Scrum Alliance told me that I’m being quoted as saying that only 30% of all teams and organizations that use Scrum will be successful.

I pondered this. I didn’t remember having said this. Perhaps this was an evolution of my having said that only 30% of all teams or organizations that use Scrum will become excellent development organizations. That fits with my memory.

Scrum is like chess. You either play it as its rules state, or you don’t. Scrum and chess do not fail or succeed. They are either played, or not. Those who play both games and keep practicing may become very good at playing the games. In the case of chess, they may become Grand Masters. In the case of Scrum, they may become outstanding development organizations, cherished by their customers, loved by their users, and feared by their competitors.

Scrum appears to have “crossed the chasm,” as Geoffrey Moore described. Scrum is now more mainstream than radical. Scrum is sometimes more a fad than a serious endeavor. When it is adopted, some of its practices are inconsistent with the culture of the team or organization. In response, the team or organization changes Scrum so it is consistent and fits in. For instance, some managers like their predictions of how much work will be done to be true, regardless. The teams in these organizations change the quality of a Sprint’s increment so the predictions become true. Some managers like to believe that a team or organization will only succeed through the application of their own and only their own intelligence and insights. Self-organization of teams does not occur then.

There are many adaptations or modifications of Scrum by organizations. I’ve called them “Scrum buts.” I ask someone if they use Scrum. They respond, “Yes, we use Scrum – but, our manager believes that we will fail if he doesn’t tell us what to do, so we are told what to do and how to do it.”

So feel safe. Scrum will not fail you.

Good journeys.

66 thoughts on “Scrum Fails?”

  1. Great post Ken.
    > Scrum and chess do not fail or succeed. They are either played, or not.
    This is an important statement. Scrum doesn’t succeed or fail. People do. When the framework AND the spirit of Scrum are wholly embraced, great things happen. I have seen this. I have seen the inverse of this too, and as you describe it is when egos and control issues get in the way, and break the self-organization principle.

  3. Great post.
    I think that many teams who fail to note the difference between working ACCORDING to Scrum, and working IN ACCORDANCE with Scrum.

    Scrum is “merely” a framework for implementing one’s development process. There are some hard rules, but between them, anything that work for one’s team is good.
    Just remember to inspect and improve…

  4. Excellent post, Ken.

    The precise words that you’re being held to account for I used to use on my intro slide decks when training new teams – I believe it was from a podcast in 2005:

    “Of all organizations that attempt to become a world-class software organization (by adopting agile practices like Scrum) only 1/3 will make it.”

    I’d then follow it up with these two quotes, both from other podcasts of the same time:

    “The inspect and adapt practices of Scrum is where the pain comes in, because when you start doing that you discover everything in your organization that’s not working.”

    “Agile is hard work; it’s a long process and it is extraordinarily satisfying.”

    Last one is a personal favourite.

  5. This is crazy common! I can’t believe how many people I have talked to that say they pick and choose and have their own “Scrum”. It may work for them but the should not call it Scrum since Scrum is really rigid in its agility by definition.

  7. The analogy with chess is not correct.

    Chess is a complex game, still it has defined rules and there is NO DEPENDENCY ON ENVIRONMENT. In software development, environment is VERY diverse. It means it is hard to create a defined set of rules that should be followed and lead to success.

    It is relatively easy to become 1800+ player in chess. It is relatively hard to become really good at Scrum adoption across various companies, cultures, etc. So I don’t think it is possible to have canonic Scrum process that fits all. And it is good when people try to fix that and adopt Scrum to their needs, but it do contains danger inside. The road of adoption can lead to wrong direction.

    • This is the perception that causes team that try to adopt Scrum to fail. If we complete the analogy and say that we don’t follow the rules of chess because our culture dictates that we don’t use pawns, we can create an odd dependency on environment. While this seems crazy and pointless to do in chess, it is what organizations do when they choose to not follow the rules of Scrum. Environments that prevent teams from using Scrum completely are as dysfunctional as not using pawns in chess.

    • Chess to Scrum analogy works for me.
      Just by knowing rules on how to play chess does not mean you can play the game.
      In chess there are two aspects: rules and strategy. You have to have a strategy in order to play your opponent.

      In Scrum your strategy will depend on external factors like ENVIRONMENT, problems you are trying to solve, etc.

      Does it make sense?

      by the way to be a GrandMaster you need a score of 2500+ as one of the criterias; there were <1000 GrandMasters world wide in 2006.

    • Looks like tou are going far beyond what Scrum *is* – simple 3 accountabilities, along with events and artifacts as defined in the (now 13 page) Scrum guide…. Which of these items (please quote Scrum Guide – any recent version) do you think can not be actievend in an environment???

  8. Great summary Ken on ‘Scrum fails or success’! It makes sense for me… I’m totally agree with you on “ScrumBut” which is more present than Scrum in organizations!
    Regards

  9. I agree with the middle chunk of your post, but the first part and the last bits make no sense to me when put together.

    As you say, chess as an abstract thing can’t fail. It just is. If Scrum were an abstract pursuit that one did just for the doing, then I suppose it could be in the same category. But by the end of the post, in telling people to feel safe, you acknowledge that there’s more to it than that. People come to Scrum with a purpose, and Scrum is certainly often sold for a particular purpose. In that case, Scrum can indeed succeed or fail, in which case a feeling of safety may or may not be warranted.

    Further, Scrum isn’t purely an abstract thing, like Beethoven’s 5th. Like chess, there’s an organization, and a community of practice, and many people who make their living from it. That definitely can succeed or fail.

    As far as practical things go, the only things that can’t succeed or fail are religious activities. If a particular surgery doesn’t fix your medical problem, then it has failed. If your favorite prayer or voodoo ritual doesn’t deliver results, well maybe you did it wrong, or maybe the gods just have other plans.

    As long as Scrum is being sold and bought to accomplish particular ends, I think it should be evaluated like any other practical intervention.

  10. William, I don’t think I follow your reasoning on things failing. Let me try this example:

    I purchase a hammer, saw, and a few nails and such, to build a table. I even get a book about it, and I try to follow the book. I get a crummy table.

    Which, if any, of those things I bought failed, and why?

  11. Great reality check. I use your chess analogy in every course I teach and it is absolutely right. Simple game, simple rules, requires complex thinking.

    People are always going to look for someone/something to blame rather than admit their own failings.

  12. I think the analogies of table building, chess playing and Scrum all work from my perspective. I know all the rules on playing chess. I can play a game of chess with an opponent. But, I haven’t built up the skills of playing a good, solid, challenging game of chess with an opponent. I am pretty bad at chess and lose constantly. On the other hand, given a hammer, saw and nails and such, I can build a pretty decent table because I have plenty of hands on experience and developed the skills to build decent furniture (many crummy tables in the past give way to decent tables today). With Scrum, one can know all the rules and follow them explicitly, but fail to achieve the highest value from Scrum through failing to have full stakeholder buy in, effective work estimating/planning/prioritisation, inexperience, etc.

    The finer skills associated with maximising the tasks needed to make Scrum as effective as it can be could be lacking hence failure to reach full potential.

    Maybe I didn’t take away what everyone else did, but the analogies resonated in mind.

  13. Pingback: Geir's smidige hjørne » Scrum feiler ikke!

  14. @Ron: You mean assuming none of the material items or tools failed (all of which can)?

    It depends on what the book says. If the book is “Tables for Dummies” and says “Even if you have no experience, you’ll be able to build a great table the first time!” then the book failed.

    If Scrum were never intended or advertised as something that could help anybody with anything, then sure, it couldn’t fail, because it also couldn’t succeed.

  15. Pingback: Scrum Fails? Yes it does | Jordan Bortz’s Software Architecture Blog

  16. @William Pietri

    > …then sure, [Scrum] couldn’t fail, because it also couldn’t succeed.

    That is accurate. Scrum never succeeds, just as it never fails. People succeed or fail. If I learn the Martha Graham contemporary dance technique, and don’t become a good moderen dancer, is the technique a failure?

    If I decide to learn a dance technique in order to become a plumber, then sure it “fails”, but seriously, what (or who) really failed here?

    Scrum is a framework for exploration; it is the boundaries within which creativity can occur. It will hold a mirror up to your organization, and it will quickly surface areas where improvement is required. But if practiced poorly it won’t do any of those things.

    Scrum doesn’t ask people to blindly comply to a process, rather it asks us to be honest, transparent and courageous, and step up to take responsibility for ourselves, our teams, and the organizations we work for.

    • The technique is not a failure if there are examples out there of good dancers who learned the technique. Where are the scrum success stories that have stood the test of time?

  17. @Tobias:

    The notion that Scrum is beyond success and failure troubles me for four reasons.

    First, I think it’s true only if Scrum has no purpose. The abstract game of chess may have no purpose. But it was invented for a purpose, and it is played, studied, and pursued with various purposes, and it can definitely succeed or fail. I believe the same is true for Scrum. Especially so since Scrum originates and is almost always applied in a business context, something inextricably bound with material purpose.

    Second, putting Scrum in a category of things beyond success and failure moves it to a quasi-religious activity. If Scrum can be thought of as something that can’t succeed or fail, then that should be equally true of any other software process. That makes questions of which approach one should pursue nonsensical, because they can’t be evaluated on practical grounds. I think that’s a mistake that would destroy a lot of productive dialog.

    Third, you and Ken contradict yourselves. If Scrum is beyond success and failure, then you have to stop making claims that it’s good for anything, because those are testable claims on which Scrum can indeed succeed or fail. Ken implies that adopting Scrum will help teams become excellent development organizations. You say it will hold a mirror up to organizations. If you two really believe that, then Scrum can succeed and fail. If you don’t, then you need to stop saying it can do anything for people.

    Fourth, people keep selling Scrum to people who expect it will solve problems for them. If Scrum is beyond success and failure, then people should stop selling it. Whatever you and Ken claim, a lot of money is being made by people who raise expectations of what Scrum can do. There are a lot of employees suffering right now when Scrum fails to do what it says on the label.

  18. Pingback: Oneda | Aconteceu no Twitter 60 - 03/04/11 a 09/04/11

  19. Great article, i see a lot of people saying “we’re a scrum team we have meetings one time a week” besides the PM saying: you must do this…and we need it in production in two weeks.

    I hope they can read, learn and practice on scrum techniques.

  20. Pingback: OneOfSix | Spectacularly Missing the Point about Scrum Success/Failure

  21. I think the analogies of table building, chess playing and Scrum all work from my perspective. I know all the rules on playing chess. I can play a game of chess with an opponent. But, I haven’t built up the skills of playing a good, solid, challenging game of chess with an opponent. I am pretty bad at chess and lose constantly. On the other hand, given a hammer, saw and nails and such, I can build a pretty decent table because I have plenty of hands on experience and developed the skills to build decent furniture (many crummy tables in the past give way to decent tables today). With Scrum, one can know all the rules and follow them explicitly, but fail to achieve the highest value from Scrum through failing to have full stakeholder buy in, effective work estimating/planning/prioritisation, inexperience, etc.
    +1

  22. A little late to this conversation… but wanted to weigh in on the chess metaphor.

    I think the metaphor is valuable and holds to a point. Most organizations I work with want to play by the rules of chess, they even try their best to play to by the rules of chess… but they are missing a few of the key pieces, and are playing on a board that is 6 x 6, or 12 x 9, instead of 8 x 8.

    And that may very well be the point. If you want to do Scrum, you not only have to play by the rules, but you also have to have all the right pieces, AND you have to be playing on the right board. Too many organizations adopt the rules without addressing the players or the board… and THAT is the problem.

  23. Great post, thank you very much.

    I like the metaphor with chess but I always have problems with the term: framework.

    As a PMO, I’m involved with a lot of other “frameworks” like PMBok, Prince 2, L6S, Scrum, XP. Those are all known as “frameworks” but in the real life it doesn’t.

    Why? Because they aren’t. In SW Development, people are using framework to pick up what they need: it’s a tool box.

    Is it applicable for a “methodology”? I think no, because that increase the noise (Scrumbuts) and waste.

    You had a great stuff that sounds well for me: Scrum is an empirical process. That’s more close to effectiveness: it’s a process to make the WHAT happen.

    Terms like management and process are not really welcome and we (our community) are looking to reinvent new terms for the same old stuff. We have a process.

    Like in chess or in cooking (my domain ;b)), if you got a receipt without a process you’ll reduce your chance to succeed and if you have a framework, you got nothing really precise: e.g. Mousse aux chocolat bolognese !!!

    This was the luxemburgish wote ;b))

    Thanks

  24. Pingback: Scrum Fails? (via Ken Schwaber’s Blog: Telling It Like It Is) « JOON PARK's blog

  25. Pingback: Scrum Fails? (via Ken Schwaber's Blog: Telling It Like It Is) « JOON PARK's blog

  27. Pingback: Not tried and found wanting, found difficult and therefore not tried | Process Revolution

  28. Pingback: Not tried and found wanting,. found difficult and therefore not tried | Process Revolution

  29. Pingback: Scrum funktioniert immer - Inspect & Adapt

  31. Pingback: Go Fish! Agile Antipatterns Minimalist Thought

  32. Pingback: Gary Pedretti » Scrum is chess, scaling Scrum is…

  33. Pingback: Gary Pedretti » Scrum is Chess, Part II

  34. Pingback: scrum – agile = problems « Sergei’s blog on bugs, penguins and stuff

  35. Pingback: Scrum Extensions Update – 1st Quarter 2012 | Scrum Alliance

  36. Pingback: Scrum Failure: What does it mean? - Chris Steele on Agile

  37. Pingback: Blasphemy! They Call It Scrum! » Agile Trail

  38. Pingback: [번역] 스크럼이 실패하는가? | Windroamer

  40. I got this web site from my pal who shared with me regarding this web
    page and at the moment this time I am browsing this site and reading very informative posts here.

  41. I have been guilty in the past of creating a “Scrum but”, however I have always tried to make sure that my “but” stayed within the confines of the Agile Manifesto and its accompanying principles. Specifically I have made exceptions when it was a choice of “Individuals and Interactions over process and tools”. If the modifcations are outside of the principles or violate the Manifesto in any way, then they should be avoided like the plague!

  42. Why don’t people like Ken use better analogies for Scrum. How about manufacturing a product, you know like a car? If Scrum can demonstrate itself in manufacturing like Six Sigma, developed by manufacturers and used by software development, then maybe there would less debate on merits and Scrum-buts.

    However all I see are if you follow Scrum it will work. This statement is true of any SDLC or framework. If waterfall was followed to the letter, there would not be scope creep, if all developers in waterfall were knowledgeable of the software code would be better, if the users engaged more with the designers it also be better. Everything I have read so far leads me to the conclusion, that people need to follow a process, whatever that process is. As soon as they step away from the original definition failures occur.

    As other people have stated the problem is the people, until inexperienced people listen to the experienced people things won’t change and software development will continue to have these pointless debates about which framework/methodology is best.

  43. You really need to read some of the books where the difference between simple, complicated, and complex work is discussed in detail. Manufacturing is a complicated activity, where more is known about what is going to happen than is unknown. Software development is a complex activity, where more is unknown than known. Waterfall, unfortunately, used a complicated model (aping manufacturing) to attempt to manage a complex activity. Hence, its failure.
    Read and catch up.
    Ken

  44. Pingback: 10 ações para ter sucesso na adoção do Agile

  46. I’ve been at three companies that had embraced “Scrum”, which was really “Scrum-but”. Or maybe worse “Cargo Cult Scrum” or “Fad Agile” … judge for yourself.

    Each “Scrum-but” was very different from one another, although there were some commonalities.

    The commonalities were: no Scrum Master. No Product Owner. Each developer on the Scrum team was working on different things. Rarely was a sprint ever “successful”, in the sense of the burn-down getting to 0 or anywhere near 0. Daily stand-ups were status meetings for the benefit of product management. No traction in incorporating agile engineering practices. Planning meeting involved being assigned work. Retrospective meeting rarely resulted in changes, and was more venting and howling into the void. For all that negativity, the Demo meeting was usually pretty good at least!

    Yet, despite all the Scrum-but variance from Scrum, we still got feature work done, and the product shipped.

    I’ve read Kelly Waters “How To Implement Scrum in 10 Easy Steps”. I’ve read Mike Cohn’s awesome books. I’ve read Robert Martin’s awesome books. I’ve read “Agile Software Development with Scrum”, also an awesome book (thanks Ken!). I’ve drank the agile flavor-ade from my co-worker Arlo Belshee, an agile evangelist extraordinaire.

    It seems so simple in theory, yet so elusive in practice. I don’t know if the lack/blame is in the developers, or management, or everyone, or human nature, or organizational gravity, or corporate antibodies.

    And if the above seems all sour grapes, we still got work done and shipped product.

    That being said, I’d like to have the opportunity to do “by the book” Scrum some day. I imagine that it would work really well, if it were allowed to blossom.

  47. Pingback: Top 3 Reasons Why Companies Struggle With Agile and Scrum

  48. Pingback: Scrum will change your organization! – Agile Blog

  49. Pingback: Die Scrum-Buts – Dirk Jäger

  50. Pingback: Скрам как шахматы - Блог AgiliX Consulting

  51. Pingback: Scrum失败了？-Scrum爱好者

  52. Pingback: Scrum change l’entreprise ! – Collective Genius

  53. Pingback: 8 Stances of Scrum Master - Professional Scrum Master I

  54. Pingback: [BLOG] Scrum change l'entreprise | Collective Genius

  55. So, in other words: “Scrum can never fail. Scrum can only be failed.” But what sort of excellent development organization produced written content with such low contrast that 30% of the audience will be unable to read it comfoprtably?

  57. Pingback: The 8 Stances of a Scrum Master – Acordo Coletivo: Cidadania

  58. Pingback: Scrum Fundamentals Workshop in Boise 🚀 Accentient - Agile, Scrum & DevOps Experts

Leave a comment