Asking questions is an art, are you still fingerpainting?

Several years ago, I was asked to attend a backlog refinement session because they were having problems with getting accurate estimates. They specifically asked me what they needed to do to get the QA people in the meeting to ask questions. This department had recently gone through an "agile transformation" and was on the verge of switching to Kanban because Scrum "just wasn't working." I know at least half of you just cringed, it's ok. For kicks, and an opportunity to demonstrate just how clearly bad so many of these meetings were going, I'm going to re-create a couple minutes of the meeting for you. Enjoy.

Product Owner (And dev manager if memory serves): Ok, ticket 24029 (load on screen on wall because team doesn't have laptops). Developers, what is your estimate for this?

Random single dev: umm… 4 hours

PO: QA what is your estimate?

Random single tester: Umm… 4 hours

PO: ok, next is 24542. Dev, what is your estimate?

Dev: umm… 4 hours

PO: QA?

QA: umm… 4 hours

PO: alright… 24601. Dev?

I'll spare you the rest, but this went on for an hour. And I'm pretty sure I never heard a single estimate that wasn't 4 hours. Now, let’s pause for a minute and let the genius agile professionals reading this head down to the comments and point out at least 2 things going VERY wrong in this meeting, other than questions not being asked.

It's ok.

I'll wait.

(feel free to fight about it too)

My role at this point was not agile coach, sadly. I really wanted to dig into all of the wonderful reasons you put in the comments as to why this meeting was failing (I'm so proud of you all), but I'd been asked specifically to focus on getting the QA team (and not the Dev team for some reason) to ask questions. I set up some quick discussions with several people that were in the meeting and asked why they weren't asking questions, here are the most common responses I received, in no particular order:

1.  No one has answers during the meeting, so why bother.

2.  I don't know enough about what is in the project to ask anything.

3.  I don't feel safe asking for clarification.

4.  I don't know how to ask questions without dealing with the side effects (No one having answers, not feeling safe because I asked a "dumb" question, being ignored, honestly a lot of the safety issues).

Now, the solutions for some of these issues are very straightforward and I won't be digging into them, but for the curious here you go:

1. Make sure the Product Owner, or anyone involved with designing the projects, are prepared for questions, or make sure they get answers outside of the meeting asap.

2. The development team needs to be prepared for the meeting as well, look at the tasks likely to come in to the sprint and prepare questions so they don't leave the meeting without knowing what they need to know.

3. Hire Inclusive Agile to help you build real psychological safety in your company (shameless plug, but true).

4. Read the rest of this post.

Since the only thing I was allowed to address was the asking questions bit, I dug into it. My wife and most of my co-workers have regretted that ever since because I have become obsessed with questions. I spent a few weeks digging into different kinds of questions, ways to get good answers, why people are hesitant to ask questions in the first place. Questions became my life. On the other side of that fever dream of research I ended up with a training program on the art of asking questions. Let's dig into some of the key points!

I believe a question needs three major components:

1. Context

2. Openness

3. Honesty

Context:

Context is where I suspect people will find the most value in improving their question asking skills. What happens with pretty much all of us all the time is we somehow forget that people can’t read our minds. I'm sure you've heard the most random questions come up in a meeting where you have no idea how to even start replying! Usually that asker just forgot they needed to provide some context. Let me give you an example that might be useful.

Question: What does that button do?

Answer: It submits the form.

Pretty basic, and it might be the answer they're looking for, but there is a LOT of information that the asker might need that isn't being conveyed. Let's try again with some context.

Question: I'm in charge of making sure that this form is properly sending all of the information to the correct database tables and need to make sure I'm catching all of the possible failure points in between. What does that button do?

Answer: That button initiates the API connection to the server and sends the raw data there, the server then parses it and sends the information to the database

The context here helps avoid needing to ask 20 follow up questions to get to the information that is really needed. We are losing a lot of time in meetings to follow up questions to figure out the necessary context that could have been shared up front. Personally, I'd rather risk wasting 30 seconds to provide context that people might already have to wasting 10 minutes trying to figure it out the hard way.

Openness: 

When I say openness, I mean that the question should be open ended. A lot of people tend to ask yes or no questions because they are more likely to get a clear answer. Unfortunately, when you only have two options for answers you don't have the opportunity to provide something else that might be valuable. And often, people don't even realize there was information that needed to be conveyed! Here is an example of a bad question that cost a company I was working with a good amount of cash. For context (hey, it's important isn't it) the department was looking to host their web based application in another country and needed to have local hardware in that country for various laws. Here is the dialog between the dev team and the operations team:

Dev: Are the servers setup?

OPS: Yes.

And the dev team went on their way being confident the servers were good to go. The day that we were supposed to launch some services, the dev team went to go deploy and found that none of the required software was installed on any of the servers… Lots of people were very angry, and the delay took over half a week. Whose fault was this? I have no clue, but I do know it could have been avoided with a better question. I'm assuming when asked "are the servers up?" the OPS team heard "are they running?" and said yep! While the dev team meant to find out if the servers were ready to be deployed to. So, how could we have phrased that better? With either a LOT of context so we can get to that yes/no, or with an open ended question. How do you think it would have gone down if the question asked was:

We're going through our pre-deploy checklist, what is the current status of the servers in regards to deployment?

I don't believe the OPS team could have just said "yes" and if they had given a vague answer I suspect there would have been follow up questions.

 Now, before I get too much hate, there are good reasons to ask yes/no questions, but only when you NEED to get a binary response. You don't ask open ended questions like "what are your general thoughts about whether you've been shot or not?" and when you're looking to get a commitment from someone you had better be nailing that final question down to a yes. Otherwise, avoid them.

Honesty:

Honesty and sincerity are what I believe will make you a person that people actually like it when you ask them questions. I am certain you've all had people use leading questions or seen someone use a "question" to just give weight to their statement or opinion. For example, that blogger Brett Barker is the most entertaining read I've seen in years, right? I have seen countless people use this tactic to get people to agree with them, and rarely does it feel sincere.

When you are asking someone a question, they need to know that you honestly want the answer. This is harder than you think, because a lot of agile coaches have been trained to lead people to the solution they think is best by directing them with questions, and that is just manipulation. I have a rule when starting a coaching relationship that I never ask questions I think I know the answer to. If I think I know the answer I will explain what I understand then ask for their perspective or to help me understand better. I feel this has created a much stronger relationship with the people I work with, they know and trust that I want to hear what they have to say, and they are far more likely to be honest and open with me because of that.

This barely scratches the surface of my obsession with questions, and I could easily talk about the subject for hours but my editor said that blog posts can't be longer than novels so you get to deal with just this for now. But please, take a few minutes today and think about the questions that you are asking, the questions that are being asked in your meetings, and how much time money and value is either lost or gained based on how those questions are asked. Think about this next time you cringe at a question someone asked and find out how to structure it so it is a valuable question. And most importantly, think about my poor wife who is constantly being peppered with questions that have 10 minutes of context that she doesn't need. She is the real victim here.

In the end I was able to give this training to the QA teams involved, and you're not going to believe the results! Nothing changed, because the fact that the testing team wasn't asking questions wasn't the problem. Come on leaders, stop trying to blame the employees for agile implementations not working, it is almost never their fault. This is a very common occurrence when someone sees an issue and decides they know what the solution is, but in reality they didn't know what the actual issue was. To really get down to what the real problem is, sometimes you need an outside set of unbiased eyes to dedicate some time to identifying what that issue actually is. Fortunately, I know a group that can do that! If you are interested in talking to us more about asking questions, or finding out what the root issues are with challenges you are dealing with, we would love to talk.  And I would love to discuss questions more, so please ask anything you want in the comments!  Just note, any questions without proper openness, context and honesty will be met with brutal mockery kind and compassionate feedback and support.