We discovered that the answer to those questions depends on who is asking them.
I am sure you are aware of Shuhari. It is a Japanese martial arts concept that describes different stages of learning. Shuhari roughly translates to "first learn, then detach, and finally transcend." The "shu"-state is about learning fundamentals, techniques and heuristics. Once one progresses, he/she reaches the "ha"-state, which means "detachment from the illusions of self". If one achieves mastery, he is in the "ri"-state, where "there are no techniques or proverbs, all moves are natural, becoming one with spirit alone without clinging to forms". I have previously explained this concept slightly deeper.
If we apply this concept to the Scrumguide, we quickly discover that it leads to some insights: Somebody reading the guide and being in the "Shu" state will need more guidance than somebody in the "ha" or "ri" state. So if you are just starting with Scrum, you will be very happy to find the three questions for the Daily Scrum, the distinction of Sprint Planning 1 and 2, maybe a guidance on how to do a Retrospective or even some standard items that can usually be found in a Definition of Done. Once you are in the "ha" state, you will want to get rid of the "rigid cage" that is being imposed on you by the "shu" rules. However, you will still need some unmovable boundaries to help you not to go astray (at least not too far). When you finally have reached the "ri" state, you don't need any framework at all. All you need are the values and basic principles of Scrum - everything else will come naturally to you and you will be able to taylor the framework to your needs without losing agility (which most often happens if somebody not in the "ri" state starts tayloring Scrum).
For this reasons I hereby pledge for three different versions of the Scrumguide:
- The Shu Scrumguide should be more like a compendium, including very strict orders on what to do. It should also include best practices. It is important, however, to make transparent to the reader what are best practices and what really belongs to Scrum. Whoever reads the Shu Scrumguide should be able to set up a Scrum Team right away with clear guidance on how to do it.
- The Ha Scrumguide should be quite similar to the current version. It should include a lot information on what to do, but no more details on how to do it. So this is basically a guide that includes the information about what is included and mandatory in Scrum. No best practices are shared here.
- The Ri Scrumguide will be a short one-pager and only include the fundamental principles and values.
Along with their normal content, the three guides should give some hints on how the reader can self-assess his/her knowledge level in order to decide which guide is the right one for him/her. It has to be made sure that "shu" people stay with the "shu" guide, otherwise we will face a myriad of dysfunctional Scrum-But implementations. After all, apprentices always try to circumvent their masters, because learning something new is difficult and painful. However, if you don't go through this pain, you will never become a master yourself.
What do you think about this idea? Rain comments on me!
I think teams new to Scrum (Shu) benefit from doing it "by the book" until they really understand why they are doing it and can (carefully) make some adjustments.
Shu teams could be too eager to move on to the Ha stage. To avoid that, rather than presenting the three guides side-by-side, the user could be walked through a few very quick questions before being pointed to the appropriate guide for them.
The Ri Scrumguide sounds like it would be the Agile manifesto...
It’s very interesting idea which you described. I would like to try to reconsider what you said in reverse order.
Creating the “Ri – Scrumguide” is a great idea and would help to define the fundamentals and the core of the philosophy. This would make the mastering of Scrum easier, because every member would have the same “process – goal”.
The “Ha – Scrumguide” would stay the same (more or less) and describe the necessary artifacts, rules and so on.
I have the most problems imaging the new “Shu-Scrumguide”. Currently, there are in existence a lot of books, which describe most “best practices” about implementation of Scrum Framework, providing the artifacts and following the rules. The challenge is to found the best one for the current situation. In my opinion, the ultimate best practice would be too abstract to use or too static to be acceptable in any situations. Another problem might be to try implementing a scrum in form “step-by-step” order. In my opinion the aspect of “inspection and adaptation” is very important for acceptance and understanding of the framework.
In conclusion, I would prefer to add a new chapter on the current Scrumguide to describe the “Ri-State”, instead of creating the three new ones.
Kind Regards
Max
Here in the West it was formalised in Bloom's Taxonomy, but most knowledge systems have multiple levels of knowledge and understanding for those who invest the time.
The established wisdom is that these deeper levels are there to be "discovered" rather than "documented" so that students attain and realise depth of understanding incrementally.
For this reason, guides such as you suggest have traditionally been valued and protected. Some exist only as an oral tradition, some are "concealed openly" via symbolism and tradition.
It's a little like having an "advanced" options menu. It tends to attract the attention of those who would do better with "simple options"!
Thanks for an enjoyable and thought-provoking article.