The Silence of Scrum

"I'm sorry I wrote you such a long letter; I didn't have time to write a short one." —Blaise Pascal

I've noticed a string of complaints and criticisms of the Scrum Guide recently, essentially that it is too short and doesn't contain enough information to be useful. For "information" perhaps read "prescription". People tend to look for direction, for explanation, for a methodology, at least for some instruction. The Scrum Guide offers none of these. It is silent on development practices, indeed on most practices. It offers only a framework consisting of roles, meetings, essential artefacts, all built on a foundation of empiricism. It provides no direction at all on how people should work, offering only vague suggestions such as, "How this is done may vary widely across organizations..."

Scrum says nothing about development practices, and oddly people interpret this to mean that those implementing Scrum don't care about such things. That's a big leap. If the Scrum Guide recommended, for example, test-driven development, or a particular method of estimation, then it would be bound to these implementations even when something better comes along. Or the guide would need constant revision.

The strength of Scrum resides in its simplicity, and it's agnosticism to practice. The core of Scrum has barely changed since it was first presented at OOPSLA '95, twenty-two years ago. The Scrum Guide does get revised from time to time, which I actually think is to its detriment. Changing "commitment" to "forecast" for example could be seen as appeasement, rather than improvement. Happily the original pattern has not been lost in the many updates.

Is Scrum perfect then? Well...is the Agile Manifesto perfect? Of course not. Neither is perfect, but each in it's own way offers a firm foundation from which to invent good process, foster engaged work communities and deliver high quality, valuable product. Being imperfect does not mean that constant tweaking would make it better. They tried that with Coca Cola—it got worse. Not a single word has changed in the Agile Manifesto since it was written sixteen years ago, and yet the values and principles it offers are as sound today as they were in 2001. Of course, if one reads it literally, many imperfections can be found. But literalism isn't the point. The Agile Manifesto offers an holistic opening of our minds. Scrum offers an holistic challenge to the existing status quo. In both cases you the practitioner need to work out what to do next. And that, as I understand it, is the spirit of self-organisation.

Still, I am not critique-free when it comes to the Scrum Guide. Unlike the voices calling for more detail though, I call for less. I find the Scrum Guide to be unnecessarily long. For example, I see no value in listing out the many Scrum Master duties. Such a list is in danger of being misused: some readers will think a Scrum Master must do all of these things, others that these are the only things a Scrum Master does.

Eight years ago, in 2009, I made an attempt to describe Scrum in ~500 words. Digging that post up again today I could find only one thing wanting: there was no emphasis on the Why. I added nine more words. Other than that I'm confident the essay captures the essential Scrum framework. I'm not suggesting Simple Scrum as an alternative to the Scrum Guide. Not at all. I do suggest though that if you are a serious Scrum practitioner you attempt your own Essence-of-Scrum essay, so you truly understand (for your own work, and for the conversations you need to have) what is essential and what is not, or to use the metaphor from the picture shown above, separate the frame from the production of fruit.

In case anyone needs an explanation for the metaphor, it's this: the farmer is the product owner, the tomato plant is the team, the gardener is the Scrum Master and the frame is Scrum. Oh, and the little boy is the happy end user :)

Scrum: simple, clean, reflective, unrelenting, melodic. The silence of Scrum speaks volumes, but we do need to listen.