Jessica Ingrassellino and I will perform a workshop at the NYC Testers Meetup on Monday May 1st during the Test Leadership Congress. Join the meetup to participate.
The session will be based on the workshop we did at CounterPlay, an international play festival which took place in March in Aarhus, Denmark. Titled “Playful Software Exploration” the topic was value driven improvisation skills in testing. Together with the participants we tested, performed music and formed a philosophical, protreptic circle
The somewhat disturbing background of the workshop is that in a performance oriented and individualized tech industry, we are expected to drive ourselves to be the best in a complex or even chaotic reality. Remaining true to our professional and personal values while staying sane and ready to act and perform every day can be very challenging.
Our CounterPlay workshop was a success. Collaboratively we gained sense of and got to the core of important values in testing. We were even interviewed for the popular show “The Harddisk” on Danish national radio.
This time we would like to playfully explore the significance of Kairos in testing.
Kairos is Greek and means the supreme moment in which the future is transformed to the past with a particularly fruitful outcome. Kairos is important in rhetorics because while there are rules of good communication, there are moments in which speaking and acting is particularly fruitful: There is a time and space for the good talk. And even the best performance will fail if kairos is not considered.
This is an aspect of all improvisation and play, and good testing is in many ways always an improvised, playful act.
We know it when we perform exploratory testing.
But even when testing is turned into a controlled and scripted process, it makes sense to perceive testing in the microscope as a playful exploration and experimentation with potential and actual outcomes – even outcomes beyond the directly observable testing results: E.g. learning points for developers and management.
At the core is that testing makes a difference for people around us, even those who are not directly involved in testing and developing.
So let’s think beyond the processes, and functional and technical perspectives on testing, and explore software testing as a playful and human event with potential to create order in due time.
No prior knowledge or talents are required to join the workshop. But bring curiosity about values in testing, and be ready to play and improvise, introspect and think and reflect abstractly.
Best,
Jess and Anders
Det er videnskaben, der bærer vores samfund i dag, og med den følger søgen efter forståelse. Med forståelse kan vi skabe nyt og blive rigere og sundere.
Forståelse indebærer, at vi indtager et standpunkt, altså står ét bestemt sted. Dermed stiller vi os i modsætning til andre standpunkter: Forstår vi noget, kan vi ikke indtage flere modstridende standpunkter om det, vi forstår.
Så med forståelse følger holdning.
Holdning baseret på forståelse virker vigtigere end noget andet, når vi skal tage store beslutninger. Hvordan mon statsministeren eller præsidenten tænker, når han skal sende sit land i krig: Tvivler han og ryster på hånden? Eller har han læst og forstået situationen eksakt og præcist og udmønter derefter forståelsen i handlekraft?
Visheden, der følger med forståelsen, giver sikkerhed og signalerer styrke. Dens modstykke, tvivlen, kan være tegn på uduelighed og svaghed.
Men måske rummer tvivlen alligevel noget godt?
Mange krige har i eftertidens dom vist sig meningsløse og måske mest baseret på rygter og løgne. Vi ved det egentlig godt: Tit søger folk jo ukritisk efter vished og giver måske sig selv og andre indtryk af sikkerhed og styrke men snyder i sidste ende kun sig selv og andre.
Måske findes der en værdifuld, reflekterende tvivl, en dyd, som vi som ledere og mennesker bør kende og opdyrke for at bevare og udvikle kritisk sans og en sans for de sandheder, der rummer nuancer, der ikke kan måles videnskabeligt og sikkert?
Det kræver mod at tvivle, men tvivlen må i alle tilfælde være nødvendig, for at vi personligt og organisatorisk kan mestre de irrationelle psykologiske for-forståelser og mavereaktioner, som alle mennesker trækkes med.
Ja måske er tvivlen ligefrem en forudsætning for at kunne handle empatisk og begavet i det daglige?
I denne ottende samtalesalon vil vi derfor lede efter værdier i og omkring tvivlen, ja dyrke selve kunsten at tvivle.
Tilmelding er obligatorisk – og det er afmelding i øvrigt også, hvis du bliver forhindret. Hvis vi har tomme stole, vil vi nemlig gerne kunne give dem til andre interesserede.
Vi glæder os til at se dig!
Dato: 15. maj 2017
Tidspunkt: 16.00 – 18.30
Sted: Gjesing Coaching, Prinsesse Charlottesgade 31, kld, 2200 København N
Tilmelding til: karengjesing@privat.dk (obligatorisk af hensyn til forplejning)
Kærlige hilsner
Karen og Anders
We hereby invite to the 7th protreptic salon in Copenhagen, this time with Jess Ingrassellino from New York – and for the first time in English.
Join Jess, Karen, and I in a salon with the theme “Play and Passion”:
Growing up, we become serious and think that play is childish behavior to be abandoned. Later we discover that the truth about play is more nuanced.
Play represents a very human aspect of life and it seems to have power to connect us to passions and personal values even in difficult situations.
The subject we would like to explore is how we stay true to ourselves, thrive, and face challenges of our professional roles in playful ways.
We wish to uncover wisdom about how we can playfully be productive, nurture our relations, and perhaps even serve higher causes.
Be quick to apply for this unique and intimate salon with music and philosophical dialogue.
Date: April 3rd 2017
Time: 16.00 – 18.30
Where: Gjesing Coaching, Prinsesse Charlottesgade 31, kld, 2200 København N
Apply to: karengjesing@privat.dk
Should you have registered, but be unable to participate, please let us know as the number of chairs we can fit in is limited and we’d love to share with someone else if you can’t make it.
Jessica Ingrassellino is a musician, teacher, philosopher, researcher, programmer, business owner, and software tester from New York. Prior to her life as a software tester, she was a full-time music teacher in New York City public schools. In 2015, she completed a dissertation about assessment and school music; in 2016, she wrote “Python Projects for Kids“. Currently, she test software at Salesforce.org. She also runs TeachCode.org, working within the New York metropolitan area to bring improvisatory, imaginative coding education to underserved communities.
Billederne af den tilsyneladende generøse præsident, der ved indsættelsen selvsikkert og iscenesat giver magten tilbage til folket var et tema på de sociale medier. Han sammenlignedes med en bestemt tyran fra en Batman-film, der brugte samme ord og udtryk. Det er urkomisk og skræmmende på én gang. Tiden vil vise, hvad der sker i USA nu.
Når jeg tænker på frihed og ansvar, så kommer relationen til mine medmennesker altid og forplumrer billedet af den våde drøm om at kun at være mig selv nærmest. Drømmen bliver et mareridt. For, hvem ønsker at være i fuld kontrol over sit liv og dermed alt omkring omgivelserne? Er man så ikke helt alene om det hele, og dermed helt, helt ensom?
Jeg må derfor straks vende tilbage til tankerne om, at min frihed kun kan leve i fællesskab med mine medmennesker, og deraf opstår vist nødvendigheden af noget ”givende”, ikke kun i en større sags tjeneste, eller blot for kollektivets skyld.
Jeg kan simpelthen ikke føle mig fri uden at give.
Temaet for næste samtalesalon er generøsitet, for vi er nysgerrige på, hvad vi mon kan finde ud af ved samtalen om den. Den er så smuk og fin, men det kunne jo for eksempel også tænkes, at der ind imellem skulle sættes grænser for den? Vi ved det ikke.
Tilmelding er obligatorisk- og det er afmelding i øvrigt også, hvis du bliver forhindret. Hvis vi har tomme stole vil vi nemlig gerne kunne give dem til andre interesserede.
Vi glæder os til at se dig!
Dato: 6. marts 2017
Tidspunkt: 16.00 – 18.30
Sted: Gjesing Coaching, Prinsesse Charlottesgade 31, kld, 2200 København N
Tilmelding til: karengjesing@privat.dk (obligatorisk af hensyn til forplejning)
Kærlige hilsner
Karen og Anders
Summary: Last year in September, I spoke at Anna Royzman’s New Testing Conference “Reinventing Testers Week” in New York about testing in Black Swan domains. The title of the talk refers to Nassim Taleb’s book “Black Swan” and concerned testing in contexts where improbable risks can have disproportionate effects. This blog contains an invitation to a peer conference in New York on the subject Sunday April 30th.
Sometimes things happen which appear to be beyond “the possible”.
This awareness haunts us in testing: We aim to get those important bugs to materialize. We want to qualify real and serious risks. Yet, our stakeholders have to accept that no matter how much testing is done, we cannot cover everything.
Logically, testing has to be focused on what is important to the business, and what might go wrong in reality. To me, that is at the core of risk based testing.
But saying that is one thing; doing it in reality is quite another. Certain risks seem almost impossible to qualify through testing. How should our stakeholders interpret the absence of clear testing results, for example, when we are trying our best to dig out quality information about quality? Could there be a serious problem lurking? The thought may seem paranoid, but experience shows it is not.
Years ago, I read Nassim Taleb’s “The Black Swan – The Impact of the Highly Improbable”. The book blew my mind and set me on a path to find out what we can do in testing about what he writes about.
The book is about “the random events that underlie our lives, from bestsellers to world disasters. Their impact is huge; they’re nearly impossible to predict; yet after they happen we always try to rationalize them.” (from the backcover of the 2010 paperback edition)
As an engineer and a human, I think testers and test managers should not give up and leave to product owners, project managers or developers to interpret testing results take care of potential Black Swans. As a tester, I wish to embrace the possibility of Black Swans and do quality testing with the aim to qualify them.
I think, however, that we need new models in testing. The problem is that most of our techniques and heuristics tend to support us best on the functional testing level.
Accident Focused Testing?
The first part in solving a problem is accepting it. It sounds basic, but acceptance implies understanding what we are dealing with. Reading Talebs book asserted to me that we have to accept the fact that really bad things can happen in the world. Knowing what I do about information technology, I appreciate that his philosophy can be applied on technology. I also believe that the functional testing will not help us muc.
Mentally examining what I do as a tester, I understood that the idea of Black Swans is fundamental to the very nature of what we do and the systems we work with.
That much about acceptance.
The problem is that in some contexts – banking, healthcare, industrial plant management, safety systems, public sector, transportation etc – accidents and Black Swans could be of a nature where they cause irrecoverable losses, set lives at stake or otherwise be fundamentally unacceptable.
Let me give an example:
I recently came across a story of an interesting IT breakdown in a hospital in Sweden. It concerned something most people do on a regular basis: Apply the newest updates to our pc’s.
As updates were rolled out in the hospital, performance of pc’s started degrading. During the rollout the problems became worse, and before the rollout could be stopped all computers in the hospital became useless.
Now that the computers stopped working, undoing the rollout became extremely difficult and had to be carried out manually, one pc at a time.
In the end it took IT-operations several days to get everything back to normal. Meanwhile the hospital had to be run “on paper”.
The hospital used an uncommon Windows network configuration, which is not recommended by Microsoft which in combination with the Microsoft update triggered a problem in the network. What is interesting here is not the root cause, however: The outcome of a seemingly trivial update in a complex system turned out very bad.
It is easy to imagine how the stress experienced by doctors and nurses due to this situation could have affected patients. Someone could have been hurt.
We can shrug and blame Microsoft or the hospital IT operations. However, as skilled testers, I think we need to be able to provide some kind of answer as to how we can constructively contribute to hospital safety by qualifying even Black Swan-types of risks.
Systemic risks
Before moving on, let me dive into the subject of risk. Risk is something we all talk about, but do we really know what it means? I’m not sure. Risk is a common thing to talk about, but the concept of risk is in no way simple.
There seems to be at least three “risk domains” in software projects:
- Some risks concern plans and schedules. Will the project be done on time and budget? That’s what we usually call “project risks”.
- Other risks concern the product or system under development: Will it do what it is conceived to do? Will it do it correctly? These are called “product risks”.
- Then there is a third class, a class of risks of a different nature: Systemic risks. They exist by combinations of systems, users, data, and environments.
Black Swans lurk in all three: Even simple products or components can sometimes fail in strange ways with huge impact. Just think of the defective Galaxy Note 7 battery problem, which was only a manufacturing problem with the battery, but one which has caused lots of harm to Samsung.
Black Swans are sometimes annoyingly simple.
But those kinds of Black Swans can be prevented by stricter quality control and similar tradtional measures. Project- and product risks are usually relatively easy to deal with using appropriate care in the context.
Systemic risks are different. They seem much more troublesome – and in some ways more interestng.
From simple to complex
Back in the early days of computing, I think systemic risks used to be rather uninteresting. Systems were simply… simple. Developing a new product, we would sometimes work to make sure usability was good, or the machine which the computer system was designed to control would work as a whole.
But that was it. Interfaces and interactions to other systems and contexts could be counted on one hand and there were usually very few connections to other computer interfaces etc.
If you have been interested in risk in software, you may have read about the Therac-25 accident. If not, let me summarize: A difficult-to-find multi-tasking bug in the control software of a radiation therapy machine turned out to be the root cause of apparantly random radiation burns of cancer patients placed in the machine for treatment. Some of these burns were fatal.
Obviously a Black Swan: A difficult-to-find bug in a lacking design.
The system was simple, however as there was only four components in the system: The user, the user interface software, the machine control software, and the machine itself. Of course there was also the patient, victims of the accidents, but they were only victims, receivers of the problem. (Some victims attempted to provide feedback though.)
The issue turned out to be a simple multitasking problem, where experienced operators who were fast on the keyboard used to control the machine could cause the software to enter illegal states. I.e. a software engineering problem.
Today, however, complexity is increasing. To me at least, it seems our industry has crossed a boundary: The number of components that work together in complex ways to realize important business functionality has grown significantly. While counting can never tell the truth, it is worrying that modern systems can be comprised of 10’s, even 100’s of components that are assumed to work seamlessly together on sunny days. Often no-one knows what will happen when the sun goes away and rain comes, so to speak.
Systemic risk in IT systems is no longer something that can be excluded from risk analysis and managed technologically.
So why are we not spending more time testing based on systemic risk analyses?
Explore the whole picture
Some readers might think of the Cynefin framework, and yes, I think it certainly appears promising as Cynefin provides a thought framework for understanding complex and complicated systems.
I went by a different path, however, when I explored the situation: I looked at safety engineering and mechanical safety analysis. I can recommend two books in particular:
- Normal Accidents by sociologist Charles Perrow
- Human Error by psychologist James Reason
(In a later blog post, I’ll come back to what a found in these two books, but you can get a peek of it in the presentation recording at the bottom of this blog. I’ll certainly also be coming back to Cynefin as it seems promising.)
But there might be a bigger problem to address too as it seems there is a management problem worsening the situation: Testers very often do not receive sufficient freedom to test the “big picture”.
When have you last heard of a tester tasked to test a product in complete integration with real users for a long time? I’d like to hear about examples of it, as very often, when I talk to people, I hear about product owners, project managers or C-level managers deciding and controlling tightly what should be tested.
And risk reporting to the rest of the organization is filtered through these levels.
Focus is too often only on going live on time, on schedule, no matter what. Too seldomly on qualifying complex or systemic risks.
I think testers should be tasked to explore the dynamics of the product in contexts resembling the real world.
Speaking about testing in a Black Swan Domain
I spoke about this first time at the first Let’s Test conference in 2012 in Stockholm (slides – PDF) and second time in September 2016 at the New Testing Conference during “Reinventing Testers Week” in New York. Scroll down to see a recording of the latter presentation.
The feedback I received at those two events has confirmed to me that this is a subject that needs exploration. Our craft can be advanced to go below the functional, performance, or usability perspectives. New models in testing, heuristics and even types of testing strategies can be developed, I think.
Going alone can be difficult, and I’m therefore extremely grateful to have received moral backing from both Michael Bolton and Fiona Charles. Additionally, Anna Royzman has agreed to co-host a peer workshop on the subject in New York with me in connection with her May conference.
I find New York an interesting place for a few reasons:
- It is where I talked about the subject last time.
- Nassim Taleb lives in New York.
- It is a very big city, so big, that it’s even difficult to comprehend for someone like me who comes from a little county with less than half the population of it. New York is seems a complex system beyond imagination.
- It is the world’s financial centre, and some of the systems running that are extremely complex. I try not to think about what types of systemic risk they manage on a daily basis.
If you are interested, feel you have something to contribute with, have time, etc, it would be great to see you at the first WOTBLACK: Workshop on Testing in Black Swan Domains on Sunday April 30th in New York.
The objective?
Advance the testing craft by co-developing and sharing models, heuristics, and strategies.
Write me an e-mail if you’re interested in participating, or ping me on twitter if you feel you have something to share now or wish to start a discussion about the subject.
On Tuesday Janaury 24th, we will be hosting a meetup on Risk Based Testing Strategy under Ministry of Testing Copenhagen Meetup group in Herlev.
Make sure you register as a member of the Ministry of Testing Copenhagen meetup group to stay tuned when new meetups are announced.
Also, don’t miss the Ministry of Testing home page to learn about other meetups, TestBash, news, and lots of useful testing resources.
Christmas is almost over and while I am still having holiday with the family, I’m beginning to think a bit about testing again.
I am passionate about software testing.
There is a lot of talk about passion, but do we know what passion is?
The word shares roots with the greek ‘pathos’, which is one of the three key components of persuasion in rhetoric. The other two are ethos and logos.
Good communication should be fact based (logos) and serve a common greater good (ethos), but passion adds something important to communication.
The passionate lecturer
I remember two math lecturers from university. One taught analytical algebra, the other graph theory and combinatorics.
Both were personalities of the type you would notice if you saw them in the street, but if someone would then whisper to you: “He is an associate professor in mathemathics”, you would exclaim “ah!” and understand exactly what you were seeing 🙂
Their style of lecturing was very different, however.
Every lecture in graph-theory and combinatorics was unique. It seemed the lecturer literally reinvented what he was lecturing while he was doing it. He was not particularly organised in his teaching, sometimes he would even forget the subject, and divert off a wrong ‘graph’ (sic!). But he had passion for the subjects, and that showed. The lectures were often very engaging and fascinating.
The other lecturer prepared his lectures to perfection: He always started on the exact minute putting his chalk to the board in the top left corner of the first of the six large black boards in the auditorium, and by the end of the 90th minute, he would finish writing formula in the last available spot of the lower right corner of the last board. He repeated that time after time. A fascinating performance. But there was a problem, as he had obviously lost passion for the subject he was teaching. I felt bored to death during his lectures, and I am not sure I ever passed that exam.
Some testers are passionate about what they do, others try to be perfect. I always prefer passion over perfection.
Suffering by Passion
Passion is one of those tacit capabilities we know by heart, but will probably never be able to code, teach to a neural network, or explain to someone who has never experienced it.
The word has an interesting record in the Douglas Harper online etymology dictionary. Apparantly, passion used to be a kind of suffering:
Passion: late 12c., “sufferings of Christ on the Cross,” from Old French passion “Christ’s passion, physical suffering” (10c.), from Late Latin passionem (nominative passio) “suffering, enduring,” from past participle stem of Latin pati “to suffer, endure,” possibly from PIE root *pe(i)- “to hurt” (see fiend).
The article even goes on linking passion to sufferings of martyrs.
Let me confess now: While I am very passionate about good testing, I am not going to become a testing martyr.
Words change meaning over time and passion is certainly a word that has become more of a daily language term than it probably was back in the late 12th century.
Today, linking passion to sufferings, even physical sufferings, may seem out context.
However, it reminds us that passion does involve trading in some things that I like too: Staying relaxed, calm and cool, for example.
I am neither of those things when I am feeling passionate.
Passion seems to be a kind of double-edged sword.
Passion-Fatigue
I am always more tired after working passionately on a testing problem than when I’m doing more trivial things in my job: E.g. diligently replying to e-mails, writing factual test reports, checking out plans and schedules.
Could there be something called passion-fatigue? I think so, and when passion is a driver in daily work life, relaxation and recharging is important to stay healthy, sane, and well in the longer run..
The need for Hygge
Now that Christmas has just passed, but I am still enjoying days of holiday with the family, it seems right to mention ‘hygge’ (pronounced “hyk-ge”).
Hygge is Danish for relaxing with others, a good book or in other nice ways.
Hygge is difficult to define. In that way it’s similar to passion, except opposite: Relaxing, calming and mentally soothing.
A day with hygge could be so relaxing and good that it deserve finishing off with a good tequila, scotch, or another good drink of your preference 🙂
What’s interesting here is that hygge seems to be a good cure for passion-fatigue. Hygge creates space for passion.
And this is exactly what ‘Julehygge’ is about: Getting away from daily life, relaxing with family and friends, and recharging.
Is “hygge” becoming a global fashion trend? The New York Times had an article on the fashion of hygge a few days ago: Move Over, Marie Kondo: Make Room for the Hygge Hordes
Playful Software Testing
I met with and enjoyed a very good conversation with Jessica Ingrassellino in New York back in September. Jessica presented a workshop on playful testing during the Reinventing Testers Week (I presented at the conference about “Testing in a Black Swan Domain” which, unfortunately, I have not had time to write about yet).
We talked mostly about philosophy.
Jessica is quite a multi-talent: Plays the violin virtously, is an educated music teacher, has switched career to testing, taught herself Python, authored a book on Python programming for kids, and is teaching Python classes at a local community college, as well as music classes.
She has a vision of making testing playful and fun.
Structured work govern testing in professional settings, work which has nothing to do with play. So why is play important?
Jessica puts it this way:
When the power of play is unleashed in software testing, interesting things happen: The quality of the testing performance becomes noticeably better, and the outcomes of it too. This results in better software systems, higher product quality.
I have a product engineering background and play is important for me too. Engineers have methods, calculations, and procedures, but great engineers know that good solutions to problems are not found by orderly, rational processes. Good solutions depend on creativity and play.
Friday December 9th, I met with Mathias Poulsen in Copenhagen. Mathias is the founder of CounterPlay, a yearly conference and festival on serious play in Aarhus, the second largest city in Denmark.
About three years ago, Mathias got the idea for the conference.
In the first year, 2014, it was an immediate success with more than 20 talks and workshops in 3 tracks on “Playful Culture, Playful Learning, and Playful Business”, and more than 150 participants. This year (2016), the conference had 50 scheduled sessions: keynotes, talks, workshops, mini-concerts and open sessions.
Mathias explains (about 0:30 into the video):
Counterplay is basically an attempt to explore play and being playful across all kinds of domains and areas in society. We are trying to build a community of playful people around the world to figure out, what does it mean to be playful and why do we think it is beneficial?
Processional IT has so far not been represented at the conference, Mathias told me. I found that a bit surprising, as at the moment almost everything in IT seems to be buzzing with concepts promising joy and fun – play.
Sometimes, however, there is an undertone to all the joy. Agile and DevOps have become popular concepts even in large corporations, and to me, both strive to combine productivity with playfulness. That is good.
But is the switch to Agile always done in order to pass power to developers and testers, allowing them to playfully perform, build and test better solutions? No, not always.
Play facilitate change and breaking of unhelpful patterns, but sometimes play is mostly a cover for micromanagement. There is a word for this: In a recent blog post, Mathias talks about playwashing:
Playwashing describes the situation where a company or organization spends more time and money claiming to be “playful” through advertising and marketing than actually implementing strategies and business practices that cultivate a playful culture in said organization.
A question is therefore how we genuinely support play? Are there methods or processes that better accommodate playfulness at work?
I believe there is. Processes need to leave space for exploring context, knowledge sharing and actual interaction with customers, stakeholders and team members.
But processes or methods will not do the job alone. In fact, putting play under the examination of psychology or cognitive sciences will never be able to grasp what play really is.
Play is more like music and poetry, where ideas based on assumptions about order, rational choice, and intention cannot explain anything.
Philosophy and especially the dialectical exploration of what it means being a playful human is much better at embracing what play means to us and how to support it.
Jessica and I are working on a workshop about playful and artful testing. It will combine ideas of playful testing with philosophy.
We are certain that breaking out of patterns will help testers, and breaking out of our patterns, participating in a conference which is fully devoted to play will teach us a lot.
Med frihed følger ansvar. Det er elementært, men kan måske alligevel være svært at acceptere. For hvordan kan jeg være fri, hvis jeg er tynget af ansvarets åg? Kan jeg overhovedet bære den store ansvarlighed?
Tænk, at kunne give sig hen, give den gas, leve livet som det er – og som man selv er! Dét må da være ægte frihed. Det er i alle tilfælde en forestilling man kun kan begære.
Men så bobler alligevel passionen og engagementet. Alt det jeg af min egen fri vilje brænder for, og når jeg tænker efter, dét jeg er klar til at kæmpe for. For mig selv, men måske især for noget større end mig.
Måske er ansvar og den endnu sværere ansvarlighed alligevel noget smukt som er værd at stræbe efter, ja ligefrem begære?
Lad os finde ud af det. Den foregående, fjerde protreptiske samtalesalon havde frihed som omdrejningspunkt for samtalen. Nu er turen kommet til ansvar.
Vi samles i en “visdomscirkel”, vender os mod os selv og hinanden, og i faciliteret samtale konfronterer vi grundværdierne. Deltagelse er gratis, men hvis du kan, så medbring gerne 50 kr til kassen vi bruger på forplejning.
Der kræves ingen forudsætninger at deltage udover en interesse for samtalen, der opstår.
Dato: 9. januar 2016
Tidspunkt: 16.00 – 18.30
Sted: Gjesing Coaching, Prinsesse Charlottesgade 31, kld, 2200 København N
Tilmelding til: karengjesing@privat.dk (obligatorisk af hensyn til forplejning)
Venlige hilsner
Karen Gjesing
Gjesing Coaching
karengjesing@privat.dk / 35 37 82 04
Anders Dinsen
ASYM APS
ad@asym.dk / 28 18 49 25
I did a bonus talk/workshop on Tuesday on Test Masters Academy‘s conference during the Reinventing Testers week. Title was: “Reinventing Testers, Reinventing Myself, Staying Sane.” The talk was an introduction of explorative, valuable, and supportive conversations.
Imagine you are at the scrum meeting. You’ve reinvented yourself as a tester and feel fit in the new team. But today, a senior manager has joined the meeting: The release is in testing and “go live” is today.
The problem is that you are facing some very odd issues. How are you going to manage talking about them?
Testers are often under pressure. We have to stay cool – and sane.
“Whenever you find yourself on the side of the majority, it is time to pause and reflect” – Mark Twain
(It was Jess Ingrassellino who tweeted this quote a few days ago.)
An experienced tester on my team recently mentioned that a sudden change in schedule had caused him to fear he would loose sense of himself.
I am very passionate about providing testers with ways to remain true to themselves, even under pressure.
In the talk, I introduced the type of philosophical conversations I practice as often as possible with team members and friends: Protreptic dialogues.
(I have written and talked about it before.)
We formed a circle and I spread Dialoogle cards with pictures on the floor for us to pick from: Pick a card that relates to testing.
Picking a picture of something and associating it to testing requires you to use your intuition better and think creatively about yourself and what you do.
The thoughts enable protreptic conversations in which I as the “guide” and facilitator listens and ask questions. The conversation is personal, but never intimidating as it is always only about assisting you in reflecting positively about your thoughts, ideas and values.
Sane comes from latin sanus, which means healthy, sober, sensible.
Being sensible, sensing, sensemaking and staying sane is linked. The kind of sanity I seek, is that where we seek to understand who we are, and stay true to our values.
I shared this slide in PDF with five helpful principles that you can follow to perform explorative, valuable and supportive conversations with colleagues and friends.