Ask the Right Questions to Improve

About 10 years ago, the company brought in experts in software development processes. We conducted interviews with everyone: product, development, test, HR, and management. After two weeks, everyone’s voice was heard loud and clear, “we need processes and procedures to add structure and organization into our product development efforts.”

I volunteered to lead the charge in product development. I was optimistic and hopeful that I would be very successful leading process change for the 50 person team. I spoke with all the developers, product managers, and team leads. I asked them what they wanted. Based on their detailed feedback and answers, I developed some 20 processes that reflected exactly what they wanted.

Then I got lynched.

Asking the wrong questions

I made a huge error implementing an improvement strategy. The first step was diagnosing the problem through interviews. I put together a list of questions to ask the development, product, and management teams. Unfortunately at the time, I didn’t realize I was putting together questions that weren’t useful. These questions avoided getting to the root causes of problems.

The second step was to create step-by-step procedures for people to follow to make everything better. I assumed that people where speaking for themselves when they said where they wanted change and improvements. Unfortunately, what they were actually saying was, “I want everyone else to change to make me better.” It was all black and white, no shades of grey. The procedures I created looked like extra work to everyone and didn’t solve the problems.

In hindsight, the questions I was asking had lead me down the wrong path. Instead of having questions that provoked thought and reflection, I used very specific questions that in most cases:

  • reinforced the current roles
  • gave voice to blame
  • caused people to relate problems that were unique only to themselves
  • didn’t foster an atmosphere of collaboration or ownership.

These questions were were things like, “Why are the requirements hard to understand?” It’s seems a valid question but it isn’t. This question pre-judges that all requirements are hard to understand. It pre-supposes that one person is responsible. Asking 50 people this question can lead to 50 different problems. My process checklist would have covered all of them. Although the question invites people to tell you what’s wrong, the question doesn’t provide a pathway for insight or ideas. They completely ignored the root causes. I would get an answer even if only one requirement out of a hundred was problematic. What I needed to do is ask more effective questions.

These questions can become a diagnostic tool to find out where the real problem lies. The question changes from, “why are the requirements hard to understand” to “what prevents you from writing better requirements”.

Powerful questions are better

Powerful questions are powerful because they are open-ended. Great questions are open-ended, non-judging and helps to foster new ideas and visions about possibilities.

Within a software development environment, I’ve used the questions below to great success in understanding what the issues are. Teams can use the answers to guide improvements to make the team and the work environment better.

  • What improvements have you seen in the last month or two that affected you?
  • What improvements did you expect to see?
  • What improvements would you like to see?
  • What difference do you hope I’ll make?
  • What does your perfect world look like?
  • If you were the CEO, what would you change today?
  • What dependencies outside your team have you dealt with this week/month?
  • What outside your team influences your work the most?
  • What situations can be changed to make work more enjoyable?
  • Why did you come to work today?

I use these as baseline questions and ask them as they are. I can also tailor them to suit the circumstances. Each question is open-ended and when you ask them, you’re rewarded with an incredible wealth of information. You can also get a lot of criticism so prepare yourself.

Making sense of the information

Once I’ve collected the information, I categorize and publish it to all participants. Depending on how open your shop is will dictate how much feedback you’ll get. I’ve worked in a closed shop were I needed to walk around to get feedback. I’ve also worked in an open shop were people are uninhibited to give their feedback. Either way works as long as people are involved.

I include a list of the top most beneficial improvements based on the number of people who cited it. I use retrospectives or more frequently, a targeted workshop to address the improvements and derive a way forward. Some areas where this has helped included:

  • Customer & user interviews,
  • User testing,
  • Exploratory testing each day on the daily build,
  • Backlog grooming, and
  • Manager transformation to a servant leader style.

As long as there’s strong management support and a willingness to take a short term productivity hit while new ideas are tested, it’s very possible you’ll be successful even if the idea itself fails.

Buy-in to changes

These types of questions are great to get people to reveal their inner most thoughts on their work and work environment but they also make getting buy-in to any changes easier.

In one example, the use of powerful questions got the development team to think of better ways to elicit requirements:

  1. The team wanted to be part of the requirements process.
  2. The team wanted to talk with customers and users.

These were combined and done at the inception workshop. After talking with users and customers, the insights provided to the development team caused almost all user stories to be thrown away and rewritten. It was a powerful result and exceeded most everyone’s expectations. It also scared the product manager but to their great credit, apart from asking, “are you sure”, the whole team prevailed. Exit interviews confirmed the development team’s high satisfaction level with the result.

Conclusions

Powerful questions can lead to System Thinking by examining the linkages and interactions between people and processes.

Powerful questions can help build relationships where business had in the past created divisions through role definitions. They ignore the prejudice of role definitions and can lead to a 3rd person perspective.

Powerful questions can help reduce or eliminate a culture of blame. They tend to focus effort on a yet unknown future state, using lessons from the past as a springboard for new thoughts and ideas.

 

 

 

 

 

 

Author: Robert Boyd

I’m a CSP (Certified Scrum Professional), CSM (Certified ScrumMaster), and CSPO (Certified Scrum Product Owner). For 30 years I’ve been streamlining processes and systems. I’ve introduced agile methodologies to software and product management departments, resulting in a 300 percent increase in feature deliveries.

Leave a Reply

Your email address will not be published.