"Scrum Exists only in its entirety and functions well as a container for other techniques, methodologies and practices." "…although only implementing parts of Scrum is possible, the result is not Scrum"
This is one of my favourite parts of The Scrum Guide, authored by Ken Schwaber and Jeff Sutherland. I feel that it is a key part of Scrum that is so often over-looked and forgotten by teams who are finding that they aren’t experiencing the results that they would otherwise expect.
The Scrum Guide also states that while Scrum is simple to understand it is also difficult to master, and I think that this is what leads a lot of teams to cutting corners and/or missing the point of some of the finer but significant details.
The Scrum Guide is a very short and concise document – cover to cover it’s only sixteen pages – and I’d encourage everybody who has interest in Scrum to take twenty minutes to read it, and then spend a little bit of time digesting it and trying to figure out what it actually means.
I’ve previously blogged about Five signs that you aren't actually practicing Scrum, but I’d like to add another one to that – that you haven’t read The Scrum Guide.
Like a GCSE Maths course; the content is not negotiable. You can change it to make it easier, harder, more of a logical flow, etc. but the bottom line is that if you aren’t following the syllabus then no matter how good or bad the course is, it isn’t a GCSE Maths course!
You can almost certainly make Scrum better – despite how much I respect Ken & Jeff’s work I find it hard to believe that there isn’t at least one way that Scrum can be improved. The bottom line, however, is that Scrum is a defined framework and if you aren’t doing what you should be, even though you might have the best Framework, Model or System in the world, it isn’t Scrum.
When you don’t understand the path you’re following, you are destined for failure almost no matter how good what you’re doing actually is.
If you’re hiking through the hills and you think that you’re following a well-established and well used path, you’re less likely to take some of the precautions that you might if you were off-piste. This analogy reflects my greatest concern with teams who aren’t following the framework that they think that they are; when you believe that you are following a well-trodden path you probably don’t act with the scepticism or the suspicion that you otherwise might. It’s easy to feel secure and safe when you’re part of the crowd, and I believe that to be true of teams who think that they are following Scrum but aren’t.
If a development team isn’t self-organising, isn’t estimating stories, isn’t transparent or doesn’t have a definition of done understood by everyone and considered as part of estimating and Sprint Planning (to list but a few things), then it is Scrum only by name.
By all means keep doing what you’re doing if it works for you, but don’t pretend it’s Scrum. Call it something whacky like Beetroot and you never know, with the right marketing it might just make you a millionaire.