Why you should ask the team more
“Ask the team.” This advice has helped me the most to become the Scrum Master I am today. It’s so simple, yet so profound.
I invite you to read the entire article, to get a more complete picture. But for the impatient, there’s a tl;dr below.
When I first started in this role, I was convinced that my job was to make sure that everyone in the team remembered what the Scrum process says, remind people to join the stand-up in the morning (and scold those coming late), book meetings, and stop people outside of the team talking with (read: disturbing) people inside the team. I saw myself as a custodian of an established process.
Now, I view my role as a manager of process. My aim is to make the process better. “Better” in the sense of more suitable for not only the people, but also the work at hand. While the others concentrate on actually doing stuff, I sit on the sidelines, watch them doing it. I then try to identify things that could be changed (thus improved).
Now follows the million dollar question: What should be changed, whom does this affect, and how should it be done instead? I claim that the correct answer is: Ask the team. This way I get to ignore the lesser questions of what, who and how, and instead concentrate on the question that matters: the why.
Let me elaborate
I could go around and shout orders at people. With some luck, my orders might end up being the optimal ones, and even shouted at the exact right people. In this case, things would actually be a very quick and effective, in the short run. In the long run, however, the team starts to use grandma’s pot roast recipe. Doing the thinking for the team skips the why completely. We have a separate word for this in Finnish: karhunpalvelus, a bear favor.
I could explain to them the why. “Hey, Steve! You need to do that one thing to that first stuff. Otherwise we can’t do that other thing to the final stuff.” Alright, we’re making some progress. But what if Steve doesn’t agree with my assessment? He might not think that having the other thing for the final stuff is all that important. Or maybe nobody, under any circumstances, should do the one thing to the first stuff, ever! Even worse: He might not say any of these concerns out loud, since it’s an order, and obeying orders leads to good performance reviews. Or at least so he thinks.
Instead, I ask the team: “How’s it going with the Friday’s deadline, the one with the final stuff?” This forces the team to figure out the why all by themselves. This is usually when the magic starts to happen. Questions start to run in their heads: “What were we supposed to do with it?” “Why was it important?” “What’s in progress right now for that?” “How much is left?”
If the team doesn’t have enough information to answer the question, now is the best time to find them out. And thus, together we go off finding the answers to these questions.
This isn’t only applicable to the daily technical work; it also works (maybe even better) when doing “the other” stuff:
“Hey guys, when do you want to have your stand-up? Remember that we use it to go through what’s going to happen that day, so it should be pretty early.”
“Alright, we’ve had four-week sprints for the last six months. Are we happy with that length, or should it be changed to something different?”
“It looks like we’re not going to meet the deadline with these features. Are we going to concentrate on keeping the deadline, or the scope?”
This makes sure that they come up with solutions to the problems that everyone agrees with. This gives internal motivation that keeps people interested and invested in their job. They now understand the thought process behind all the questions, since they were the ones making the thinking. This is the reasoning behind the mantra “bring me problems, not solutions”.
You want to avoid doing too many decisions alone, all by yourself. Instead, involve the people around you in decision-making. This helps not only with rubber-ducking, but also gives purchase to any raised issues by involving others in the process; you need to spend less time convincing other people, since you have came to that one conclusion together starting from why, arriving at a jointly agreed-upon what, who and when.
The role of a Scrum Master here is only to ask the right questions at the right time, and make sure that you get appropriate answers for the appropriate problems.
Yes, making the team think is sometimes (usually?) slower. But only in the sense of “it takes more time for things to start happening.” You need to remember that this is a long-term investment. When the people are in it together, things will work smoother later on. They’ll be able to use this knowledge later on. If, however, there’s no time to think, and it needs to be done right now, sure, go ahead and lay out the action plan for them. But once you’re done with that, make sure to have a postmortem to ask yourselves how you ended up in this situation.
Also, yes, having a thinking team requires motivated team members. If you ask the question and the room remains silent, you have a communication problem in your hand. This probably needs to be solved with highest priority. Remember that communication goes both ways (you and them), both ways (speak and listen). And start by making sure that you are not the problem, otherwise you won’t get far.