Information Technology Dark Side

Struggles of a Self-Taught Coder

Information Technology Dark Side header image 2

Six things I dislike about Scrum

January 26th, 2012 · 21 Comments

Scrum is a poor man’s agile
I won’t lie. I’m in a fairly contrarian mood today, and that is likely to influence this post to be harsher than it would be if I’d written it on a day when all was well. But, nonetheless, even on a good day I think I would agree with the gist of what you’re about to read.

Scrum is, in my opinion, the least “Agile” of all the agile methodologies. It is also the easiest to learn, the easiest to try, the easiest to add to your bull-crap resume, and the easiest to completely fail at. More on that later.

I don’t like the branding association it has with agile
Scrum is the de-facto brand of the Agile Alliance. I don’t really have anything against AA, but it bothers me that the only agile training they offer is related to scrum. It feels to me like AA positions “Scrum” as “Agile”, when in fact it is really only one of many methodologies that was inspired by the Agile Manifesto. The net effect is that when scrum projects fail, it’s not just scrum that gets a black eye, but also agile. And I don’t like that, because scrum projects fail a lot.

I don’t like the training
I’ve never taken a scrum class, so you may conclude that I don’t have any business trashing it. You might be right.

That said, I know a lot of ‘scrummasters’, and I’ve debriefed a number of people after they’ve taken a certified scrum master course, and as a general rule the training they received has failed to

  1. Give them an adequate appreciation for the values and principles that make Agile agile
  2. Convince them of the importance of absolutely critical development practices such as test driven development
  3. Prepare them for the intense resistance they will face attempting to introduce agile in an environment where it is new

I don’t like the certification
I’ve written training curricula before, both for professionals and for college students. I’ve never offered to “certify” anyone. I don’t really place much value in certification as a hiring tool or as a job-seeking tool except in certain very special areas where I know the certification is a bonafide test of competence at some level (assuming the possessor did not cheat or somehow fake the certification). Some examples of such certifications:

  • Diplomas from real colleges & universities (schools that don’t fail anyone are not “real”)
  • A license to practice law
  • A license to practice medicine
  • Certification as a professional engineer

These certifications are difficult and expensive to obtain and therefore demonstrate a fairly significant level of dedication on the part of the obtainer. They are also very rigorous and they police their members – if you screw up in a big way they will kick you out.

CSM is about as far from this certification as you could possibly get. Anyone with $500 and two days to kill can become a certified scrum master. That’s not impressive – being the proud possessor of a scrummaster certification is only a differentiator in the stupidest of organizations. In fact, if I am interviewing you for a position and you have a CSM my skepticism toward you just went up.

The true value of scrummaster certification is to the companies that sell it. They benefit immensely from it. So far as I can tell, they are the only ones.

I don’t like the club
Because CSM is easy to get and because Scrum pays short shrift to the values and principles from which Agile was born, there is a community of scrummasters who evangelize the Scrum process without grasping why Agile works. Take this genius for example:

Every CSM class I teach, I emphasize the complete nature of Scrum as a single tool, not a collection of tools. Learning Scrum is about learning the tool, not learning how to pick and choose pieces of a tool. Let’s explore this metaphor of Scrum as a tool.

Consider a hammer. A hammer is ideally suited for pounding nails into wood. It has two parts: a head and a handle. If you take the parts and use them separately, they can still be used for pounding nails into wood… but they are very ineffective compared to the hammer (although better than using your bare fist). It is non-sensical to decompose the hammer and try to use the pieces separately. However, a hammer is not suited to other purposes such as driving screws or cutting wood. It’s perfection is not just in its form, but also in its proper application. A hammer works through a balanced combination of leverage and momentum.

Scrum is like a hammer. It has parts (daily Scrum, Sprints, ScrumMaster, etc.), but taking the parts and trying to use them separately is… you guessed it… non-sensical. The parts of Scrum combine to be an extremely effective tool for new product development. Just like a hammer, there are things you wouldn’t want to do with Scrum such as manufacturing or painting a wall. (We might not all agree on the limits of the use of Scrum… that’s something for another article.) Scrum works through a combination of pressure on the organization and “inspect and adapt” (continuous improvement).

Please. Don’t modify Scrum. If you must change things about Scrum, please stop calling it Scrum.


This is in direct opposition to a number of agile values and principles, most notably that individuals and interactions are more important than processes and tools. It is also ludicrous to say you use “inspect and adapt” to obtain continuous improvement, but only so long as you don’t inspect and adapt scrum.

That’s just plain stupid.

Scrum is full of people who think like this, and it makes me sad. There is little point to scrum if you do not understand and embrace the values and principles from which it sprang. It’s just another flowchart.

I don’t like the methodology
Scrum is too rigid. It imposes a structure and process on an agile team that doesn’t always fit, and it puts pressure on teams to use that structure or else. It’s not true to the fundamentally critical cycle of experimentation and evaluation that is at the heart of agile.

I also think it puts too much emphasis on the scrummaster, and not enough emphasis on emergent planning, good design, and disciplined software development.

I don’t like the results
Bright-eyed and bushy-tailed brand new certified scrummasters are failing to deliver working software all over the place, mostly because of the three things their training failed to give them. As a result, lots of organizations are back-pedaling from their scrum implementations, mistakenly blaming agile for the failure.

Well guess what? It’s not agile’s fault. If you just “do” scrum without understanding or appreciating the values behind it, you didn’t “do” agile. You just did a totally empty version of scrum.

Is there anything left?
Nope. I think that’s pretty much it. Scrum is the new waterfail.

If you enjoyed this post, make sure you subscribe to my RSS feed!
Stumble it!

Tags: Uncategorized

21 responses so far ↓

  • 1 Dave Woodward // Jan 26, 2012 at 10:41 pm

    I completely agree. I’m on a team right now that is basically rebooting after a “failed” attempt at Scrum.

    The entire time, the team – you know the guys who according to Scrum rules are supposed to be “self organizing” and have the freedom to focus on the “how” – kept questioning how to fit certain needs into Scrum. Like refactoring.

    The answer kept coming back as basically, ‘Don’t know, there isn’t a rule and/or process for that. Shut up and do your Scrum’.

    Scrum isn’t agile. I’ve been on teams before who used a looser practice of it, but in my limited contact with Scrum it has been used by micro-managers and decidedly un-agile people to foist their old practices on developers.

    So I agree, Scrum isn’t agile and it is the new waterfall!

  • 2 David Christiansen // Jan 26, 2012 at 10:53 pm

    Ahem. I think you mean waterFAIL! :)

  • 3 Stu // Jan 27, 2012 at 9:04 am

    A well reasoned article, until the last comment, when all your predjudices come out – “my way is best, everything else, ever, is wrong” – is what so many Agile Evangelists preach, and quite frankly, it’s becoming tedious.

  • 4 David Christiansen // Jan 27, 2012 at 9:26 am

    Um what? When did I ever say that? Please elaborate.

  • 5 Stu // Jan 27, 2012 at 9:59 am

    Ok, maybe I too get a bit contrary, but the ‘waterfail’ type remark always niggles me. By using this sort of comment, to me it infers that, to you and therefore to all readers of your blog (the ‘preaching’ bit), anything else is not worth considering, as it will ‘fail’.

    Waterfall worked for many years in many cases, yes some projects didn’t meet their expectations, but the process was not the disaster it is made out to be.
    In the days of writing code on coding sheets, desk-checking those, then submitting them for input, it made sense to plan and prepare the whole project before any development took place.
    In the current development environment, where code can be changed quickly, then, yes, the design methodology needs to be more flexible.
    But don’t diss the old stuff, especially if you’ve never done it as it was in the early 80’s.

  • 6 David Christiansen // Jan 27, 2012 at 10:08 am

    Maybe waterfall worked in the 80’s, I don’t really know. But I call it waterFAIL because it is a high-risk approach to software development. Even PMI admits this – when I earned my PMP certification one of the things prep class spent a lot of time on was the high risk of waterfall projects. PMI estimates that 70% of waterfall projects fail (or at least that’s what they estimated back then) and suggested that it was even worse for waterfall software projects.

    I’m not dissing stuff I don’t understand or never tried. I spent over a decade in waterfall environments and, as I mentioned above, was once PMP certified. I let my certification lapse intentionally, in spite of the fact that it’s considerably harder to get than CSM, because I don’t believe. But trust me, I tried. I just got sick of failing.

    But this blog post isn’t about waterfall. It’s about scrum.

  • 7 Andrew L. Robinson III // Jan 27, 2012 at 12:49 pm

    I Love This!

    In one of my recent jobs, I preached going to a more agile process for Years…I had the Agile Manifesto printed out big, and pinned on my cube, and evangelized it at every turn. Using real word samples of how we weren’t being agile, using validated learning and comparisons to the agile methodology I wanted to implement and the waterfall methods they had been using for years.

    Finally, after $()@*$ 4 years of hearing the same thing from me, they decided to switch to a more agile methodology, but they went to the books. Then brought in a $300/ hour consultant that preached the ohh so powerful and all encompassing Scrum.

    At first, I was excited, and then he began to talk. Every other sentence made my blood boil even more. He was doing a good job at selling his services, but almost nothing he said I felt subscribed to the tenants of the Agile Manifesto, and I didn’t see how it would help us get to working software any faster or better than what we were doing, because it was essentially waterfall with more meetings.

    So, I tried to point this out to the powers that be, and it seems to me that those who don’t know shit about building software are scared of anything that isn’t completely written out for them, in a step by step fashion. If they actually have to have discernment, experience and insight, they completely cave. So, they now have thousands of “scrubbed” stories with Use Cases and documentation against each. How in the #$()$)($ is that not Waterfall!

    Now, I know that they are doing even Scrum wrong, but my point is that using any of these cookie cutter frameworks to build an agile environment are missing the point. The point is simply that agile is that trying to implement an agile process, but the defining the best way to do agile for your situation is out of the question is a huge hypocritical irony that is both frustrating and funny at the same time.

    Very refreshing article!

  • 8 PM Hut // Jan 30, 2012 at 9:30 am

    Scrum certifications are just an excuse so that IT departments can spend their budget by paying companies that really offer nothing.

  • 9 Gebhard Greiter // Jan 31, 2012 at 7:19 am

    I fully agree to what PM Hut is saying.

  • 10 Ron Higdon // Feb 6, 2012 at 9:43 am

    Most of post is focused on people who are trying to make money on Scrum and Agile and you seem to use those negative to discount the actual Scrum methodology. Only one of the six reasons you hate scrum is directly addressed at the methodology. As someone who have been using Scrum and XP successfully for over 4 years across 6 development teams I disagree with your conclusion. I don’t like all of the negative things you mention as well, but don’t discount the many successes that folks are having with Scrum who spend the time to understand and appreciate the principles first before applying the practices.

  • 11 David Christiansen // Feb 6, 2012 at 10:56 am

    Hi Ron – good to hear from you. You’re good at scrum because your approach to software development is firmly rooted in the values and principles of agile software development. Other people look at successful projects like those you have run and want the same success but don’t want to pay the price of really coming to grips with the values and principles needed to make that happen. I will state this unapologetically – “agilists” who evangelize the methodology without helping people through the required paradigm shift are doing more harm than good, and CSM training is the biggest offender.

    That said, I’m not discounting anyone’s success. I’m not even saying that scrum will cause you to fail. I’m simply saying that the Scrum establishment has screwed up, and it hurts all of us.

  • 12 Ron Higdon // Feb 6, 2012 at 4:10 pm

    So it appears that you don’t hate scrum as much as you hate the ‘Scrum Establishment’. I agree that scrum has developed a poor reputation, primarily because too many people tried to monetize agile and they picked Scrum as the vehicle. I had an interesting conversation with Jim Benson who wrote Personal Kanban. He said the folks at PMI contacted him about putting together a certification for Kanban. Jim politely refused. I said, “but think of the revenue opportunities’. Jim laughed and said, ‘exactly’. So watch out for the Certified Kanban Ninja training coming to a conference near you!

  • 13 David Christiansen // Feb 6, 2012 at 4:20 pm

    Hahaha. Certification crazies are the worst.

  • 14 Ryan Cromwell // Feb 6, 2012 at 9:07 pm

    CSM and tech/agile certifications are BS… that’s why so many leaders and trainers from Scrum Alliance have left and continually bash it. The founder even left because it became a paper mill (

    Discloser: I provide the PSD and PSF courses that organizes. We do not certify. We provide assessments that gauge knowledge of the courses, but are quite clear that practice and experience are needed. Scrum and Agile are crazy easy to learn, but crazy hard to master.

    Scrum has earned the reputation that Scrum Alliance created. A LOT of us know this and want to fix it. Scrum isn’t the problem and Scrum isn’t the solution.

    “It’s not true to the fundamentally critical cycle of experimentation and evaluation that is at the heart of agile.”
    This is the heart and soul of Scrum. Beyond that, there are people who create the product (dev team) and a person they can go to for fast, authoritative decisions (PO). Scrum even says the team can fire their Scrum Master. This is, because the role serves the team and PO. Doesn’t get much more simple than that. Daily Scrum = Make a plan for the day. The 3 questions??? See my tweet!/cromwellryan/status/165109125481639936

    The abused description of Scrum Master you describe doesn’t come from Scrum itself. We like to say that a Scrum Master is always trying to put themselves out of business by helping the team learn to solve problems. It’s hard to see the many people problems when you’re on the team. SM is meant to be an outside, objective observer who provides space and opportunity for growth. See Coaching Agile Teams… amazing book.

    “Well guess what? It’s not agile’s fault. If you just “do” scrum without understanding or appreciating the values behind it, you didn’t “do” agile. You just did a totally empty version of scrum.”
    — Bingo. People are always the key. No matter what, the same outcome will surface with the use of any framework while ignoring the foundational elements.

    In the end, I really would encourage you to bring your thoughts and ideas to the Scrum community. Suggest a change ( or extend Scrum ( I think you’ll enjoy seeing what comes out of those extensions that are already being proposed. Especially Scrum Basic.

  • 15 Pedro Gustavo Torres // Oct 8, 2012 at 7:26 pm

    well well well… so… you saw bad scrum master and so scrum sucks?
    if you see a bad football player then football sucks?
    don’t blame the game… blame the player.
    scrum is a great way to start… but doing scrum isn’t the goal… delivering great software is!
    scrum is a nice point to start with and you should then inspect and adapt and then use your fork of the framework.

    plain simple.

  • 16 Joshua Partogi // Oct 9, 2012 at 5:59 am

    Well said Ryan Cromwell.

  • 17 David Christiansen // Oct 9, 2012 at 6:56 am

    Pedro, sorry but you’re analogies are silly to me. The reasons I don’t like scrum are much more complex than that and are based on much more than casual observation of a few isolated teams. They are based on almost ten years of experience in this industry both doing and teaching in a wide variety of circumstances.

    Here’s the analogy I prefer, which isn’t an analogy at all. Imagine you have a training program that churns out thousands and thousands of “certified” workers every day. Further imagine that said ‘certified’ trainees emerge from this program pathetically unprepared to use the practices they have been trained on and without any grasp of the notions or values behind those practices. You can argue that we shouldn’t blame the training program, but I don’t buy it.

    Scrum is more of a training industry than it is a project management practice at this point, and yeah, I don’t like that.

  • 18 Pedro Gustavo Torres // Oct 9, 2012 at 11:19 am

    I guess you are talking calling the Scrum Alliance “Scrum”.

    Scrum is a framework… and a great one by the way!

    The certification system of Scrum Alliance… that I can agree with you that it is BS. No one can be “certified” in two days… in this one I’m with you :)

  • 19 Neil Killick // Oct 11, 2012 at 5:41 am

    Rather than the hammer analogy I think a more apt comparison is with the statement “guns don’t kill, people do”.

    I love Scrum, as Scrum is supposed to be, but its use in analytic organisations in an attempt to deliver the same crappy software more cheaply is the reason it receives so much criticism from the Agile community, in my opinion.

    At the end of the day, whatever process – or method or methodology or whatever you want to call it – you use to develop software, the person or people behind the choice of this process will have a particular mindset (or collective mindset). IMO you either have an Agile/synergistic mindset or you don’t. If you don’t, your attempts at Agile in any form, including Scrum, Kanban, XP, anything, will fail.

    The least important things about Agile and Scrum are the actual processes. Good processes emerge from truly self-organised, self-managing, smart people with an Agile mindset. If you start with the processes and ignore the implications of mindset (and its big brother, culture) you will fail.

    “Scrum doesn’t kill Agile, people do”.

  • 20 Petri Heiramo // Oct 12, 2012 at 5:11 am

    “If you just “do” scrum without understanding or appreciating the values behind it, you didn’t “do” agile. You just did a totally empty version of scrum.”

    I think you said it yourself, a “Scrum” implementation which isn’t rooted in Agile values and principles, is not Scrum. Blaming Scrum for those “not Scrum” projects is a not fair blame. Calling something “XP” and not rooting that in Agile values and principles, and then failing miserably, doesn’t mean that XP sucks. Thus, unfortunately, much of your text misses the mark.

    If a Scrum trainer came to you and taught you something that is not founded in the Manifesto, I’m really really sorry to hear that. I’d have hard time believing it’s any of the trainers I _know_, but I certainly don’t know all trainers, so I don’t presume that a CST couldn’t talk crap. In my course, I talk very much about the value foundation, and much less about standard book practices. I trust, like you, that once the value foundation is correct, people can use Agile correctly. And they are in much better position to use Scrum, XP, Kanban, Crystal Clear, or whatever their preferred flavour is (considering their circumstances), and to continually inspect and adapt its use.

    Yes, I’m a trainer and “sell certifications”. But from a personal point of view, I don’t train for that certificate or the test, I train people to succeed with Scrum. I don’t presume that these people will be able to do Scrum effectively starting the next day. I don’t pretend to them it’s easy to do Scrum properly. I do talk about how critical it is to use XP or similar practices to actually do Scrum as it’s intended. I talk about the cultural and organisational changes needed. Etc. If the certificate attracts people to the courses, it’s giving me an opportunity to help those people to understand what Scrum _really_ is (as opposed to the hollow version you also seem to know), and I intend to use that opportunity. I wish I could invite you to my course to see what I do, and then give me your honest opinion (regardless whether or not you like it), but it seems you’re based in US and I’m moving back to Finland. :/

    I wish you luck, and keep changing the world (or least the SW dev part of it) for better :).

  • 21 Yuval Yeret // Oct 13, 2012 at 1:11 am

    Good thoughtful article. I tend to agree there’s some awful scrum out there, not necessarily because of Scrum itself more because of the ecosystem.
    I also like Neil’s comment about the need to shift mindset/culture to really make a difference.

    These days im trying to see the agile frameworks such as scrum and kanban as culture/mindset hacks – ways to shift the culture and structure of the organization.
    I think this should be a key aspect of what makes a good agile framework. How easy is it to apply it in a way that actually makes a difference to mindset/culture, versus what are the risks of abuse to entrench the status quo ( typically analytical mindset in the Marshall model as Neil suggests)

    I will probably elaborate my thoughts on this in my blog at some point

Leave a Comment