If you’re attempting to implement an Agile/Scrum development process where none has existed before, you will surely an encounter a moment of frustration on the part of your developers. “Why do we have to do these standups?” “I don’t understand why we need to assign story points, can’t we just get to the projects?” “Where is my technical specification?” Like Ralph Macchio in The Karate Kid, your developers may wonder why you have them doing the engineering equivalent of “wax on, wax off,” when what they really want to do is get into the fight. What Ralph Macchio eventually understands is that the performance of rote, rigid external exercises is a first step on the road to internal mastery, a process well known in the world of martial arts as Shu Ha Ri.
In its broader definitions, Shu Ha Ri describes a process of learning: in the Shu stage, the learner follows directions literally and adheres rigidly to whatever rules the teacher has set. In the Ha stage, the learner begins to see how the rules and directions can be adapted for specific situations, and exercises some judgement in how they should be applied. In the Ri stage, the learner has developed her own techniques, and now innovates freely as the situation demands.
Martin Fowler and Alastair Cockburn have written about the role of Shu Ha Ri as it applies to Agile development, but we could characterize the three stages as rigid adherence to the principles and ceremonies of Scrum, followed by what I like to call “pragmatic Scrum” that adapts to the styles and situations of individual teams, which then culminates in true Agility in approaching projects, challenges, and the process itself. The most important thing to take away from the application of Shu Ha Ri to software development, however, is that it is about the internalization of principles, followed by an understanding of their application, which leads finally to innovation in how problems and projects are approached. This is in sharp contrast to other methodologies, like traditional waterfall, that are simply about the imposition of schedules and rules that leave teams stuck in an eternal Shi limbo. It’s difficult to imagine that these teams would experience much satisfaction with their position, much less be capable of innovation.
It’s now been six months since we adopted Scrum at Sauce Labs. We’ve had our Shu period, and, as expected, it was a difficult time. As we implemented Scrum, there were many moments of frustration, questions about why, and some resistance to what were perceived as pointless rituals. It didn’t take long, though, before we had moved into pragmatic Scrum. The teams began to better understand their own abilities, and how to incorporate and adapt Scrum practices to the way they work together. And now, I’m guardedly optimistic that we are entering into Ri, as evidenced by the project to open our data center in Las Vegas. This was a true DevOps project, in that there was no easy separation between development requirements and operational requirements, and it required the cooperative efforts of many teams to accomplish. It also required that teams who had adopted and adapted Scrum learn how to make their particular version fit in with that of their colleagues – they had to take what they had learned, in other words, and improvise upon it. Had they not been able to do this, I have no doubt that we would never have been able to accomplish this monumental task, that had so many dependencies and inter-dependencies. In any traditional project management approach, we would no doubt still be writing the specifications, rather than delivering significantly improved performance to our customers. To paraphrase Mr. Miyagi, first we had to learn how to “stand up,” then we learned how to fly.
Joe Alfaro is VP of Engineering at Sauce Labs. This is the sixth post in a series dedicated to chronicling our journey to transform Sauce Labs from Engineering to DevOps. Read the first post here.