How to Identify Risks?

Beren Van Daele, The Core of Things

Risks are things that keep people up at night. Not just you, anyone. Taking a risks can make you feel alive, scared, overwhelmed, excited,…

Risks are based on Feelings

People often try to quantify risks. Any project with higher compliance requirements will tell you they estimate Likelihood and Impact, that they then put those in matrix and show which ones are minor, major or critical risks. Apart from helping you pass an audit, these practices also look nice and make you feel safer…
Feel safer’. No matter which process you use to quantify risks, it won’t ever remove that it’s all based on feelings. It’s a crucial piece of insight you need when discussing Risks: whatever you think, predict, foresee, expect,… is all based on feelings.

You’re a rope walker, who needs the right amount of skills, confidence and situational awareness to survive. Fear will paralyse you, overconfidence will unbalance you.

An actual rope walker

Trade-offs and Feelings

Remember this very same header in the “defining quality” section? It’s simple: Risks are the reverse of the quality medal. In a world where you’d have infinite resources you would still need do the same balancing act. They are two different ways to think and talk about the same thing. Ying & Yang, but dealing with them is exactly the same.
From a Quality point of view, in order to increase the fluency and flow for the User Friendliness aspect you gather data to find out where people leave, are blocked or face issues. In the same sense, added monitoring and user tracking, which might help you identify and deal with risks quicker, might infringe on people’s perception of privacy.

Ugh. Feelings? Balancing acts? Can’t measure or quantify any of this? Bah!

– Many people in IT

If you can accept this though, it will help you understand that the things we do in our field to deal with these problems are entirely beside the question. Without going too far into detail, there’s this model called Cynefin. It teaches us that different types of problems need different types of solutions.

If you believe Likelihood x Impact = Importance and your next step is checking several boxes to show the risk is dealt with, you believe the problem space is either Obvious or Complicated.
If you believe that risks are based on feelings which are different on who you ask, are bound to change and might need several possible and probable solutions you may or may not keep or discard, you believe your problem space is Complex or Chaotic

The important distinction is that you understand that nobody has done exactly the same thing as you are right now. There are no best practices, no guidelines, no experts who have done the exact same thing again. Almost by default, your first realisation should be that you are lacking information.

Don’t get into Cynefin right now, read this post first, ok?

Defining Risks

This blogpost is part of a series that uses to structure a discussion towards a better understanding of quality, risks and what to do with them.

Following Phase 1: Defining Quality you should have a selection of important Quality Aspects, but more importantly: a better and shared understanding of what’s important for your product and project. This is an excellent starting point to explore and identify potential risks.

  1. Gather people with specialities in: analysing, building, testing and operating
  2. For each Quality Aspect, One by one:
    • Think about 2 to 3 ways it might be impacted negatively
    • Write down your ideas
    • Include for every risk: Event, Cause, Result
  3. Have an open discussion about Risks

Gather people with different specialities

Traditionally, someone doing Risk Analysis would create a spreadsheet, make a list of all the risks they could think of and then consult the following people:

  • A Business Analyst to add a number to each risk for Impact. Something like: 1 if there’s almost no loss of money if the risk would happen and 5 if we’d lose a lot of money.
  • A lead Developer or Architect to do the same number-game but for Likelihood. 1 if it’s very unlikely the risk would happen, 5 if it could happen any day.

I’m not entirely against this process and especially like the interaction with other roles. However, some things we want to change in RiskStorming:

  • Include more specialities into the discussion such as testing & operations
  • Invite more people to quantify Likelihood & Impact values
  • Use the values, not as goals, but as discussion points

Writing down Risks

“If you can’t think of three things that might go wrong with your plans, then there’s something wrong with your thinking.”

Gerald Weinberg – Secrets of Consulting

I’m less strict than the famous Mr. Weinberg and will only ask you for at least two examples of how your plans could go wrong. Yet, seriously take your time to think in different angles about your product and project. Testers are particularly trained in this skill, give them some input and see which questions they come up with.

Once you identified an idea of how something could go wrong it’s not sufficient to just note down ‘Hackers get in and steal our data!’. Though this is a good starting point to discuss further, try to specify three aspects for each risk:

  1. Cause: There are inconsistencies between layers of the application, leaving an exploitable gap
  2. Event: Someone with malicious intent gains access to the inner workings of our system
  3. Result: Data is stolen, removed or worse. We may face lawsuits, lose users and loss of business.

Exploring these three aspects to a risk gives you and the team a better sense of the gravity, possibility and consequences of the problem. You’ll be better informed as well as better prepared to take countermeasures.

Have an open discussion about Risks

Working together, you have now identified several risks that are actually tied to quality aspects that are important. They are well understood and discussed by the team. Nobody should later blush and say ‘oh, I didn’t know that was important’.

For each risk, people who can make an educated guess can specify a likelihood & impact quantifier, others can leave it to ‘?’. These values can help you prioritise, group or use them as a basis for your compliance process.

What’s next?

If you don’t do anything else with RiskStorming at all, having done Phase 1 and this phase with your team, understanding the lessons and taking heed to what you discussed, you’ve taken a huge step forward to building a successful product.

All Skyrim Enemies Lord of the Rings music 'Bridge of Khazad Dum' - YouTube
Some risks are scarier than others. Don’t have a wizard? Do RiskStorming Phase 3!

Now that you’ve identified the most probable and dangerous threats on your journey, you’re better prepared and equiped to deal with them. Phase 3 offers your team a whole lot of prompts and ideas to deal with them. Figure out what works for you, discuss and plan.


Read all posts made in this category here: RiskStormingOnline Knowledge Center

How to Define Quality?

Beren Van Daele, The Core of Things

‘We need to Improve our Quality!’, ‘We have bad Quality!’, ‘We sell a tool that measures Quality!’, ‘I’ll add some tests to improve Quality!’

These are just a fraction of sentences I’ve picked up over the years that make NO SENSE.

Quality is conflict

Quality is a word that creates divisiveness. It creates conflict and controversy. However, not all conflict is bad and this particular one is looming over our heads whether we face it or stick our head in the sand. You will pay a price.
Freedom, is a very similar word that lets us dream of utopic scenarios, yet suffers the same boundaries as Quality does. Both concepts find their limitations as soon as you bounce into someone else. When we permit ourselves a certain luxuary, it will more than likely impact someone negatively. Quality works similar.

Freedom, to me, is walking on a mountain without a care and nobody around me. How do I feel about someone claiming that piece of land for themselves and building a hotel there?

Quality, to me, is a smooth experience with no hassles, no passwords or extra verification. How do I feel about someone stealing, selling or even just viewing my data?

Trade-offs and Feelings

Both situations impact me directly, one way or another. A hotel can offer me comfort, lunch and ease-of-access. It also implies many more people can enjoy nature. It’s a trade-off. There is no right or wrong. There is only right or wrong in context. Additionally, what you base yourself on is a personal feeling. This feeling is influenced by your own personal values, principles, maybe even some data, but it remains your personal feeling.

Cycling Lac d’Iseo

Defining Quality

This is how I tackle Quality discussions. It is a step-by-step backbone that I will almost always follow. How each of these steps take form, how they evolve, who I include are very situational. However, this backbone is usually a firm pillar to lean on. This is also why my product follows these steps and enables you to achieve the same in an interactive and structured manner.

  1. Gather stakeholders
  2. Understand your context deeply
  3. Break up ‘Quality’ into more defined Quality Aspects
  4. Visualise Quality Aspects as Journeys

Gathering Stakeholders

People who matter. These can be users, teammembers, people in Marketing, Salespeople, people who wish to make profit from the product, external experts,…
Pay special attention to diversity and empathy.

Clippy Didn't Just Annoy You — He Changed the World

A diverse set of people with different skills, backgrounds, goals and dreams, demograpics, mindset,… will help you tackle your biases, blind spots and other points of failure. History provides us with many product failures due to biases. Example: Clippy, the ‘friendly’ digital assistant in Microsoft Office. During market focus groups, women who found the animations creepy and leering, were ignored.

Empathy is a seriously underestimated skill during these discussions. The ability to pick up when someone else would like to pitch in or feeling when someone else might have a better supported opinion than you might have is an amazing help. When discussions about Quality, or any discussions actually, become a shouting match, my advice is to walk out. Yet even then empathy can help diffuse the situation with calm explanations and reasoning.
Additionally, empathy enables someone to take the point of view from people outside of the discussion. ‘Oh, I don’t think Laura from opperations would like this.’

Understand your context deeply

Context is another word that is difficult to grasp due to its many, many facets. In Tech environments context usually means ‘everything around our product, project and happy team’. Lots of people are happy to work within the bubble of the project and leave the ‘working with the outside’ to managers, product owners, marketing or sales departments and do their own thing without truely understanding the ‘why’.

We’re not just building a product, we’re solving a problem. Someone, somewhere will be impacted by what we do. We need to understand our goals, failures and how we impact them personally within our context. If we don’t, we’re part of the problem.

This coin has a second side though, people on the outside can’t just treat the project as a black box and expect ‘quality’ to come out. This is one of the conflicts we need to resolve: Leaving our comfort zones and finding common ground, common language.

Our new product:

Breaking up Quality into Quality Aspects

In my experience as a Product Owner and working with other Product Owners I noticed a huge flaw. We are obsessed with functionality and have little patience for other quality aspects. Many people around us know this, but feel that their voice isn’t strong enough or that it isn’t their role to provide direction.
This results in a backlog filled with Functionality stories, with the occasional security, performance story or requirement.

This puts all discussions about important stuff that isn’t functionality on at least the second place. That is, until problems arrive… and they do.

With, we provide a simple tool to select and prioritise Quality Aspects. We offer 25 Quality Aspects that are designed to initiate discussion. Functionality is only 1 out of these 25 cards.
We introduce a limit of 6 cards to be chosen to encourage stakeholders to make these trade-offs.

Phase 1 of

Visualise Quality Aspects as Journeys

The important thing about this phase is the discussion, the exploring of different points of view, elaborating on their importance and making decisions on what really matters.

I like to think of these Quality Aspects as journeys. The easiest one is probably Functionality, since we’re usually quite familiar with this one. We often break this Quality Aspect down to a Minimum Viable Product. Maybe we have ‘a finalised product’ in mind. What we can usually agree with, is that we’re not at our destination yet. We still have steps to take. This next step is often the topmost user story of our backlog.

We need to keep in mind a similar way of thinking for the other Quality Aspects. What does the final destination of Security look like? What is the next step we can take?
Very often, we don’t really know what the next step is, what the destination is or sometimes even how to begin the journey.

At this point, you might think that this isn’t helpful?
On the contrary. Knowing what you don’t know is often more important that what you do know. It gives you the opportunity to learn, adapt and evolve.

Knowledge is power, France is bacon

– Lard_Baron

What’s next?

You’ve just had a discussion on what is actually important to the success of your project and your product. People’s ideas were challenged and are hopefully more aligned. Questions were answered, misconceptions straightend. But…

There’s still more questions to ask!

Lucky you. You’re on a journey, you’re learning and you’ve found people who accompany you.
Adventurers of old applaud you! Yet they warn you:

Fellowship of the Ring (Group) | Middle-Earth Films Wiki | Fandom
Adventurers from Lord of The Rings applaud you

No journey is without Risks.
Our next step will explore possible risks from as many angles as we can.

A well-informed and prepared (wo)men is worth two.


Read all posts made in this category here: RiskStormingOnline Knowledge Center

Launching Your Own Digital Product

Beren Van Daele, Product Ownership

At the start of my Product Owning journey a mentor gave me his number One tip:

Treat the product as if the budget came out of your own pocket.

I thought I understood him back them. Turns out I was wrong.


TestSpere used in RiskStorming

What does it take?

After months of hard work, we’re launching a new product in a couple of days.
It’s an online product that helps team collaborate on their understanding of quality, identify risks and how they can work together to achieve said quality and battle the risks, together.

Sure, we started coding some moths ago, but it actually started in 2017 when I launched a card deck called TestSphere with Ministry of Testing. Months after that, RiskStorming became a workshop which used the cards. Two years later after the workshop improved and improved over time AND gathered more ‘believers’ we decided to build it into an online tool.
It seemed logical to do so when the whole world suddenly went remote for obvious reasons.

Things working for us:

  • The workshop format was mature already
  • The userbase was modest but vocal and enthusiastic
  • The product adds immediate and clear value

To be invested:

  • 20.000 EUR and counting. (1 fulltime dev + several part-time freelancers)
  • Countless hours of my own time & headspace

Possible reasons of failure

  • Confirmation Bias bubble: People may be vocal, but this doesn’t translate to sales
  • User feedback wasn’t reflecting needs of the larger group of possible users

How do I feel about this?

A strange mixture of pride, fear, anxiety and excitement. It is my own budget, my idea-baby and my personal feeling of success/failure on the line.
When you have this much of your own skin in the game, your project fills you with both happiness and dread, depending on the day or even the hour. Sometimes I have stress-induced headaches spanning several days. Sometimes I feel like I can take on the world.

It’s a strange but exciting journey. Even in the worst case scenario, I may lose some material and selfconfidence, but I’ll have learned to be a more emphatic leader and human being.

If you’re in product ownership, management, leadership, I dare you to fund your own project. You may curse me for it afterwards, but you’ll have grown considerably.

The Product?


Early version of RiskStormingOnline

If you want to know more about what I think was worth the investment and effort, read on.

RiskStormingOnline is for you if:

  • You believe your team can’t define Quality as a group.
  • You suspect there are highly important risks that are being ignored
  • There is no clear strategy or plan to build in Quality from the start

We launch on the 3rd of September 2020.
Interested? Sign up here

My Dealings With a Pandemic

Beren Van Daele, Running Isle of IT

People who follow my journey somewhat may know that at the beginning of 2018 I decided to break with a great many things and journey onwards. Up until recently, the road (business-wise) has been mainly littered with proverbial candy. Now, in what seems to be a resurgence of the global pandemic, a first real threat to the business has been culminating and will likely continue to do so. This blogpost will give you insight in my thought process and feelings of the past couple of months and what we’ve been doing so far.

The months, even years, that happened before the lockdown now feel like they were preparations for today. The moneybuffer the business amased, the hires, the projects, all of it suddenly shifted from ‘business as usual’ to ‘how is this helping us to survive?’. Let me shed some lights on the cards we’re holding.

Some Dreadful Things

Just before the lockdown, I hired two new people. Joanna is a seasoned event organiser, Aline a junior front end developer. The third employee, Geert, has had a good contract at a customer in media for some time and continues to do so. So steady income from one, while three (including me) are currently costing. We can see a slow decline in our moneybuffer monthly.

You can imagine that events got cancelled overal and it’s extremely difficult to find projects for juniors in such a market. Finding a project for myself at a reasonable rate seems to be difficult too.


Hiking the Ardennes

For four months, we’ve been trying to find projects for either me or Aline, the front end developer, with no avail. This has been frustrating and stressful to say the least. Please realise that this includes: Countless times of ‘not hearing back’, doing interviews with no feedback or answer, being disappointed on a daily basis. This is difficult for me, but also impacts the morale Aline, who may start feeling like a burden rather than an asset.

Another aspect we face is that events were planned, but uncertain. For some weeks we were hopeful to organise them in a safe way. However, now we decided to hold only one event online. These experiences are rollercoasters in a time that one wishes stability.


Kayak with the team

Some Hopeful Things

Because we have a small organisation that values transparancy and communication I can truly feel everyone engaged to make the best out of this situation. They’re thinking, even to their own disadvantange, about ways to help the business forward. I can feel that they love being part of this. That they subscribe to this ideology. That they want this company to succeed.
This is probably the single proudest achievement for me.

We have a good buffer that will last us some time longer even though I can see that number declining slightly month after month.
I can see Geert taking his responsibility to continuously work and bring in the baseline which we need.
Joanna is using her strengths to enlist people to her cause. has had some major setbacks, yet she’s building a flame that is growing brighter day by day.

Aline and I? We’re building something I’m very hopeful for:
She’s shown incredible motivation and aptitude in digitalising this workshop which I feel can help so, so many software projects. We’ve been able to recruit the help of several more experienced people to help us get to something marketable quicker. Check out the beta version here:

This Is Not a Cry For Help

This is a window into my head, do with that what you will. As an employer, you take the risk. You reap the profits when things go well and you carry the risks when they don’t. That’s the simple truth.

The complexity behind it, the feelings and many events contributing to your state of mind are much less obvious. There’s the great pressure of having people relying on the company for their income. It’s both a (self inflicted) blessing and burden.
Another challenge is the daily planning for an uncertain future and hoping you’re making the right choices. There’s a constant influx of trade-offs to be made.

Should I invest time to find Aline a project, or make sure she can focus on
Should I accept a less-paying job for myself, getting some extra money, but having less time for others, possibly burning myself out?
Should I put all my eggs in the RiskStorming-basket?
How much more time do we have in this ‘normal market’ until the pandemic hits again?
Do I ask people to go temporarily unemployed and save some money while leaving people in the cold?

These are a few of many considerations that I’ve had to deal with once, multiple times or even daily. All the while, checking in with people around me.
These same people, whom I respect and love, often second guess my decisions. They shake my convictions. They give me hope, but they don’t take it easy on me.


A much needed weekend together in Belgium

In the future, I may regret some decisions I’ve taken these days. However, I’ve learned a great deal of what it means to run a business during ‘good times’ in preparation of ‘bad times’. I’ve learned to treat advice for what it is: Glorified experiences. Very little people have dealt with running a company like mine, with its values and ideology in a global pandemic situation.

Advice is a form of nostalgia, dispensing it is a way of fishing the past from the disposal, wiping it off, painting over the ugly parts and recycling it for more than it’s worth.
– Baz Luhrman, Everybody’s free

We’re doing well. We could use some more good news here and there, but all in all, our foundations are steady and we’re building towards the future.


Daria & Joanna at their own Polish weekend


Dipping One’s Toes Into Testing

Aline Lanckneus, Experience Reports, Software Testing

How does one get into testing? From what I’ve heard, most testers don’t go to “testing school” but they simply fall into it. The same applies to me. 4 weeks ago I was attending a coding bootcamp where I found myself longing for any kind of feedback and mentorship. About 3 weeks ago I was offered a contract by Isle of IT as a junior test consultant. That’s how many weeks I have dedicated so far attempting to learn everything there is to learn about testing. 

Before all of this I was realising a lifelong dream, becoming a veterinarian. Obviously, if you’ve read the paragraph above, you’ll know this particular dream didn’t work out in the end. Instead of talking about why I decided to end my veterinarian career, a question I have had to answer too many times in the last couple of months, I’ll briefly talk about the skills I believe and hope are transferable to testing. 

Aline and Geert in Ardennes

Aline and Geert in Ardennes

Testing Powers and Veterinarians

Asking questions for example. When diagnosing an animal, we learn to ask questions. In general, you aim to ask just the right amount of questions. Ask too many, you might annoy the owners, ask too few, you might miss crucial information necessary to achieve a correct diagnosis for your patient. 

Communicating, unfortunately as a veterinarian sometimes you need to deliver really, really bad news to people. Delivering this news in a thoughtful and compassionate way is of the utmost importance. Obviously, communicating skills are useful when dealing with people in general. I remember one of my professors once saying, imagine a brilliant and greatly skilled veterinarian who doesn’t have the best social skills. Most owners would eventually stop seeing this veterinarian, despite his/her geniousness. Now imagine a veterinarian who cuts corners, delivers mediocre work and is mostly interested in ways to earn as much money as possible, with the least amount of effort. (I’d like to think this particular kind of veterinarian is rare) This incredibly charismatic veterinarian could sell his/her customers anything. You better believe customers will keep coming back, despite not necessarily getting the best possible treatment for their beloved pets. Now I don’t believe I fit into either of these categories, I imagine myself sitting somewhere in the middle. I do feel like I learned some very valuable communication skills during my training and while I was working. And I believe those skills transfer to testing.

The ability to observe, as a veterinarian a trained eye and attention to details comes in handy. Diagnosing orthopaedic conditions for example includes observing an animal from every angle, in motion but also when standing still or sitting. The slightest abnormality in stance or gait could be caused by an orthopaedic problem.When imaging techniques are not possible for whatever reason, a veterinarian depends solely on his/her capability to observe.

Lastly, my favourite subject in university was pathology, you might think that’s quite a morbid statement. What kind of veterinarian prefers to work with animals who are already deceased? Well, what I personally loved about it was the detective work. I thoroughly enjoyed searching for clues, every clue being a piece of the puzzle. I assume testing resembles detective work in a way and that you end up searching for clues in order to understand the bigger picture.

An Island with Herons nesting, Belgium

An Island with Herons nesting, Belgium

Start with Why

Back to testing. At the very beginning, the amount of information was overwhelming. Where does one start learning? I had the books, memberships on all kinds of online learning platforms, about a million online resources bookmarked and the entire internet to my disposal. I was all set, I’d spend 8 to 10 hours per day studying, weekends included. I couldn’t tear myself away from my desk. It almost became an obsession to me. I had a lot to prove, to my new co-workers, to my parents and most of all, to myself.

After two weeks of studying I was fortunate enough to get a one on one training with Mark Winteringham (DojoBoss at Ministry of Testing, Automation in Testing advocate, co-founder at Software Testing Clinic, …). I’ll admit I was a bit nervous beforehand, scared I would end up asking stupid questions. I was relieved to hear stupid questions are rare in testing. Luckily Mark did a great job making me feel at ease. 

But then came the question that would give me my first aha moment: 

Why do we test

Weirdly enough, despite my best studying efforts and countless hours spent in front of my computer, I wasn’t prepared for that question. How silly is that? I guess studying for 8 years at university, mostly learning how to jam as much information as possible into my brain, didn’t help me during my current quest.

In the end, I was able to give a decent answer. But only thanks to Mark leading me in the right direction and asking me lots of other questions. 

What is testing? What is quality? What happens when we test? What could happen if we don’t test

The remaining hours we talked a lot about the thought process behind testing. How testing should be about understanding the product and supporting the entire team in understanding it. Testing should be a team effort and as a tester you play an important role in that process. I assume everyone has a different understanding of what testing is, but what Mark was talking about made a lot of sense to me. He also talked about testing strategies and the importance of risks. 

We chose a simple todo-list app and brainstormed about the possible risks. After choosing one risk in particular, Mark asked me to think about how I could test it and on which level of the application we should test. He shared his mnemonic “Say Tatta to your Tuttu’s” that would ignite a certain thinking process which I found immensely interesting. 

He also talked about how visualising the application you are testing can help you in deciding where to test for a certain risk. I was relieved to find out a simple pen and paper can suffice to assist you in your thinking process and in seeing the bigger picture.

I was happy to hear Mark’s view on the role of automation in testing because from what I’ve read and heard so far, this subject in particular is controversial to say the least. We touched on some other subjects like what programming language you should learn when you’re starting out in testing, the asynchronous nature of JavaScript, the importance of distinguishing models from heuristics and so on. 

We were now nearing the end of our online training session. He gave me some final advice on how to structure my learning process, what I should be focusing on first en he provided me with a list of interesting resources. 

Every Learning Journey is Different

This training made me realise I had spent a disproportionate amount of my time learning about automation tools. It was easier to measure my progress this way. Completing tutorials gave me a false sense of progress. But I was fooling myself. I’m very thankful to Mark for helping me reach this conclusion. Now I can continue my learning journey in a way that will benefit me in the end. Focusing on understanding the problem and risks involved first and only at the very end start thinking about which tools to use.

Everything I’ve written down here is my interpretation and I am aware I may have misinterpreted or misunderstood certain things. Maybe I’ll read this blogpost again 5 years from now and have a good laugh. If somehow this blog post would be published publicly and people would actually read it, I am more than happy to hear anyone’s thoughts, questions or comments.

Beren on Nosal, Tatra Mountains

Beren on Nosal, Tatra Mountains

If you made it to the end of this blogpost, bravo! Considering I felt slightly reluctant to write it in the first place it turned out to be way more lengthy than I expected. But it did help me to digest all of the information I have been absorbing these last couple of weeks. Therefore I thank the person who asked me to do this in the first place. I want to thank him as well for introducing me to this fascinating world of testing and for continuously believing in me. Despite the current economic situation we find ourselves in, I feel motivated and hopeful that there is an opportunity out there for me. And I’m excited to represent Isle of IT in the best way I can.