When Not to Use Scrum


Don’t get me wrong, people! I am CRAZY about Scrum. Just ask my wife(she gets sick of hearing about it sometimes)! I’m probably the biggest Scrum fan on the planet!

However, I’ve encountered certain situations where it doesn’t seem like Scrum works well. They all pretty much boil down to two generic cases:

  • Applying Scrum to a problem domain it was not designed for, or
  • Applying Scrum where people or processes actively or passively work against Scrum principles.

IMO, Scrum may not be the best fit for:

  1. Companies who will actively or passively work against Scrum and its major principles.
    • This includes companies that do Faux Scrum.
    • If the Company doesn’t care what process is used at the team level, and won’t constantly act against Scrum, then Scrum is fine at the team level.
  2. Companies who are expecting a lot of benefits from Scrum but cannot commit to doing Scrum in a good faith, holistic, way.
  3. Companies that like to matrix numerous people into numerous projects.
    • Matrixing at the Product Owner or ScrumMaster level *may* be ok(but probably not optimum) if the people are experienced/highly knowledgeable in those roles.
  4. Teams who cannot commit to a week of fairly fixed scope (say, where < ~70-80% of the scope is fixed for a week).
    • Examples of teams that sometimes cannot hold to this are generally interrupt driven type organizations, like network support, production support, software operation support, etc. A Kanban type of approach can be considered with such highly variable scope, but I’m not a fan of the Kanban movement yet because it is still incubating IMO.
    • Be careful on this one.  If your team experiences high scope churn, it may just be a really bad dysfunction that needs rectifying.  Look closely before discarding Scrum here.
  5. Teams where members and/or leaders will actively or passively work against Scrum and its major principles.
    • This includes companies that do Faux Scrum.
    • Stealth approaches are fine, but if there isn’t enough consensus to work within the Scrum framework(especially from team leaders), then results will probably be mediocre.
    • I have seen some team leads(or functional managers) who embrace the principle of self organization (always to a point, especially if the team lead has more command and control responsibility from above), and I have seen team leads who just can’t let go of the authority. In cases where a team leader cannot let go of the authority, Scrum may be a disaster, especially for those advocating for it. If you’re in one of these situations and you really love Scrum, find a new team or organization to work for that truly embraces Scrum.
  6. Something other than software development.
    • It’s my personal view that true Scrum is for software development. One can adapt Scrum to other domains, but then it’s not really Scrum any more. One can certainly use “adapted pseudo Scrum” effectively, but that’s only if the person guiding the adaptations is a Scrum and/or process expert. I strongly believe that many Scrum concepts can be “lifted out” and used very successfully elsewhere — but again, that’s not really Scrum any more IMO.

Again, please don’t take this the wrong way and use these scenarios as an excuse to “give up on Scrum.” Scrum is about the “art of the possible,” and the only time it doesn’t work is when it is not ‘possible.’ I believe the situations above to be when Scrum *may* not be possible (or at least very difficult). In pretty much any other situations than the ones described above, I will defend Scrum heavily as possible and potentially highly beneficial.

Below are some examples of interesting situations where I didn’t think Scrum was the best fit.

Example #1

I had a company call me once for advice on Scrum. In short, they were doing the typical consulting firm thing where everyone works on ~3+ projects at once, which meant ~3+ different teams for each team member. I told her they either need to re-org into teams that work as teams, or forget about Scrum and find something else. I love Scrum, but matrix hell is Scrumbut City and it won’t work.

Example #2

(in this one I didn’t recommend against Scrum per se)

I interviewed to be a Scrum Coach(as a consultant) with a company. They had a couple of major Scrumbuts that they were unwilling to change, yet they expected to obtain significant productivity gains from using Scrum and wanted me to make that happen. An hour or so after the interview, I called the person who set up the interview and I told them I didn’t believe they would reap the benefits they sought because they weren’t really willing to embrace Scrum. As such, since I didn’t think it would be a successful engagement, I politely declined.

7 Responses

  1. I feel that if people don’t want to improve the way they work or themselves, scrum is definitely not an option. Very few (IMO) don’t really know how hard scrum really is and give up before they start to realize the benefits it can present.

    • I can’t disagree with you too much gstober. Ken and others have said “Scrum is simple”, and I just don’t agree with it. I don’t think it’s “complex” either, but I don’t think it is simple. Putting on your shoes in the morning is simple. Scrum is more involved than that.

  2. Michael Sahota has written a great series of blog posts on how different organization cultures fit – and don’t fit – with agile philosophy: http://agilitrix.com/2011/04/agile-culture-series-reading-guide/

  3. Hey Charles, looks like the links in the article for Faux Scrum are broken.

  4. Hi Charles,

    This is an excellent post on Scrum, and it will be enlightning to many project managers who are confused on when to use and when not to use Scrum. That’s why I would like to republish this post under the Scrum category on PM Hut. Please either email me or contact me through the “Contact Us” form on the PM Hut website in case you’re OK with this.

    PS: You might be interested in this post I have published a month ago on PM Hut: The Lifecycle of User Stories.

Leave a comment