Scrumcrazy_header5.jpg
scrumcrazybtn.jpg

For Training, Coaching, and Consulting engagements, please contact me for details on how I can help your organization.


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 a 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.

coaching(4).jpgForScrumMasters.jpgForProductOwners.jpgForScrumDevelopers.jpgPresentations.jpg