Those Who Failed

Beren Van Daele, Quality Coaching

This blogpost follows the earlier ‘Versus The Endboss‘ post.

Many actors were part of the story. Some helped, some saved the day, some helped us take a step further, some failed. There’s a lot to learn from the steps that worked, those that didn’t; and why.
I’m not claiming everything I did worked. Nor that everything others did, didn’t. One could argue I should de-personalise this post and only write about behaviours, rather than the people.
Keeping it personal serves a purpose; as a consultant this teaches me details, sensitivities. Particularities that aren’t always obvious and seldom seen in a wholistic manner.

Enjoying some time off – Col Du Chaussy

I single out several people who came, did and went. Each of them have reviewed this post before launching it. We’ve kept in touch over the past months and they know I harbour no ill will, quite the opposite. In many, many ways, they paved the way for me to be successful and I hope I have had similar effects in earlier projects and will have in the future. While it’s fun to write about yourself as ‘the hero’ in the story, realise that there’s a host of supporting actors. Let’s be honest, I’m only the hero this time because of their help… and because I’m writing the story.

So what didn’t work? The problem we saw was obvious; this project couldn’t scale. It’s some kind of umbrella-problem for problems in communication structures, technical debt, product-dev malfunctions, bad feedbackloops,…
There were a lot of sub-problems we could identify and plenty of solutions to solve them. The world is a much messier place than identifying a problem, writing code to solve it, testing it and pushing it to production. Here’s a couple ways of going about change that were less than ideal.

Addressing the wrong problem

One person joined the team as a senior developer. He was a high-spirited man, easy to talk to, easy to listen to and a positive aura around him. He was experienced, but in a different type of company. While we were building software that had to bring in money quickly and do so for years to come, his experience was with projects that were profitable from the start and would need less maintenance over the years.

He was quickly frustrated with the ‘cutting of corners’ and ‘inconsistencies’ in our code. He was right.
This is however, not a case of right and wrong. It’s a case of making money or having an elegant product. Yes, that’s a false dichotomy. In this context, it was a trade-off that fell to the side of ‘making money’.

Excellent mountain water

One retrospective, he positioned the inconsistency of the code as an issue to discuss. Quite quickly, the discussion branched off and became the classic ‘tabs vs. spaces’ thingy. Which then became a joke.
As a result, through little fault of his own, he became the butt of the joke; ‘the tabs vs. spaces guy’.
He didn’t even have a strong opinion about it, he was very vocal about tackling the inconsistencies rather than having a preference one way or the other. He wanted to work together to make it consistent. So what went wrong?

He didn’t have buy-in from leadership. He hadn’t built up credibility with the team. Yet. He burned too soon. It’s difficult to time when exactly your ideas will gain traction and you’re not the only one fighting that uphill battle.

Addressing the problem in a wrong way

When you’re not focused on the first problem at hand everything can become a discussion point and everything becomes a battle. Another Senior Developer who joined before me suffered a bit from this. He had lots of experience in similar contexts. The main problem I could perceive was that his extensive experience lent him the opportunity to offer advice and give guidance in a great many topics.
This, and some other situations, created some friction between the team and him.

Especially the CTO found it challenging to provide feedback and coach this developer to a way of working that worked for the company.

If a company is doing well overall and nothing needs an immediate fix, which is most of the times the case, it’s important to follow the current and change small things at a time.

Not understanding who cares about what

Col Du Glandon – Until the snow blocks the road

I experienced a lack of confidence and purpose at some point. Steps had been made, more people became ‘endboss’ and were stepping up. It felt like a wheel was set in motion and it was gaining speed. My instinct told me not to push any further, and risk tipping the wheel over but rather let the wheel find its natural course.

I had been operating under assumptions that quality had to improve in order to scale. When I had my 6-month review, the CEO told me some interesting stories that swayed my thinking. My perceived goal was to improve quality of the work so that we could scale, but the real goal was to become less dependable on the CTO. The CTO was holding all the strings. There was no other way of dealing with the situation. The fact that we had a one person bus-factor created lots of anxiety both on the top and bottom level of the organisation.

As soon as I understood this, both my strategy as my narrative changed. When I was more focused on testing and quality at first, I changed tack to deal with systems, output and team performance. Had I not had this review, I’d not been successful.

Going in the wrong way

A friend of mine joined as a tester. His background was in software development and brought a couple of decades of experience. He helped change a lot. At times, we played good cop – bad cop with him coming up with solutions that were clearly good things to address, but difficult to achieve. He’d get some arguments against its viability, which then opened up room for a more balanced solution which I, or someone else proposed.

He did a lot of good work, and helped others achieve a lot. The problem was that he had entered the project from a sub-optimal position. He kept being boxed in as ‘the tester’, not truly being accepted to give technical advice. This made him feel as if he wasn’t having as much impact as he hoped he’d have. Which in turn made it difficult to communicate his value and eventually created a ‘mutual burn-out’. From his point of view, the drive became less and less and from the business side, the perceived value he brought lessened as well.

The Golden Formula

Lacets de Montvernier

I myself have failed often in different projects. You’ll find plenty of my blogposts over the years where I got frustrated and try, try, tried. This time, the pieces fell into place and I feel I have a better understanding to repeat this, become better at succeeding. I’ll still fail, but hopefully less often.

Is there a Golden Formula to come in and bring change?
Most likely, yes. Do I know all of the parameters? No.
Here’s a pretty good guess based on a lot of failure and some successes;

Find the balance between ‘being taken seriously’ and ‘having finance people breathing down your neck’. I ask for 20-30% higher than market standard. Be prepared to feel like an imposter, a super-star and everything in between as you try to justify to yourself and those around you that you’re worth it.
This isn’t something you shout at people until they take you seriously. It’s a subtle change of how decisionmakers communicate about you, treat you and listen. People pick up on these behaviours, not your rate.

How do you come in? From the bottom or the top? What’s your style? I’m more of a supporting leader and communicate that change takes time, but will last longer. This is highly context dependent though. Some companies will require you to come in with a mandate and bring change from top. I’ve experienced this can feel very paralysing as you’re vying for resources while at the same time not necessarily having the whole picture of the business.

Col du Galibier

What factors into the weight of your words? Leadership backup? Demonstrable experience? Built up good faith? Feedbackloops, both giving and taking are extremely important. Not just with those paying you, but also those with strong influence whom you might underestimate at first.
Some of my proudest moments are of enabling people to take one step and seeing them take the next ten themselves. Not only is this a giant leap forward for them and the company, but people remember who believed in them. They become strong allies.

In most cases, people have a way of not seeing things as they are or noticing what the real underlying problem is. In other cases they realise it, but have a hard time speaking the difficult truth.
What’s the real problem, though? You need to know this if you want to succeed in your mission.
How can you find out? There are plenty of workshops, interviewing techniques or assessments that can help you. I used RiskStorming in an atypical way to find out problem #1.

Perceived need.
How big is the problem and is this understood? Did people try and fail before you? In software development, different people often state “if we go on like this, we’ll grind to a halt at some point”. While hard to quantify this, some speak of growing technical debt, raising burnout possibilities, out-of-date technical solutions,… it does scare people. Especially those not knowing software, but having decision power.
If enough people predict such doom-and-gloom it’s important to swing it back to a positive note. Stay positive.

How do you measure success? What does ‘Mission Complete’ look like? This might not be obvious from the start, but I do feel it’s important to state some kind of deliverable from the get-go. In this case the very unhelpful metric “Ship 20% more PR’s” or something was put forward. It helped me gain some initial credibility, but was quickly abandoned. Eventually it became clear that my goal was to remove the dependency on the CTO. Not to remove the CTO, but make sure the company could survive if something would happen, whether that’s a bus-factor or a lottery-factor.

Lac d’Annecy

The moment the CTO said:

It’s the first time since starting this company that I had time to sit for an hour and think; How can I help the company forward now?

That’s when I knew my work was done.

Versus The Endboss

Beren Van Daele, Quality Coaching

A year and a half ago, I was hired to help scale a development team of 5 to many more.
They hired me to test, but paid me to help scale up. After 18 months of influencing, coaching, working in the shadows, joining the rave party and meticulous change management, I can proudly say we’re much further than I anticipated. This blogpost explains part of this story.

A Quality Assessment

Vernon Richards, who has supported me throught the assignment, had done one of his signature Quality Assessments for this client. One of his outcomes was that they needed someone to help them out with improvements in process, growth-mindset and systems thinking. That person was me.
Together, we set the other outcomes & ideas of his assessment into place. Slowly, but steadily.

The CTO bottleneck

As the company was still on the brink of scaling up and the CTO was very hands on and in control, our primary mission was to take him out of the process. Not bruskly, not unnecessarily risky but controlled, transparant and with respect to the tremendous work that was being done every day by this person.

Goro, Mortal Kombat Endboss

My process was roughly like this:

  1. Appreciating the process that is in place
  2. Create awareness of the problem
  3. Name the problem, impersonally
  4. Communicate an ideal, vague vision
  5. Implement, step by step.
    1. Enable people to set small steps
    2. Be an empowering ally
    3. Celebrate wins, loudly

The Rave Party

1. Appreciating the process that is in place

Starting to test with the team was a crucial moment for me to establish that I was here to help, to be a teamplayer and to be part of the group. The team released multiple times per day. The process was chaotic, fast paced and resembled, in my experience, to a rave party.

Bowser, Super Mario Endboss

I decided to roll with it. Several days, weeks,… I jumped from ticket to ticket, PR to PR, docker environment to docker environment, database to database, to provide quick feedback, move it to the next stage of the process and see it being shipped and re-tested again in production. It was the wildest and most fast-paced way of working I had seen.
Stuff went wrong sometimes, but we could quickly handle this.

It was awesome. Heartbeat-acceleratingly, high dopamine awesomeness. So what’s wrong with that?
Well,… it doesn’t scale, for one, and it’s not very human-friendly, among other reasons.
The process had its issues, but it was highly effective nonetheless. I was a fan of the way of working, the enthusiasm, the personal touch. It worked for this group of people, marvelously.

I was hired to make the process ready for bigger, more inclusive groups though. I endeavoured to gradually change it. A more controlled, paced and human process is now appreciated even by the hardiest of the hard workers.

The First Retro

2. Create awareness of the problem

The human-unfriendliness of the problem wasn’t how we approached this. Since the team consisted largely of young developers who were more than happy to throw all their brainpower to the problems they faced, it was the scaling issue we chose to address. This issue was the one creating most pain for the developers and especially the CTO.

Every PR that went to production was reviewed, merged and re-tested in production by the CTO. He did an awesome job at this, but there were several painful side-effects.

  • Feedback in the form of ‘We’ve built the wrong thing’ came way too late.
  • Big PR’s were postponed until eternity.
  • PR’s that weren’t handled immediately began gathering dust.

Effectively, 10% of all work was disappearing. That was half of a developer’s time going to waste on this issue alone.

Ilidan, World of Warcraft; The Burning Crusade Endboss

In the first retro we organised we started naming these issues, presenting the supporting data and making the issues visible. We continued doing this on many occasions. There’s no point in only stating feelings or uncertainties. Get data, show problems as they are and the negative impact they have.

The Endboss

3. Name the problem, impersonally

The CTO understood he was the bottleneck. He didn’t like it, but he saw no other way than to be the one in the middle. This was not a process, testing or technical issue. This was a trust issue. Very human, very real.
There’s nothing to gain in villifying this person. He was doing massive work and it was up to the rest of us to gain his trust.

Sephiroth, Final Fantasy 7 Endboss

We named him Endboss. Endearingly.
The Endboss phase was added to our Kanban board. It was the phase where the ‘yay’ or ‘nay’ was given for a PR to see the light of day. The developers, the tester, the analysts,… We all worked together to train up our PR’s to such high quality that it could survive the endboss. It wasn’t an ‘us vs. him’. It was Us, helping each other become the best versions we could be, to show that we’re on the same level he expected us to be.

It was important that this was not about the person, but about the concept. Getting everyone trained to efficiently ‘defeat’ the Endboss is potentially the single most valueable change that was introduced for this development team.

Feedback from testing or technical reviewing that was repeatable became part of a checklist.
And whenever the endboss DID slap our work backwards in some cases, this became an important learning opportunity.

Death to the Endboss

4. Communicate an ideal, vague vision

The concept of having an endboss does not scale at all. We wanted to get rid of the whole concept, but we couldn’t achieve that yet without losing time on poor quality. Not yet.
Scaling up became our primary focus and scaling up needs a livable pace, human interaction and people working together to achieve high value.

An Endboss phase doesn’t fit into the goal of scaling, but it’s an excellent way of framing your problem. It creates a training ground for people to be stronger and work together more closely.
Keeping the vision vague enough is important. If you have everything planned out and ready to be ‘implemented’, you’ll find few allies to help build it with you. Ask for participation, try out ideas, experiment, learn, adapt. Do this together, as a team. Find balance & find

Quality Coach Perspective

Gary Oak, Pokémon Blue/Red Endboss

Quality Coaching is influencing systems to deliver better. Better, in the broadest sense. In our case, everything had to be more scaleable and in order to achieve that, we had to make sure our feedback circles were shorter and more to the point. Our developers started working more closely together and improved their output drasticaly. In the role of tester, I supported them in achieving this.

As a Quality Coach it’s easy to either lose yourself in working within the system (as a tester) or being outside of the system and directing (as a coach). Doing both was crucial in this context. I would not have earned the trust and respect if I hadn’t joined the rave party. I would not have had much impact had I not helped identify the next steps in improving our way of working and supported others in taking those steps.

What’s more?

A lot more happened on this project. It didn’t end with the Endboss phase, but it was a great start. We trained more Endbosses, we split up into teams with different Endbosses, we took out the CTO largely out of the process and are improving our pipeline to eventually get rid of our Endboss phase.
In further blog posts, I hope to outline our work in more detail.


Beren Van Daele, Running Isle of IT

I write this now, to capture and understand exactly what I feel. I’ll likely feel better tomorrow, today is an exercise of allowing myself to feel deeply and getting perspective. These posts are often emotionally driven, and its conclusion often comes as a surprise to myself.

Initially, I was going to write three separate blog posts. One on my experiences of hiring and employing people. Another on developing and selling your own product and a last one on consulting.
These were the three threads I was pulling over the last year, all the while a pandemic thread was pulling me back. My adventure turned sour very quickly. The buffer was shrinking and within a very small amount of time you find yourself in survival mode, rather than thriving mode.

Writing this feels very personal. I’ve felt paralysed for the past couple months. I’d appreciate hearing your insights if you have constructive ones. Though I still stand by my ideals, they’ve gotten a good beating. If you can help heal them, please reach out.

A Short Timeline

2019, December.
My project had been downright unrespectful and shady towards me. I decided to end the project and not start another anytime soon. I had a good buffer to support this decision and wanted to go on a business adventure.

I hired a seasoned event manager who I’d have worked with before. She and I wanted to organise events on Diversity and Inclusion in IT across Europe.

2020, March
I had just hired a junior developer who showed lots of potential. That brought us to 4 people, as there was one senior consultant that was already working with me for a year before.

Shortly after, the first lockdown went in effect. Within this hostile market, we started building a product called RiskStormingOnline, which is a collaboration tool for risk analysis. This was a successful workshop before the pandemic and it made sense to invest the idle time to make it possible to run it remotely.

At the same time, we decided to cancel all 4 Diversity and Inclusion events and run an experimental online event in September.

As time went by and funds slowly lessening, pressure to get back into the consulting game rose. Finding a project during these times proved to be a challenge.

I found myself taking care of people’s financial position, mental health, safety… while maintaining my own sanity.

2020, November
We survived.
After several unsuccessful interview trajectories, I finally found a new project as a consultant and would turn our steady monthly loss into a steady profit again.
The event in September was well organised, interesting and professional. If only more people had turned up.

The seasoned event manager was at a loss, as her whole career suddenly felt irrelevant. She decided to re-school herself to Product Owner, then Scrum Master.

The junior dev had been on a short project for 3 months, though that was ending soon.

2021, July.
Today. The seasoned event manager called me up this morning that she was going to accept a job at a different firm.
The junior dev had done the same two months ago.
RiskStormingOnline didn’t take as many steps forward as I had wanted. It feels stagnant and I don’t have the people to move it forward.
There’s two of us again. Both doing what we know, consultancy.


If I look at the aftermath of this whole situation on facts alone, I see that we’re back at where we were two years ago. We’ve managed to create a financial crater and then crawl out of it. We’re back, but we’ve lost two years.
That’s sour, but it could’ve been much worse.

Emotionally, I’ve taken regular beatings, most of them didn’t come as a surprise. I was just waiting to get this final one.
I feel like I stood at the forefront, working hard to move forward with only small wins to show, all the while creating stability for my people. I’ve worked hard during a whole year, regularly stepping out of my comfort zone, taking on roles I had never done before. Understandably, people’s patience run out and they look to improve their own situation.

Falling down, not staying down.

– Pearl Jam, Dance of the Clairvoyants

I am writing this to acknowledge to myself that I had a difficult time, that I feel I have failed in my business attempts. I have nothing to show for a year of hard work. I suspect most people would see this as failure. That’s my experience too.
On the other hand, I need to realise that due to these efforts, at least two people and their families will be forever changed. We survived a very difficult time together. Even though we are on different paths now and we might not appreciate the circumstances that befell us, we’ll think fondly of the people that we weathered the storm with.

Concluding, I uncovered this silver lining: I’ve helped people through my business. One aspect failed, another aspect did well. Only now I understand what a good friend had already told me.

I must lick my wounds and find the strength again to trust my idealism. I need time.

Failure is only truly failure if nothing is learned. What feels devastating right now, will be an opportunity in the future.

How To Improve Quality

Beren Van Daele, The Core of Things

“Give me six hours to chop down a tree and I will spend the first four sharpening the axe.”

― Abraham Lincoln

What’s next?

Another famous quote is: plans are worthless, but planning is everything. I’d argue that following through is at least as important. We used to only have 3 phases of RiskStorming. The Online version introduced a 4th: Commitments, Deliverables & Measurements.

We try to achieve two things in this phase:

  1. Broaden the backlog past Functionality
  2. Plan little steps to move forward on our Quality Journey
User Stories typically deal with functionality.

Past Functionality

Back in Phase 1, you identified 6 Quality Aspects of which Functionality is or isn’t one. In my experience, the team’s backlog is filled with functionality stories. There might be an odd security, performance or accessibility story or acceptance criteria or requirement interwoven in it, but that’s rather rare.

By picking at least 5 other Quality Aspects, identifying their priority issues and discussing possible mitigation steps you virtually built up several new ‘backlogs’ of work items that need some attention. Now I’m not suggesting you create 5 separate backlogs, or worse yet, start silo’ing these things up further in teams or roles or,… Please no.

Pick the highest priority issues, something of a minimum viable product and integrate them in your backlog/kanban board/requirement list,…
Don’t try to complete everything, you can’t, but tackle the most pressing things first. Convert these requirements/plans into work items for your backlog.

Move Forward On Your Journey

At the very beginning of your RiskStormingOnline workshop, you discussed where you are on your journey towards the a goal. In this stage, you can decide together how you’ll achieve the next step. Are you worried about performance being an issue?

  • Analysis: You might first want to define benchmarks for performance. What’s acceptable? What isn’t?
  • Operations: Can we check what the current average times are? What are bottlenecks?
  • Testing: How can we measure safely, smartly and reliably how the system will react under more stress, persistent load and large number of requests?
  • Development: Can we optimise our systems to make them more fluent? Do we need separate testing environments? Would they give realistic results?

Start with defining benchmarks and measuring what the current results are. Maybe ask a tester to explore and investigate potential problems and report back. Once you get a feel of whether things are satisfactory or not you can implement measures and drill deeper into the new problems, if they matter enough.

See how this ties into the heuristics, planning, strategising discussion from phase 3? Just like the squad that was caught behind enemy lines: First get your bearings, evaluate and scan your possibilities before taking a well thought-out action. …or take action and be ready to deal with the consequences.

How To Act For Quality?

Phase 4 is here to make things concrete. The discussions we have gone through to get here were invaluable. They gave you purpose, vision and means to achieve your goal. Here’s the next step to make them actionable, trackable and measurable.

  1. Make commitments
  2. Provide means to stay accountable
  3. Visualise your journey

Make Commitments

In Phase 4, we structure the information from the previous phases into ‘streams’. This means we see combinations of one Quality Aspect, a risk and it’s possible solutions. This gives you a great overview of what your team discussed.
From here, people or roles can make commitments to take action.

Compare it too action points following a retrospective. A retrospective without action points is a complaining session. A RiskStorming Session without action points can give direction, but has no plan.
Phase 4 helps you translate your discussion into actionable tasks, user stories, sticky-notes,… Any body of work you normally work with.

What you’ll be looking for is commitments from teammembers to take up part of the work that was discussed. Raising possible solutions but waiting for others to achieve them doesn’t help at all.


As far as possible, define what success would look like. How does the person making the commitment and other teammembers know when they succeeded in their commitment? What are they measured against?
Measurements have a bad reputation in IT, but they can be very helpful when applied specifically and when the team carries them. In other words, when the team defines the measurements together, the measurements are valuable and acted upon.

Measurements can be numbers, but also feelings, happiness, an achievement, milestones, KPI’s, OKR’s, the result of a questionaire,…

Goodhart's Law for Data Science and what happens when a measure becomes a  target?

Visualise Your Journey

Over the years, I’ve experimented with several ways to visualise where we are with our quality.
I encourage you to be creative and try your own ideas, things that make sense in your context.

The important factor here is that you find a way to make your progress visible to people within the team. This might be more difficult in a remote setting, but with various communication tools you’ll find plenty of ideas to share your charts, models, walls,… I’m sure.

Here are a couple of ideas:

A one-page-test-plan to capture the most important ideas on one page. Especially highlighting issues the team may have which they can’t solve themselves.

A RiskMap to hang on a wall to show phase 1 and 2 of RiskStorming. Buy some red and green stickers to highlight on the map what is going well and what isn’t.

A wall of bugs with actual pictures of bugs to indicate the severity. Butterflies are trivial, scorpions are blockers. Start exterminating!

What’s next?

Hopefully, this has been a wonderful exercise for you and the team. Not only did you learn about how to deal with quality and risks, but you applied it to your current project and your current situation.

Among many other benefits, these are probably the

  • Work that was previously invisible are considered wasteful is now brougt out in the open.
  • You can track quality in a more meaningful way
  • Whenever a new teammember joins, walking them through the results will be very enlightening for them.
  • The shared understanding of your product and project by your team has greatly improved.

Now is the time to make the next step on your journey. I hope you feel much better prepared now.

Virtual Tolkien Is A Free VR Recreation Of An Iconic LOTR Film Scene
Good luck on your journey, traveller.

How To Discuss Solutions?

Beren Van Daele, The Core of Things

“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.

Being great at chess means you’ve absorbed a number of heuristics and know how to apply them succesfully.

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.

RiskStorming Phase 3

For Each Risk, match possible solutions

In 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.

Obama’s famous Mic-Drop

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.

Model by Dan Ashby, adapted and coloured by Janet Gregory

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.