The How Might We framework is quite often called HMW. The framework was originally created to define and frame design challenges, but you can use it to address a lot of different challenges you might encounter.
The How Might We framework is basically a way to reframe a problem. You’re not only trying to see the problem from a positive perspective, but also opening your mind and consequently your possibilities to new solutions. This can be an amazing opportunity.
This concept has been borrowed from Design Thinking approaches. I have personally used this concept to resolve issues and impediments in my clients Agile transformation and adoption journey. It is a different way and a method to tackle things that would bring different views and perspective to life.
Normally HMW question can be quickly formulated if good findings / issues / problems statements have been identified. This definition of HMW should not take more than 15-20 mins / issue or problem. We would typically do this with a lot of white boarding, using Post Its, Pen and Paper.
When we redefine our problem with the How Might We approach, we are actually turning challenges into opportunities. It’s a process, and you might not get it right the first time. It’s an important tool for mastering the ability to develop creative solutions to problems. Redefining our problems in this way can unlock a world of possibilities.
Make sure your team is empowered to come up with even silly and crazy ideas. Create a safe environment where brainstorming is truly valued. At this point, don’t worry about the feasibility of the ideas, just brainstorm and go crazy. In some cases, the crazy-impossible ideas can be reframed in a brilliant and innovative way, so don’t constrain your mind or your team. HWM questions are a way to foster brainstorming and other ideation sessions.
Why are they called “How Might We”
“How” part suggests that we do not yet have the answer. It allows us to consider multiple avenues for innovation and reinforces that we are still exploring the problem and solution space.
“Might” emphasizes that there are many different paths we can go down when thinking about solutions. This allows for open-minded creativity and brainstorming and thinking about the problem from multiple perspectives. This “might” is where innovation becomes part of the process.
“We” immediately brings in the idea of teamwork. “We” should all work collaboratively to come up with a joint understanding of the problem and put our heads together to come up with a joint solution.
How should this work for an Agile team?
Reflect upon all the issues / challenges / Improvements as needed and identified during the retrospective, then reflect upon them to see and understand the context a lot more better (at times, we are emotional during the retrospective and want the whole world to improve)
Motivate the team to explore and come up with several HMW questions that could address the needs or the problem statements
Each question should follow the logic of “How Might We” and it should be followed by a verb, noun and type of the user base that we are trying to address the problem for
As a passing thought this approach of HMW can be used for any type of problem solving or identifying new ideas / thoughts / innovations or opportunities – this could be used in resolving the issues or challenging the current status quo of the Product backlog approaches, how user stories are to be developed, what solution would address the problem in hand.
I have seen a lot of people using HMW statements to invoke discussions leading into innovation, but as the case with some other models, they can go horribly wrong… Like too much of Open Ended Ness
- How might we make our app more usable?
- How might we redesign our website to make it better?
Or at times, we go so deep, that we have created a narrow view:
- How might we make our app’s add to cart experience more functional?
When HMW statements are too narrow, we lose all the incredible, innovative ideas that can come from them. With too much focus, we are stuck on one particular solution already. We want several different ideas to test at the end, so focusing too much on one solution will limit creativity and innovation.
Always remember that in addition of the description of the problem, a target customer must be defined for the project / problem to be resolved. In doing so, we are now trying to highlight the user and his / her needs (now notice we have got Persona as concept involved here)
Have multiple HMW ‘s for each problem statement, Each HMW question can then be understood as a prototype and testing in a short brainstorming session, The one that is the most appropriate one will then be chosen and pursued.
Key elements to take care of:
- Do not discuss a HMW question for too long, Timeboxing should be performed for each HMW and do not get bogged down in the phrasing of the question.
- It is essential to be optimistic and close to the needs of the user to come up with several good HMWs
Use the above ideas and thoughts in your next retrospective or product backlog refinement session, do share your experience and help us improve the approach and tool sets for continuous improvement approaches.
I propose this approach to be added to the concept of Liberating Structures
agilescrumworld 