“Scrum by the book”
I often come across teams that are ‘doing Scrum’, but fail to realize the core principles that form the foundation of it: transparency, inspect & adapt. A lot of teams I’ve met, are starting out by doing Scrum ‘by the book’. They are doing the standard events as talked about in the Scrum Guide in the obvious way. Doing 1 daily standup answering three questions, 1 sprint retrospective, 1 demo and 1 sprint planning. The obvious artifacts like a burn-down and standard sprint backlog are used.
Now to me there is nothing wrong with this approach. You have to start somewhere and if you have no previous experience to rely on, by all means, do Scrum as it comes ‘out of the box’. If you come from a waterfall background or other heavy project management approaches that try to do pre-deterministic risk control, you’ll probably find your productivity going up.
“If after a year of Scrum, you are still doing ‘Scrum’, you don’t do Scrum’
However, if you keep sticking to your standard routine and blindly apply your learned techniques in new projects, you’ll sooner or later find out that the magic wears off. If you are in this situation, it’s time to Scrum your Scrum!
When I heard my first presentation on Scrum back in 2007, the guy who presented said “If after a year of Scrum, you are still doing ‘Scrum’, you don’t do Scrum”.
I always found this expression a bit awkward, but what he probably meant was that if you keep on doing Scrum in the same manner after a substantial period of time, you are missing the core values of Scrum. You should adapt your way of working to your specific environment and circumstances.
In Aikodo there is a learning technique called “Shu-ha-ri”. This literally means “embrace”, “diverge” and “discard” and it says something like first learning from a master and copying his exact techniques and forms. After that the student learns the underlying principles and starts learning from other masters and applies that into his own practice. Finally the student learns from his own practice, he creates his own way of thinking and adapts his techniques to his own specific circumstances.
Alistair Cockburn came up with the idea to apply this way of learning to software development techniques and methodologies.
Taking it home
So applying this way of growing to your Scrum adoption, here are some tips:
- Don’t be dogmatic about your burn-down: it’s about the transparency of seeing progress.
- Don’t be dogmatic about your daily standup: if you are working with 2 or 3 people and you really are communicating well, you might want to skip it sometimes
- Don’t be dogmatic about your ‘daily’ standup: if there is a lot of pressure and a tight deadline, you might want to do a standup every two hours.
- Don’t be dogmatic about your three standard questions to answer during the standup. If there are other questions relevant for your situations progress- and impediments tracking, ask them (but remember to keep the short timebox!).
- Don’t be dogmatic about having your user-stories in a specific ‘as a.. I want.. so that’ format. It’s about getting clear communication and the team knowing enough to build the software.
- Don’t be dogmatic about having your user-stories to have an all inclusive list of acceptance criteria, remember it’s not a contract. Prefer face to face communication, together with the whole team. The user stories should be a record of that communication.
- Don’t be dogmatic about having your Scrum Master fixing all impediments. It’s about team effort. If your Scrum Master is sick or so busy fixing some impediments and you can do something about it yourself, do it yourself. The Scrum Master’s role is to make the team run smooth and if you can help him/her it’s better than waiting passively.
How are you doing Scrum in your team? If you are stuck on improving your way of working, remember Shu-Ha-Ri.