IIan Goldstein, Certified Scrum Trainer, consultant and the author of the ‘Mike Cohn Agile Signature Series’ book, ‘Scrum Shortcuts Without Cutting Corners’, is writing a scrum myth buster series. So far he has published four parts of it. This series will cover off myths great and small including:
- Scrum is an acronym
- Sprints = speed
- Scrum is an approach only for software development
- Scrum is anti-documentation
- Scrum teams must use the User Story format
- Planning Poker, the Sprint task board and Sprint burndown are all fundamental to Scrum
- Sprint ‘Zero’ is a core part of Scrum and must be the length of a ‘typical’ Sprint
- The Sprint Review is the activity to engage with the Product Owner
- A Sprint is a failure if the team doesn’t complete everything in the Sprint Backlog
- Requirements must be completed end-to-end in the one Sprint
- All Scrum team members must be cross-functional
- ScrumBut is different to ScrumInProgress
IIan clarifies the first myth – “Scrum is an acronym” in the Scrum Myth Buster Series – part 1. He explained that scrum is not an acronym and was actually named after the game of rugby’s scrum.
In part 2, IIan explained that sprint is for distance and not for speed.
The fact of the matter is that scrum actually promotes sustainable development practices as described in the 8th principle of the Agile Manifesto.
The term Sprint should be associated with distance and focus rather than speed, drawing the comparison between the shorter sprint race and the significantly longer marathon (that seems to go on and on with no end in sight). The Sprint allows teams to regularly pause, take a breath, check the road ahead and inspect and adapt to ensure they haven’t strayed onto the wrong running track.
IIan talked about implementation of scrum outside software development in part 3.
So here’s a serious myth for you – Scrum is an approach only for software development....But here’s the thing; if you read the axiomatic Scrum Guide there is no mention of the word software or engineering anywhere to be found! Scrum has been purposely abstracted above this level so that it can be applied in a whole host of other domains and industries.
As per Agile Manifesto - "We value working software over comprehensive documentation". He emphasised the importance of the footnote in the manifesto “while there is value in the items on the right, we value the items on the left more”. Emphasizing on this, IIan explained the fourth myth about documentation in Agile in part 4.
If documentation is required then we don’t shy away from it. There is a big difference between generating documentation for memory rather than using it to create an artificial perception of upfront control. Scrum in conjunction with the User Story format is not about eliminating detail and documentation. It is about getting the right level of detail at the right time.
IIan is going to write about the rest of the myths in coming months. InfoQ interviewed IIan about the scrum myths.
InfoQ: What motivated you to write article on scrum myths and why is it important to know about these?
IIan: As a Certified Scrum Trainer, I am lucky to be exposed to a vast range of different teams and as such I've certainly witnessed both the growth of Scrum as well as the growth of its associated myths. It's at this global tipping point that we really need to ensure that collectively we are on the same page as to what is 'real Scrum' and what ‘lip-service Scrum’ is.
InfoQ: Why do you think these scrum myths persist in various organisations?
IIan: I would say generally it comes down to poor quality education...
InfoQ: You talked about scrum outside of software. Give one example where you implemented scrum outside software development.
IIan: My book, Scrum Shortcuts Without Cutting Corners was actually written and edited using Scrum!
InfoQ: Would you like to give any message to scrum practitioners?
IIan: Avoid dogmatic Scrum. Don't focus on labels. Be pragmatic and always go back to first principles and the underlying intent.
