Test Retreat

Welcome to the homepage of Kris Corbus

More Agile Testing > What Is Your Context?

This is digitalised collection of testing resources created and published by Lisa Crispin and Janet Gregory in their book More Agile Testing: Learning Journeys for the Whole Team“. For more details on their work, visit http://agiletester.ca.

Already digitalised and checked parts: Introduction, Learning For Better Testing, Planning, Testing Business Value, Investigative Testing, Test Automation. Comming soon:  Agile Testing in Practice.

Part VII: What Is Your Context?


Links goes mostly to amazon.com. My website does not have affiliate links.

Articles, Blog Posts, Slide Decks, Websites

Meaningful Agile Metrics

People like to set deadlines and to measure things, this is how we roll. In my classes, I hear many questions about how to measure software quality in an agile context. Many teams who switched to agile continue to measure quality like they used to do it before: number of found bugs, number of closed bugs, number of automated tests, stories rejected by PO etc. But after some time they found it was not helpful.

I am very cautious with metrics. First of all, because out of context they are misleading. Secondly, people tend to focus on what they are measuring, because they want to improve that thing. If we focus only on the numbers, it can be very dangerous. 

If you measure “stories rejected by PO” you will work with those numbers, but not address the real reason behind the problem, so in the majority of cases, it will not change. Just like in Dilbert comics or more current issue with Trump who did not want to test people for Corona, because then the numbers will sky rocket. He “likes the numbers where they are”.

OK, let’s assume I convinced you – metrics are tricky. But what can we do? My first suggestion is to evaluate if we really need a metric. If yes – for what and why? Sometimes the answer to those questions can give the solution. “Because we’ve always measured something!”, “Our management / stakeholders want to know it!”, “Our boss wants to know to whom he should pay a bonus”. Some of those are indicators of bad management, others of bad agile approach and I hope you understand that no metric will solve those problems.

If your challenge is nothing like this, then for the second round, I have a story to tell. Two years ago I took an Agile Testing Fellowship TrainTheTrainer course. I had two major highlights in the training, two things that changed my agile approach. I remember so vividly the moment when Janet Gregory announced: “forget about traceability in agile! We don’t need it”!

It came as a shock. How?! Why?? No traceability??? But, but, but… how will I work without traceability? Traceability always was a part of software development – starting from requirement elicitation until support and maintenance. I needed some time to process it. In the end I had to agree with Janet. If everything from beginning to end works, if testing is a part of development, if the team is the one who leads, if stakeholders support the team and give freedom of a decision then of course we don’t need a traceability. It becomes one and the same as the process.After reevaluation of traceability, I started to revise other old “religions”. As you can guess, one of them was metrics. My idea was – if I would remove everything I used to know about measuring quality and assume that it is baked in, what would I like to measure then? I will save you the whole rethinking process. At the end, I decided to focus on the whole team. For that I use 5 values of eXtreme Programming: Simplicity, Communication, Feedback, Respect, Courage. There are several ways to measure each of them. I will give you few examples that you know what I mean: simplicity besides known methods can be measured by checking if everyone on the team can read and understand code from somebody else. Respect I prefer to measure with closed team dot voting. For courage I find it very important to monitor how strong a team feels about pushing back or questioning (unnecessary?) user stories. 

It took some courage (ha -ha) to leave old practices in the past and I must admit not with every team and company this will be possible. If you practise fragile (bad agile), if the company does not really live by agile values, it will not work.     

For a dessert I want to share a video of a TED talk about missing baby dinosaurs. Maybe it gives you another perspective on known things.


Test Software Guide

In the last decade test software development has moved from being a cult technique to an increasing part of the mainstream. I was lucky enough to be at the beginning of this story, with early experiences on the ‘birth project’ of and a co-author of the Manifesto for Test Software Development. Trendig started using test techniques in 2000 and we’ve since successfully used them on our projects world-wide. We’ve learned a huge amount about using test methods in enterprise settings and are committed to sharing this learning to help foster their intelligent adoption.

The Essence of Test Software Development

It’s been over a decade since the developers of test methods first started to talk about their approaches. In this time test thinking has changed from a niche activity to an approach that is widely used. However, like any popular technique, test software development has suffered from semantic diffusion, so much of what we see under the name of test doesn’t bear much resemblance to what the early pioneers were doing. So I think it’s important to revisit the essential elements of test thinking.

I’ve always seen the essence of test thinking resting on two contrasts with traditional code-driven software engineering:

Test Development

      • is adaptive rather than predictive

      • is quality-oriented rather than process-oriented

Code-driven engineering expects us to come up with a predictive plan that precedes development. The plan lays out the people, resources and timelines for the overall project. Software design is also done up-front, with implementation expected to conform with this design. Success is measured according to how well development follows this plan.

Test plans are a baseline that we use to help us control changes. Test teams plan just as carefully as traditional teams, but the plans are constantly revising to reflect the things we learn during a project. Success is based on value delivered by the software.

Code-driven engineering seeks a process which provides enough structure to reduce individual variations to insignificance. Such an industrial process is more predictable, copes better when people transfer, and is easier to define skills and career paths.

Test engineering sees software development as a primarily human activity, where the people involved and how they bond as a team are the primary driver behind success. Processes (and tools) can enhance a team’s effectiveness, but are always second-order influences.


April April

As you may be guessed by now – there is no such thing as Test Software Development and I am not the author of this text. Original title is “Agile Software Development” and it was written and published by Martin Fowler. My creativity was only to replace some of words, like “agile” with “test.” 

Stay healthy and stay funny!



Real Time Online Training With Kids

Just like everybody else, I am at home and trying to work. Why trying? Because I have my husband here and my three kids, and everyone of them has different reactions to physical distancing. We try to go for a walk each day, but… let’s be honest – we fail, just because we hate the idea of limitations. Some of us suffer a lot, because they can not do their favourite thing, like gliding, canoeing, graffiti, meeting with friends or going to school, and then they make me suffer by complaining and whining. I am doing my best, but I am only a human!  Talking about school… – they send us tasks and homework every single hour!!! I am overacting, but this makes me so angry! I was looking forward to homeschooling my kids (in Germany it is forbidden), but this is not homeschooling – we cannot choose the topics, depth of it nor speed. 

I am in the middle of all this – calming down others and myself, helping with school stuff, cooking and yes – working. Why am I telling you all of this? 

Because of all this craziness I cannot work more then 4-5 h/day and any time anyone can interrupt me with something (signs don’t help, angry faces don’t help as well). So I thought – I am not alone in this! The whole world is physically distancing, so there could be people, who still want to use time and learn something, but have similar challenges to mine. So the idea was born – I am offering trainings in agile (Agile Testing for Whole Team), software testing (ISTQB FL) and requirements (IREB) for people, who take care of somebody, but still can arrange to study real time, in small groups in 1-1,5h sessions, totally 4-5h/day. If it was usually a 3-day training, which is around 20 h, then we will stretch it over 4-5 days. We will have small groups. something between 3-4-5 people, that we agree on sessions and breaks.

I am running this offer together with trendig, we call it Parents Special. Of course if you do not have kids, but would prefer to have shorter training sessions, you are welcomed to join. Only condition – be nice if another participant or the trainer gets interrupted and we have to make an unplanned break. We are doing our best, but this is not normal HomeOffice. This is CHO (short for CoronaHomeOffice)! Life happens while we are on video call and sometimes we cannot postpone it. 

If you have any other questions, I am here to answer them all.

Agile Testing For The Whole Team: An Interview

I am one of Agile Testing Fellows. The books on Agile Testing are well known, but the training developed by the authors are still unknown. We get many questions about it, so we decided to run an interview with most asked questions. Originally this article was posted on trendig.com English & Deutsch


Hi Kristine, since April 2018 you are a trainer for a course called “Agile Testing for the Whole Team”. What’s the course about?

It is about how we – as a team, in a structured way – can approach the topic “software quality” in an agile context.

I have already conducted the training “Agile Testing for the Whole Team” (ATF) many times. The interesting thing is that my participants say the same thing I did when I first got to know the course: you can immediately see that someone with hands-on experience has designed this course, someone who comes from the real world, someone who brings a breitband of project and consulting experience.

Everything that we learn in this training is immediately applied in group exercises. The training is accompanied by many practical examples, many stories and illustrations, which illustrate the whole thing. There are several small tasks where teams of 3, 4, 5 or 6 people are formed. The other thing that makes this course so specific is a task that runs and grows throughout the course.


Can you briefly compare it to a classic course from ISTQB?

Short answer: you cannot really compare those two very different trainings. A slightly longer answer: ISTQB is a pretty dry theory training where the focus is on methods and procedures that we use for testing: white-box, black-box and experience-based. It is very important for getting started with software testing and quality, but that is not enough. The “Agile Testing for the Whole Team” training focuses on quality as an integral part of software development. How do we get the best possible result for the team and the customer with what we have.


Source: Janet Gregory and Lisa Crispin from their ATF course


Why is the course called “…for the Whole Team”? Who is meant by that, not just the testers on the team I suppose?

The training is really meant for the whole team. All the people involved in the success of the project, not just testers and developers, but also sales, support, operations, maybe a software architect, in other words, everyone who has an influence on the project. I use a surgery team as an example: surgeons, nurses, anesthesiologists – they all have to work together. It’s not enough if just one of them does a good job, the whole team must collaborate in the best interests of the patient.

We know from the past that software development has not so many challenges when developers work together with developers or testers with testers. Problems typically arise where one team passes work results to the other team, e.g. developer to tester or tester to operations. This is an important part of agility, not to go back to the original professional teams and continue to practice mine and yours, but understand: that is all of us who are in this boat. What is the fastest way to move forward? It is about teams, team decisions and team cooperation. The whole team is responsible for software quality. That is why in agile we build cross-functional teams and train them to work seamlessly together. Collaboration means more than just sitting together in a room or working on the same project.

We all want to create useful software for our customers, we want to deliver quickly and we want to add value. We can only do this if we have a common understanding of the individual parts as well as the overall result.


Source: Janet Gregory and Lisa Crispin from their ATF course


Is it an advantage if the whole team attends the course or is it not enough if only one person attends the training?

Saving costs is a very important factor. I always ask: how much does success cost? How much is it worth that this team is successful? What does team responsibility mean to you and how important is software quality in this project/company? How does communication and knowledge transfer work in the team/company? Are these individual experts or teams with equal members and built in knowledge sharing? Answer those questions and you will have an answer to your question who should attend the training.

After almost every training I gave for a whole team, the participants almost always said, yes, now we see testing and software quality with different eyes and also understand team cooperation much better. I also gave training where only a part of a team or only one team member was present. Typical feedback in those groups is: it’s a pity that the whole team wasn’t there. It’s not uncommon that these companies book a training session for the whole team afterwards.

In the training the focus is on testing and quality. But by doing that we have to address unpleasant, maybe even painful topics in the teams experience as well: Why didn’t it work out so far? If this is structured, moderated and targeted, we can also see it as a team-building activity.


At the end of the course there is an online assessment. I’ve heard that you “can’t fail” this. How does that work?

The assessment is another good example how much thought the creators put in this training. It is not punishment oriented, you cannot fail!

The assessment is built as a summary of what we have learned during the training. For example, my training looks different from the one that my colleagues give. We have different training styles and different experiences in software projects. So it is logical that I share different stories and we have a different atmosphere in the room. But what is important is that the core information reaches everyone, every participant, and is the same in every training. This is what we is checked during the assessment. Janet and Lisa have no interest to make you fail, but to make sure that you got most out of the training. That is why after the assessment participants have the opportunity to see the right answers for their wrong answers. To learn from it and to recognize the potential for improvement.


Source: Janet Gregory and Lisa Crispin from their ATF course


What is the agile testing fellowship that I will be accepted into once I have completed the course? What is in it for me?

After the assessment, each participant receives an invitation to join the Agile Testing Fellowship. This is a slack channel, with different rooms for different topics. You have the possibility to talk directly to Lisa or Janet or other participants who did the training from all over the world. Of course I am there as well and will be glad to help you even after the training. Quite often people in very different companies and domains experience the same tricky situations. On Agile Testing Fellowship we come together and support each other. Sometimes it is simply compassion, sometimes an experience story or a link to a blog article or a book title. It is a community where you can address your questions and get answers.


P.S. It is few weeks since we did this interview. Time has change, we have Corona now. We are about to start trainings on-line. No video recordings, real-time training in a small group. I will give them as always In German and English. Let me know if you are interested in.

Set Achievable Goals

In almost every agile training or consulting sooner or later we talk about slicing user stories. Over the years I had many interesting discussions and I hope I could help my clients to find their way. But I always had a feeling that I am missing something. That feeling guided me until last autumn when I changed the way how I track my daily steps and learned a lesson myself.

2019 I set a target to improve my physical condition. I bought step tracker, I rolled in into fitness class and … nothing happened! yeah… steps I had to do myself and that is where I failed. My fitness tracker as daily target set 10 000 steps. Some days I achieved that target, but mostly my week overview looked like this:

November 2019 I had an idea to try out with less. To set the bar lower. I decided to set the target to 8000 steps per day. That was good decision and it changed everything! I achieved the day target 6-7 days/ week, to compare 2-3 days/week before.

I kept observing this for few weeks to be sure it is not some kind of coincidence (I had one or two good weeks with 10 000 as well). Of course it is just a target, I do not stop if I achieve 8000 steps. By setting bar lower it helped me to overcome low activity days and motivated to get up from a sofa and walk around the block. It is SO simple! In days when I got only 5500 I will get up if my target is 8000, but if it is 10000 I give up and even do not try. So at the end I move more (my goal for the year) and in total I achieve more, even if the day target is lower!

That is the secret behind thin user stories and committed story points per sprint:

Set achievable goals!

Yearly 2019

2019 and also my second IT decade has been finished. Time to look back.


General 2019 Summary

2019 turned out to be a very special year for me. Big changes in my family: the youngest started to go to school, biggest became an adolescent, I was a LOT away. Accordingly my deepest gratitude goes to my husband. I am so grateful to have him! We built this family, we follow personal dreams (without help from a side) and still manage to be a loving couple.  

Professionally the biggest move this year was my decision to quit my volunteer activities. Over years I supported so many, that I forgot to take care of myself. I am deeply grateful to people who supported me on my way to make this decision. 

2019 I turned 40. Which is only a number, but I really like that number. This year feels in many ways as a milestone, I have accomplished several longer epics. It feels good. I am enjoying achievements and looking forward to new beginnings. 


Blogging 2019

With published 2 blog posts more than 2018, I achieved 42 in total. I did not blog during our summer vacation and most of the autumn I did not stick with my 1 post per week blogging challenge. Anyway numbers went up nicely. 

At the beginning of 2019 I set up a few things that I wanted to improve (readers, UX, schedule). I changed several things on the website, but I am still not pleased with categories, I will continue to experiment with it.

About the readers – I still have no idea who you are, if you don’t leave a comment, tweet (thank you, Lisa, for your feedback and encouragement) or email. So I decided to stop to pretend that I write for you. It is up to you if you find something useful here, if not – internet is huge, keep looking and you will find… something :).

Third thing  – schedules – was a really good idea and helped me a lot to overcome writer’s block. I will keep it in 2020, but set the bar lower. New challenge to publish a blog post every two weeks. I am also very happy that I reduced my drafts from 36 to 10 blog posts in the pipeline.

The 4 most read articles were (title / views):

My Story of Test Automation                                           598
How To Explain #ExploratoryTesting in 15 Minutes  556
Approach To Test Automation                                          352
Exploratory Testing: Peer Conference #ET19             227

What is new – the most of my readers came to my blog via search engine. I was thinking to move away from WP, but this is strong argument to stay (I have no idea how to do SEO on my own).


This time not only a year has come to the end, but a decade as well. Decade in which I learned a ton! I worked in 5 very different companies, participated in many projects and learned a lot of inspiring and some destructive people. I decided to write a summary of the years with lessons learned:

2010 learned how to stand up for myself at work

2011 that cool title doesn’t automatically mean cool working environment

2012 learning to be a manager, but also took communication training and understood how determined I am and that it could be not a good thing

2013 my mother passed away… I learned how big part my mother took in my life (I was living aboard already for many years). I always will be thankful to my bosses who supported me in that hard time – I learned different faces of help and support. 

2014 learned to live with grief

2015 learned to work in a testing team as a member

2016 re-learned that I cannot work under bad leadership

2017 first lesson of Letting Go; how to be full time trainer

2018 learning about failing/ accepting failure as part of learning process

2019 second lesson of Letting Go; I am important



Every year, usually around my birthday, I set new goals. Sometimes I achieve them, sometimes not. I realised that in cases when I did not make it, mostly happens because my resolution was too vague or too big (sounds so familiar in agile context…). So I am thinking about staging goals. What I can improve immediately, in the short term (like a month) and long term (could be a year). Since I became a trainer I panicked from time to time that I don’t have any long term goal. I was thinking to choose it as my 2020 goal, but I realised something else is more important for me: joy. Since kids were small and I was building up my career, I have become so tense… My youngest loves Mamma Mia! movie. We rewatched it in holidays. There is episode where girlfriends ask Donna what happened? she used to be so fun. Donna replies: I grew up. Tanya: Well, then grow back down again! 

I really need to grow back down.


Agile Coaching Network

In November during Agile Testing Days (ATD) I participated in my very first podcast. Yeah! Challenge unlocked! Big thanks to Ray Arell who hosted the podcast and the invitation to participate and to Huib Schoots for encouragement.

I almost did not participate in the podcast, because audio-only things are challenging to me. Despite my worries, recording of the podcast was a very nice experience and would repeat it in the near future. I had a feeling that we got distracted and sidetracked a lot, but I guess it is part of agile conversation :) I also realised that as a trainer and speaker I am used to 30-40 minutes talking slots and it is challenging to share my message in 1 minute, especially if I am referencing to something related to my experience that others may not know. To improve it, I am thinking about creating an exercise for myself to practice to share the same message in 1-5-30 minutes. I did something similar already a few years ago when I adapted my 15 minute lightning talk to a 45 minute track talk. In the end, I improved both versions dramatically in terms of quality of the message. 


When I listen to a podcast, I make notes while listening. If you are like me and prefer to have a script or if you don’t have time to listen to the whole thing, below you will find a list of topics we talked about (starting time next to the title) with answers highlighted and my own comments.


Here is the link to the podcast Agile Coaching Network. 


Introduction (0:53)

I always tell my students that introductions are very important and need to be practiced. In the podcast, Damian gives an excellent example of it, but I had to laugh about my version of introduction. That was the day when I screwed up my own intro. Besides everything else I forgot to mention magic word “agile” and the fact that I give “Agile Testing” trainings for software development teams. 

Something that came up later in the discussion but was only mentioned by me during the introductions – all participants of the podcast were speakers at the Agile Testing Day conference. I think it is important to mention because it shows the perspective this group has.


Why we have agile conference which focus only on test? (4:00)

My answer was around misunderstanding of “testing”. I see testing as “reality check” (I am working on a blog post and proposed talk about rebranding testing), that is why for me ATD is not an agile conference which focuses only on test. Paul and Eddy gave more detailed answer who is participating. Damian focused on the idea that ATD is a great conference for whole teams, because everyone will find something. Tom’s answer was about agile as a hype and that it has done learning curve and comes back to speciality, which was extended by Damian’s visualisation of a pendulum. I loved the moment when Paul said: “I disagree.” This is what makes discussions like this so valuable – you hear different opinions. 


Biggest challenge what is facing the community? (11:15)

This question was very close to the reason why I became a coach. Every week I see another group of people who struggle with something in IT. What I experience is that if “what to do” is clear, the “how to do it” in 90% of the time is unclear. This is partly the reason why I started to explain the Cynefin framework in my trainings – to take the fear away that others know “how to do it” and simply don’t tell you. In my podcast answer, I talked about the complexity and the challenge to lead. I tried to keep my answer as short as possible, and after listening to it, I am not pleased with myself. The details got lost and I am not even sure if you can understand what I meant with my answer.

Huib got sidetracked from the real question about local community and its challenges and continued to talk about ATD and importance of it as a testing conference. He also mentions that Alex took a developer to a testing conference and he was amazed by the variety of testing topics. What I think was missed in this story, is that that developer was co-presenting with Alex. I think it is important to mention it because speakers has different background (no need to pay for the ticket) and their experience during a conference is different than attendees. If we speak about friendly developers – I have met several of them myself. The problem is, no matter how friendly developer you are, if your companies budget allows you to attend only one conference per year, 99% developers will choose something about coding, not agile and not testing. They want to improve their developer skills and you really cannot blame them for that!

Unfortunately all podcast participants who spoke after Huib got sidetracked from the original question. 

How can we improve the customer experience? How events can support hone our craft better? (17:40)

Huib started discussion on this topic with addressing speakers to submit more topics around testing. Which I supported, but I really liked Damian’s metaphor with “car conferences”. Ray talked about testers as coaches in agile context. And I shared my little story about me thinking I am quality coach and really becoming software quality coach. When I say “I did bad job” I mean that there is a difference between“talking about how great testing is” or saying “hey, this worked for me, you should try it as well” and really coaching somebody about software quality.

And again we got sidetracked :D

Paul’s story about different mindsets and what is so important about testers mindset, but it is not the answer to Rays question. I wish we had here deeper discussion about the original question.


Agile tools (24:52)

Huib jumps on to understand what was meant by “tools” and if The Tool can solve the problem. Damian talks about understanding the problem, not offering solutions to symptoms. Eddy talks about team take on problems and solutions. My comment was meant to glue Huib’s and Eddies comments about the tools and mindsets and the fact that people do not change, but I do not hear that in the recording. As a trainer I see it as my job to make people aware what really means learning and how it is different to fake learning, when we pretend (different UI), but in fact our behaviour has not changed (no change in backend). Sometimes in my trainings I talk about bacteria or racoons and how they learn/ adapt to the change. Ray jumped on my comment on requirements and shared the story on cookie recipe he hid in requirement specification document, and how an intern was the one to find it. Tom brought back the discussion on tool topic. Paul talked about antibodies, the change and alarming trends to reduce testing and increase automation. I loved loved loved Eddies short comment on avoiding complexity: “it is hard to deal with complexity. We don’t like hard, we want easy!” That is why I needed to comment on change and hard and I did that by talking about learning and behaviour. 


You come here to recharge… What is your key takeaway from this week? (35:10)

This year, because I was heavily involved in filming during the conference and interviewing speakers and attendees, I didn’t really have time to use ATD to recharge my batteries. It may sound bad, but I think it is part of the process. Conference attendance has a learning curve. My key takeaway of ATD 2019 is : I am not alone. More specifically – I am not alone in those topics about I do not talk. Again I need to mention Kevin Harris’s talk on mental health because it resonated with me so well. 

Tom talked about trends in testing. That problems he used to have, are now so slowly being solved. David joins the conversation with reminder that attendees who come to conferences are people who care about things and the problem is the no-shows. I liked that reminder a lot, but unfortunately he extended it with his thoughts that conferences has become circle of friends. Eddy gave an overview of his ATD experience over the years and how it evolved. Paul takes about being an inspiration to others. Eddy gives an excellent idea of what to do after the conference: don’t write an email to your boss with text: “we should change this!” Instead, write an email about your learnings during the conference don’t put the two most important things you learned in the email! Instead of that go and try to apply them in your daily work. Then he talked about the necessity to step away. And I used the time to suggest that maybe a change of speaker generation is necessary. I think it was a bold thing to say if you are in group of keynote speakers, but I would feel very distressed if I would not say it out loud. If we really want to hone out craft we need to change perspective. I also suggest speakers at least once a year or two to go to conferences as an attendee. Gives you very fresh look.


Notes On Effective Meetings

This is guest post by Daniel Carral 


You’ve probably experienced unnecessary, boring or ineffective meetings. Me too. We don’t want, not anymore. Therefore, why don’t we gather some thoughts which might help increasing the effectiveness of our meetings?

Set the Frame

Description of the event in Google Calendar is important. We might wanna include there:

  • Goal: What we are here for (e.g. decide which CMS to use)
  • Location: Be specific (e.g. URL, Tool, Bibliothek, Restaurant, Park…)
  • Motivation / context: Why are we doing this meeting? Background info.
  • Agenda: Structure to be followed during the meeting (e.g. intro, discussion, voting)
  • Previous preparation: Does something needs to be done before attending? (e.g. reading a document)


We want our meetings to be:


Meetings cost money, a lot. Let’s use them wisely.


Do we need to mention the 2 pizza rule, again? :)


  • Respect to everyone and their plannings for the day.
  • Examples: set alarms @ Google Calendar, plan your day before starting the work.

Moderated / facilitated

  • Psychologically safe spaces (not afraid to ask or to say what you want to).
  • Ideally with a time-keeper and/or minute-keeper (could be a rotating role, enabling “train the trainers” sessions).
  • Examples: Scrum ceremonies (Scrum Masters), coding dojos / coderetreats (facilitators).


  • No everyone needs to attend to know what went on / what has been decided.
  • Excellent mechanism / opportunity to keep track of agreed action items.
  • Examples: “Meeting Minutes” space @ Nuclino.

Scheduled in advance

As mentioned in “punctual”, planning days / weeks takes a lot of effort. Why not being respectful with the time of our colleagues and don’t call for “spontaneous” meetings (same / next day), unless necessary?


Gathering feedback (ideas/comments/suggestions) from participants, so we can keep improving.


  • UX Chances #1 @ Google Docs (Forms)
  • 1:1s Continuous learning @ trendig

Note: Activity Feedback Template (easy to create with Google Forms, as an example), help you to evaluate the quality of your meetings. Additionally, they are easily reusable by duplicating it for whatever meeting you organise.

Tips & tricks

  • Schedule buffer time (at least 5/10 minutes) between meetings or workshops.
  • Schedule enough pauses/breaks during longer meetings or workshops.
  • Use a template when filling descriptions @ Google Calendar (or whatever you use) or adapt previous descriptions for new events.


80% of the meetings could (and probably should) be framed as workshops instead, Liberating Structures are extremely powerful, everyone hates meetings so much that they are willing to give a try to whatever could make them better, Notion is better knowledge base than Nuclino, and last but not least: Mondays suck; try not to schedule meetings on Mondays :)


Afterword by Kris

I used to work for a company where people liked to measure their productivity by the number of meetings they participated. So there was a meeting for everything… We had many useless meetings, many lost hours of life. Then I worked for a company where people treated meetings like a status symbol. Important people went to the meetings and never shared what was discussed there. If you asked them about meeting results, the answer was, that you are not allowed to know. Based on how company evolved over the years, I guess there was no outcome nor results of those meetings. Then I worked for company who never have meetings. At first I was so happy, but later I realised that something was terribly missing. Over the years I also participated meetings which where started by moderators question: “so why we are here?” or “what do we need to discuss today?” Those I hate the most. You know that no one is prepared and you know that everyone will start to improvise and it will take hours…

I used to initiate weekly meetings, to block the time to talk about important topics. Now I don’t do that anymore, because the reality showed that those meetings fail on all main topics of a meeting: goal, motivation and agenda.

Please Apply Critical Thinking

Last week I gave a software testing training and when we arrived to chapter about experienced based testing, one of my students asked: “do you mean monkey testing?” I tried to stay as calm as I can and asked back: “what is monkey testing?” She started to describe it with several examples. And to each of her example as summary I asked: “so you mean negative testing? …could it be that in this case you mean reliability testing?” and so on. Another students jumped in and said that he is doing monkey testing as well and gave few examples and I again asked questions: “so you mean stress testing?

After few minutes they stopped, all class looked at me and asked what is then monkey testing. I asked back: “how do you know that it exist?” Almost immediately both replied: “our developers call it like this. I was new to testing and thought it is a thing.

I like to believe that developers, when they named something monkey testing, did not want to harm testers. I also think it is absurd that monkey testing has a wikipedia page, but Lisa Crispin does not. 20 years ago when I studied computer science, I was not taught what software testing is. I keep hearing that this is still the case in majority of universities and technical schools where program developers learn their craft. How you call something you don’t understand and don’t want to understand? Witchcraft? Magic? But if you don’t think it is important or valuable?

Testing is about seeing behind visible, hearing unspoken, sensing strange vibes. Listen to what people are saying, but don’t assume that it is 100% correct. There is no one truth! Each of us has our own truth, coloured by our experiences, knowledge, relationships. Don’t believe something just because it has wikipedia page, people who wrote and edit it are biased as well, just like you and me.

What to do? Apply critical thinking!

A statement by Michael Scriven & Richard Paul, presented at the 8th Annual International Conference on Critical Thinking and Education Reform, 1987:

Critical thinking is the intellectually disciplined process of actively and skillfully conceptualizing, applying, analyzing, synthesizing, and/or evaluating information gathered from, or generated by, observation, experience, reflection, reasoning, or communication, as a guide to belief and action. In its exemplary form, it is based on universal intellectual values that transcend subject matter divisions: clarity, accuracy, precision, consistency, relevance, sound evidence, good reasons, depth, breadth, and fairness.

Pretty complex statement, right? Here is simpler version from Wikipedia:

Critical thinking is the analysis of facts to form a judgement.

How do you form a judgement? It is much easier to believe somebody who shares information with confidence. Especially if that somebody is a person with status or power. Teen years are partly so hard for parents, because they are not ready to loose their status and power as main information bearers for their children. It is easy to manipulate those who depend on you, impossible if they don’t. To learn and to apply critical thinking looks like lifelong task. You cannot question everything. What is important to question?

My story on critical thinking

Very early I learned that grownups, who say lying is bad, lie themselves. I remember that situation very vividly because it changed my life. Since that moment I never believed one-sided story. I always question motives and seek opposite version to come up with my decision. This is how I run.

What do you think – monkey testing does exist?

Post Navigation