Shuhari has for some time been associated with learning how to be Agile. Alistair Cockburn introduced its use in the context of learning software methods in general in his early book Agile Software Development.
According to Wikipedia, Shuhari roughly translates to “first learn, then detach, and finally transcend.”
- shu(守?) “protect”, “obey” — traditional wisdom — learning fundamentals, techniques, heuristics, proverbs
For example, learn and do Scrum it exactly as laid out. Learn the discipline. Gain understanding by precise application
- ha(破?) “detach”, “digress” — breaking with tradition — detachment from the illusions of self
Experimenting and Tuning. For example, Learning where particular procedures breakdown. Varying, and mixing techniques, ATTD with XP inside Scrum, Scrumban, etc.
- ri(離?) “leave”, “separate” — transcendence — there are no techniques or proverbs, all moves are natural, becoming one with spirit alone without clinging to forms; transcending the physical
In agile, full certainty on one’s craft and what is needed, acting, creating what is needed.
Shuhari is a great roadmap for learning a discipline. But someone adopting Agile today is liable to struggle with a bit. The beginner is supposed to follow the rules exactly, yet in Agile, that’s a question that surfaces almost daily: “What are the rules?”
For example, at the level of technique, the use of Features, in addition to Epics and User Stories, is gaining favor, with at least two distinctly different interpretations of what that means (subject of a future blog). Also trending is the practice of doing away with story points as well as the decomposition of tasks from stories. On a broader scale, there are new organizational models emerging (Reinventing the Organization, Laloux), DevOps, and the battleground around how to scale agile. It’s is an exciting time to be embarking on or engaged in Agile. But where does one begin? How does one “Shu”?
Part of the answer is that many people starting agile adoption, and even some who have been doing it for some time, make this underlying, but incorrect, assumption: That there is a standard way to do Agile. In particular that there’s a standard way to do Scrum, one that involves detailed instructions on user stories, tasks, and so on. But if you look in the most recent, definitive description of Scrum, The Scrum Guide, (Southerland and Schwaber, 2013), it (wisely) makes no specific reference to user stories or tasks. It does briefly describe Scrum’s theoretical pillars, and the basic roles, events and artifacts. But the entire document, including title page, table-of-contents, and historical notes and acknowledgements at the end, is only 17 pages. And of course Agile software development itself is, to this day, grounded in just the four values and twelve principles of the Agile Manifesto.
Agile is like many other discipline, then, in that it is consists of some core principles and many methods. And these latter are continuously maturing. It is perhaps different from many in that it is also supported by values and philosophy that make it naturally wary of crowning specific, detailed techniques as the way, or “best practice”, This is a natural result of the trust, empowerment, and belief in the individual’s desire and ability to create and produce when unfettered, that are inherent in Agile.
Which takes us back to the beginner trying to apply Shuhari. Where does she begin? Basically by reading, getting trained, finding a reputable coach who can provide some workable details and direction where needed, following those, and getting some experience under her belt. “Shu.” Then having a look around and working and studying some more. Trying some other approaches. “Ha.” The only real difference in Agile might be in “Ri.” The master agilest never stops learning, never stops collaborating, never stops sharing and working with others to advance the craft. But I suspect the Japanese ancients who originated the concepts would have expected no less.
Success with Agile though, even in “Shu” does require something else – a devotion to continuous improvement. That, and the other aspects of an Agile Mindset and what it means to Be Agile, are the subject of another blog.