“If your only tool is a hammer then every problem looks like a nail.”
– Abraham Maslow

The Problem Solving Business

In IT, our job is to solve problems. Whether you look at the project as a whole, a requirement, a user story or potential risks to be tackled, there are problems all around us. Nobody has exactly done this thing before.

We’ve taken the first important steps previously: We’ve identified our problems  stating them in event, cause, result plus we have defined what is important to us.

“A problem well stated is a problem half solved.”

– John Dewey

Moving onwards, two important facts need to be understood when trying to plan or strategise for solutions to our problems:

Everything is heuristic & Sometimes, the best solution is to fail gracefully

Anything we do to solve problems is bound to be heuristic. A heuristic has the potential to both succeed and fail. The outcome is mainly influenced by experience and expertise of the person or team using it, their ability to estimate their current situation and the future situation(s) they can reach by applying the heuristic.

An example: A squad of soldiers find themselves behind enemy lines. Several heuristics they could employ are:

• Find higher ground to get bearing of their position and surroundings;
• Try to establish connection with homebase via technology;
• Use stealth or decoys to find their way back;
• Fight their way back as quickly as possible;
• Do the exact oposite and push through to a safe position and reevaluate.

These aren’t all mutually exclusive. Some logically follow up one after another. Sometimes you’ll have several successful outcomes, only to fail in the end, like having the upper-hand in a chessmatch, only to lose in the end.

Plans & Strategies

The difference between a plan and a strategy is contingency. A plan is like a booklet to put together an IKEA table. Don’t get creative with that stuff, just follow the plan or it will likely not work.
You can have a meeting with several people and come out having a step-by-step plan to release your product to production. If any of the steps fail, you’ll likely have another meeting to patch it up.
In Chess, I often open with a 4-step-to-checkmate plan. These are 4 steps I need to carefully take in the beginning of the game, without miss and without having my opponent shortcutting it. This is a plan which is part of my strategy. When it fails, I need to start thinking in terms of contingency and build a new plan.

A strategy can almost be seen as a set of plans, each building upon one another or providing alternatives when something goes bad. Build strategies based on your experiences, expertise and skills by discussing them among each other, learning from failures, extrapolating what worked and sharpening what didn’t.

Mitigating Risks by Implementing Solutions

Following How to Identify Risks? you’ve defined what’s important and what could impact your product negatively. Now, you’ll want to start making sure those bad things, don’t happen. We’ve moved away from an over focus on functionality and are now broadening the Team’s idea of which activities influence Quality as a whole.
You can not solve these problems with a tester doing test cases. If this was a big part of your project’s ‘strategy’ you’ll come a long way by the end of this phase.
Here’s the step-by-step:

1. Gather people with specialities in: analysing, building, testing and operating
2. For each Risk, discuss what possible solutions are available
3. Find a balance between roles and activities

Gather people With Different Specialities

Oh yes, you’ll be tired of reading about this step by now, so I’ll keep it short.
If your RiskStorming Phase 3 consists of only carpenters, all your risks will look like a nail for which a hammer will be the solution. Testers will test, developers will craft code, analysts will analyse,… It would be sad to have come all this way in RiskStorming, only to discuss one facet of influencing quality.

However, doing RiskStorming within a group of like-skilled people could be benefitial as a learning opportunity, such as within a community of practice.

For Each Risk, match possible solutions

In RiskStormingOnline.com we offer a grand 120 possible activities that can help you tackle your risks. They include Techniques, Heuristics, Patterns, Observability and Dealing with Change cards that will help you connect possibilities to problems. In the future, we’ll structure the cards differently to match the skillsets: analysing, building, testing and operating. For now, you can flip, scroll & search through many ideas and prompts that will help you tackle risks.

The idea is to find common ground between Team members. ‘oh, you’d like to do stress testing? I can see an issue that we don’t have a controlled and isolated environment for that. Maybe I can help set that up!’ & ‘That’s a great idea! I’ll activate extra logging so we can learn more.’,…

The focus is on sharing ideas, extending helping hands and finding comon ground. If people have been saying ‘Quality is a Team Responsibility’, then this is the moment it actually takes shape.
Only now have your teammembers understood sufficiently what quality actually means and how they can work together, from within their roles, to achieve it.

Find Balance

If your solutions are mainly showing a similar colour, that means your solutions are too one-sided. Try to balance out the colours and discuss how one failing activity might be supported by a different activity.

E.g. If we don’t catch issues during the story mapping, we might find them during our End-to-end UI automation or when our testers go through the business scenario’s. If all that fails, we might catch the inconsistencies during beta-testing during our Dark Release or during Real User Monitoring.

Find balance. Harmony.

What’s next?

You’ve gone through the three most important stages of RiskStorming:

1. What’s important to us?
2. What Risks will impact that negatively?
3. How can we deal with those Risks?

Lots of ideas and discussions float around, supported by cards, hopefully some epiphanies as well.
You’re probably lacking something concrete at this point. We’ll explore this in a next post.