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.

 

 

 

 

 

 

3 More Questions to Ask During Stand-ups

Most everyone is familiar with the three traditional Scrum questions answered during the daily stand-up as presented in the 2016 Scrum Guide by Sutherland and Schwaber:

  1. What did I do yesterday that helped the Development Team meet the Sprint Goal?
  2. What will I do today to help the Development Team meet the Sprint Goal?
  3. Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?

The purpose of the daily stand-up is for the Development Team to review the previous day’s plan and then arrive at a plan for the next 24-hours. In most cases, the Development Team can do this pretty well. The daily stand-up is a straight forward and simple meeting that focuses on the sprint goal but what could be done different to enhance the team’s daily goals and daily commitments, commitments which the Development Team will hold themselves accountable for.

To help focus the Development Team on the day’s planned delivered value, “What will I do today to help the Development Team meet the Sprint Goal?”, it is helpful to expand this into 3 questions before taking about today’s plan:

2.1 What is the customer value you’ll deliver at the end of today?

2.2 Is there something you can show the Product Owner today?

2.3 Is there something you can do to help get the most important story done today?

Now these three questions are not simply the fantasy of the Scrum Master but are arrived at jointly with the Development Team. Each of the above questions have their roots in team retrospectives and, in the beginning, the team wanted the Scrum Master to ask them. It’s very important that the team agree to any enhancements to the daily stand-up. For teams still early in their Agile journey, these questions will probably not seem unreasonable. However, for more mature Agile teams, there definitely needs to be a strong motivation to adopt them. In my particular circumstances, the Scrum Team was very mature and each of these 3 questions addressed a very specific problem the team recognized.

2.1.  What is the customer value you’ll deliver at the end of today?

When the question is asked, the team provides an answer in terms of acceptance criteria/tests that would pass at the end of the day that currently fail.

I started asking this question of the Development Team several years ago when it was brought up during a retrospective that during the daily stand-up, the team was focusing on the technical aspects of the work more than the customer problem they were actually meant to be solving. It wasn’t that the technical stuff wasn’t important, it is, but we wanted the team to keep some focus on what why and who they’re doing the work for. During the retrospective, the Product Owner said he was unclear of the progress of the user story, specifically the progress of the user story from a value perspective. More focus on the acceptance criteria and tests was a natural way to convey progress on value completed. The Product Owner was happy and the Development Team added the acceptance tests results as part of their daily planning.

This question provides an additional opportunity to further communications and collaboration between the Development Team and Product Owner. This is achieved by tying the customer, the acceptance criteria, and the solution together as a daily goal, a measure of value delivered each day.

2.2.  Is there something you can show the Product Owner today?

This question sprang from the Developments Team’s observation that some work was being rejected by the Product Owner, especially user interface work, too late in the sprint to correct it. The problem was the team was waiting until the story was complete before showing it to the Product Owner. This usually resulted in a new user story being written and added for the next sprint.

During the retrospective, the team recognized that some user stories and the intended value were being missed during the sprint because of the delay in showing progress to the Product Owner. The Development Team and Product Owner quickly saw that viewing incremental progress was the answer but the Development Team needed to alter how they broke down the work into tasks to facilitate this. It was breaking down the work differently that was the real challenge for the team as it required some work to be done that would ultimately be thrown away. This was the occasional stub or driver code to get some display components looking ‘right’.

This question provides an excellent opportunity to further collaboration between the Development Team and Product Owner. It serves to help focus on what ‘done’ means for a particular user story and helps reduce rework through a more collaborative approach to solving a problem. It can also make for a better product faster as the Development Team and Product Owner make any adjustments as a story progresses.

2.3.  Is there something you can do to help get the most important story done today?

This question got its start while 4 teams were working the same backlog and it was observed that new stories were being started while higher priority stories were still in progress sometimes with a large number of tasks in ‘To Do’. Although this question came from a Large-Scale Scrum (LeSS) implementation, it scales down nicely to a single team working a single product backlog.

What the Development Team was trying to improve during a retrospective was their ability to swarm until done. When I was developing, I would prefer to work it alone, without outside help whether I could use it or not. The Development Team saw that this mindset tended to slow down getting stuff done and suggested that the question be asked during the stand-up to heighten awareness that getting to ‘done’ was important. The way it eventuated was tasks still in ‘To Do’ for the higher priority stories were picked up. It also helped in identifying tasks that needed further breaking down.

The question provided additional visibility to getting stuff done rather than getting stuff in progress. Getting work done quicker gives the Product Owner maximum flexibility in releasing or A/B testing of new features. Unfortunately, companies sometimes look at 6 developers and wonder out loud why there aren’t 6 stories in progress.

Outcomes

After having the Scrum Master ask the 3 additional questions at the start, the Development Team began using the questions in context to their plan for the day and the questions themselves weren’t asked after a time. These 3 questions helped the team find the deeper meaning to the question, “What will I do today to help the Development Team meet the Sprint Goal?”

Please drop me a line and let me know what you think and your results if you give this a try.