Many people associate Scrum with a complete methodology. However, Scrum is only a framework and as such does not provide the details found in other methodologies. It provides a basic definition of the roles, major activities, and basic artifacts around the ultimate goal of producing a “potentially shippable product increment” within a fixed time box called a Sprint. For example, Scrum does not tell you how to best develop a product backlog, it just tells you that you need a prioritized list of backlog items to determine what should go into each of the sprints.
This can cause some frustration for some that want a methodology. They want a script that tells the team what they need to do and when they need to do it. The thought being that the team will be more productive if they don’t have to figure out the process as they go along. Sounds like a valid point, right? However, Scrum is based not on a predictable model (which is what is being asked for by those that want a methodology) but based on an empirical model. The thought is that teams will figure out the best way to get things done by trying things out, inspecting what the results are, and adapting their work to get better results in the future. With this approach, the teams will figure out the best way to work from the context of what works best for their team and the particular needs of the product they are developing.
This is why I tell people, “Scrum is easy to learn, but difficult to master.” You can teach team members how Scrum works in just a matter of hours, but it takes much more time and discipline to get really good at delivering product increments using the Scrum framework. So, what’s involved in achieving mastery?
Shu-ha-ri is a Japanese martial art concept, and describes the stages of learning to mastery. The word shuhari roughly translates to "first learn, then detach, and finally transcend."
- shu: "protect", "obey" — traditional wisdom — learning fundamentals, techniques, heuristics, proverbs
- ha: "detach", "digress" — breaking with tradition — detachment from the illusions of self
- 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
As a Certified Scrum Coach, I believe it is my responsibility to provide guidance to the teams to go through these stages of mastery. The first step with any team is to provide initial training to gain knowledge of specific techniques that are needed to apply Scrum within your team. Techniques such as developing User Stories, Story Point Estimation, and team’s “Definition of Done” to name a few. You will find this kind of training in Scrum certification classes like Certified ScrumMaster and Certified Scrum Product Owner. This achieves the “shu” stage, to have a foundational knowledge of the language, culture and practices that are essential to success with Scrum.
In a coaching role, I then try to provide teams with the reasons why these techniques have been put into place as well as a complete understanding of the agile principles that are behind the Scrum framework. If teams understand why these practices are put into place and the goals that the practices are trying to achieve, then they also can find ways to adapt these techniques to achieve success within their particular team or project. This moves into the “ha” stage, to challenge the status quo and do something different as part of every Sprint Review.
Finally, as teams begin to inspect and adapt their process, I move then into a mentoring role. I spend time not helping the teams understand or adapt the processes, but encouraging them to come up with new ways of accomplishing their work that isn’t borrowed as a “best practice”. After all, many of those practices came from teams experimenting with new ways to accomplish our goals that the community embraced as a best practice. While the team started with adoption of these practices, they should figure out how best to achieve better results. This brings the team into the true transcendence to where it’s not about adopting specific practices but just becomes just a way to do work that becomes second nature.
Skip has over 20 years of experience in IT/software development in a variety of roles such as Developer, Project Manager, Consultant and Chief Technology Officer (CTO). He provides thought leadership, coaching and training to new and experienced teams interested in agile practices. His unique focus is helping companies achieve organizational agility beyond development teams.