The Scrum Litmus Test

In reading the Scrum Guide the other day, I came across this little line in the “Definition of Scrum” section:

Scrum makes clear the relative efficacy of your product management and development practices so that you can improve. 

Put another way and taking the liberty of including the greater context of the whole Scrum Guide:

Scrum doesn’t solve problems; it exposes them.

This is not a new thought; the first Scrum Master I ever met and worked with told me this very thing…and it stuck. Scrum is less method and more test; it is not a best practice, but it is a good one.

Think of Scrum like a piece of litmus paper. Apparently, Litmus is a die made from species of lichen (fungi) and Litmus paper is just a strip of paper colored with Litmus die. The blue and red dies are precisely formulated to turn either red or blue in the presence of an acid or a base. In the same way, Scrum is intentionally constructed and the Scrum Guide precisely composed to expose a multitude of dysfunction. Dysfunctions like (and definitely NOT limited to):

  • Hours long Daily Scrums that include people not building the product
  • Product Owners in name only, or no product owners
  • Development teams that must rely on personnel outside the team to finish their work
  • Sprint Reviews that are just dressed up demos
  • Planning and estimating bullied by the HIPPO (HIghest Paid Person’s Opinion)
  • Features produced that aren’t used by real people or for real problems

Once exposed by the light of Transparency, Inspection and Adaptation, these dysfunctions can finally be revealed, identified and removed.

Apart from exposing dysfunction, you may also come to learn that your project is simply not suited for Scrum. This article from Scrum Crazy has some good discussion on when not to use Scrum, and I would add the following to what it is saying:

Scrum is not suitable when:

  • People or processes actively or passively work against Scrum principles #ScrumCrazy
  • Your problem domain is not software development #ScrumCrazy
  • Your Development tea is fewer than 3 people
  • Your Development team cannot communicate face to face on a daily basis

On several occasions, I have listened to people and bloggers claim that their project is not suited for Scrum when it seems much more likely that Scrum is simply exposing huge problems with their people, processes and tools. Their position is to cop out and blame the diagnostic tool and ignore the questions being begged:

  • Why can’t we conduct our Daily Scrum with only the Development Team and keep it to 15 minutes or fewer?
  • Why can’t we find someone to curate our software project who will take a leadership role and whose decisions will be respected by the organization?
  • Why can’t our team finish our work without calling in outside experts, db admins, QA personnel, etc.?
  • Why are our sprint reviews lackluster and feel more like a performance than a working session?
  • Why do junior developers clam up during estimation and senior devs end discussion with, “Listen, I’ve been here 15+ years…”

Remember the words of Polonius to Laertes in Shakespeare’s ‘Hamlet’:

This above all: to thine own self be true.
Scrum will not solve your problems for you and blaming it for your professional failures and the failures of your organization only propagates a most dangerous self-delusion.


Jason is a developer, Scrum Master, writer, teacher, coach, husband, father, and community leader out of Tulsa Oklahoma. He's been delivering software since 2007 and absolutely loves the values and principles of agility especially as given form by the Scrum framework.