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:
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’: