Following was inspired by the Tao Te Ching (Dao De Jing). I was preparing to teach a new Agile team and wanted a simple version of the rules of Scrum. I started with the Scrum Guide, which I distilled down into 15 basic rules and 53 sub-rules. The basic rules, in this Taoist-like format, are a kind of Ri (expert or master) version of Scrum. In this post are the first four rules, with comments.
The Underlying Tao
The Way is Transparent. The Way should be Inspected. What is Inspected should be Adapted to.
The basis of Scrum is that it is transparent: to the people who pay for development, to management, to customers and users, to the team itself. Of course, this sounds good, but in fact people often hate it. It is hard to give up old ways, to be exposed in our comfy habits. So we don’t always take full advantage of transparency. We want transparency of some things, but not others.
Next, given that we have transparency, we are now in a position to inspect what actually happened. Did our plan work out? Did the change to greater detail in our stories actually make a difference? Were we able to get QA more involved this sprint?
Finally, when we see the results clearly, it is incumbent upon us to make changes, to adapt. If QA did not get more involved this sprint as we wished, what happened? How did we fail? What can we do differently? The questioning mind is an open mind. In the beginners mind there are many options, in the expert’s there are few.
The Tao of People
The Product Owner decides the ‘what’ of the Way.
With only one person making decisions on what to work on (and why), teams are able to get very clear and move very fast. With inspection, everyone sees whether those ‘what’ decisions actually worked out. The Product Owner is likely to either love or hate this arrangement. If we know where we want to go–and are able to adapt quickly to feedback–it is wonderful to be the driver. Conversely, if our success has been due to maneuvering around accountability, this will be an unhappy path with which we will likely find fault.
The Team decides the ‘how’ and ‘how much’ of the Way.
In regards to the Product Owner’s direction, the Team decides both how to accomplish the ‘what’ and how long it will take. To do otherwise will tip the scales of power unwisely, in ways that do not reflect reality accurately. Teams feel the integrity of the process when this dictum is upheld. It conveys respect and professionalism.
The Scrum Master serves the Way, and tells others when the Way has been lost.
Ultimately, the Scrum Master must serve the Way itself. For Scrum, the Way is embodied in its rules and essence. At times, the Scrum Master may feel like a voice in the wilderness, trying to be heard above the din of deadlines and demos. But if she serves the Way truly, her voice will eventually be heard. If it is about his ego, or results, the Scrum Master will fail: himself and the Team. This is very hard for the new Scrum Master to learn. We have been trained that we must be responsible for the team’s results. Ultimately, attempting to do so will compromise our allegiance to the Way of Scrum.