At the end of each Certified ScrumMaster class that I teach, I invite attendees to fill out an evaluation form. One of the questions on the form asks for feedback on improving the course. A consistent response from 10 to 20 percent of the attendees is a wish that I would more directly answer their questions. They note that I often answer their questions with stories, anecdotes, and sometimes with questions of my own. Why, oh why, won’t I just give them a straight answer?
Scrum is really hard. It is especially hard for people in our profession: people who often are attracted to software development because it requires logic and the ability to abstract sense from complexity. We study requirements, both technical and business, and abstract them into architectures, designs, and finally code. We then implement the code onto hardware where it works perfectly, over and over again. What satisfaction!
Unfortunately, Scrum asserts that projects have too much complexity for the above approach to work: the people, changing requirements, and unstable technology ruin successful, long-term abstractions and solutions. Scrum’s approach is frequent inspection and adaptation. After all, the one constant is that everything changes. We should expect that any decision we make will be useless by tomorrow as changes obviate its accuracy.
In my courses, I use many exercises that are designed to teach students to reason out answers to complex problems. I point out that each answer has its own merits and faults, there is no perfect answer, and new complexities likely will render the answer ineffective by the next day. I want students to be able to come up with answers on their own, based on their knowledge of Scrum principles, and be willing and expectant that the answer may only be good for one second. At the same time, I want them to have confidence in their problem-solving abilities with Scrum because whenever a solution becomes suboptimal, the inspection and adaptation principles of Scrum will make it obvious.
The other principle that I try to impart during the courses is that ScrumMasters and management should resist coming up with answers whenever possible. Answering questions is yielding to the siren song of command and control. The best people to answer the questions and come up with the solutions are the people asking the questions! Since they are doing the work, they are best in place to come up with an appropriate answer and to immediately change the solution when complexity renders it inappropriate.
Such a simple philosophy! Yet it’s so difficult to practice. After all, it would be much quicker to just answer the question and move on; or, from the other point of view, much easier to ask a question and have a ready answer provided for you. But true understanding of Scrum will have you dodging questions too, even when you know that a new stack of feedback forms awaits you, asking, “Why won’t you just give us a straight answer?”
