I Know Everything

– Hey, listen to me! I am the trainer/big name/white middle-aged man – I know everything!
– emm… no, you don’t. And neither do I.

I have arrived in phase where I know nothing, but I have enough confidence to teach others that little knowledge I have.

Since I was little I was very good middle man. I was reading a lot and used to observe things from different perspectives. Later at university my speciality was to explain something my study mates knew much better than I did, but struggled to understand some aspects of it. How can I do that? Very simple – I listen. Not just words what people say, but words which they do not say as well.

I work as a trainer not because I know everything, but because I like to help people. Training and coaching for me, in first place is about empathy.  I need to be able to connect with trainee and to understand her/his journey, to understand their challenges and problems. Only then I will be able to guide them to their next step. Not to my next step in that situation, but their next step.

My trainer moto is:

docendo discimus,

which means: by teaching, we learn.

I really learn while teaching. Listening to people and empathising with them I learn to know their stories. Based on my trainees questions, I start to explore new topics or dig deeper in domains I knew superficially. In my last training I learned a lot about Ireland – did not expect that, but wow – it was so interesting!

Lisa Crispin is excellent role model for learning attitude. She is three book author, has 20+ years of experience in agile teams, international speaker and, and, and… But I never heard another person then Lisa to say so many times phrases like: “I learned today…”, “that’s interesting!”, “I learned it from …”. Lisa helped me to understand that learning is not something what we do. Open mind to people, situations and new ideas is a mindset.

To know Lisa also showed me that it is easy to ask Lisa for a help. Because you know she will not judge you that you don’t know something. I try to use it in trainings I give. I talk about my mistakes, I say that I do not know everything, but I know material very well and I will do my best to help them to find their answers.

 

 

Words Has Meanings: Learning

This is conversation between two friends

Kris: I have to tell you a secret… I have big problem with “learning” if we talk about ET (exploratory testing).

Lisa: Hmm… It’s always been taught to me as “learning about our product”. But I am not an ET expert by any means.

Kris: For me “learning” means “to change behaviour”

Lisa: oh, interesting! for me it’s just gathering knowledge

Kris: Gathering information doesn’t include using it. You use information by changing your behaviour (huge excursion in my experience as mother and trainer). But only thing what we want to change is the software. So no real learning on human side.

Lisa: We might learn about features we are missing?

Kris: That is functional or contractual acceptance testing. No learning.

Lisa: So if I do exploratory testing on some feature, and then I realize, before customers can use this feature, they need another capability that we haven’t even thought of before – I didn’t learn something? Or if I find something is really hard to use – I didn’t learn something?

Kris: How do you know that they need something else? Hard to use – do you mean usability? Testing usability?

Lisa: How do I know? Because I’m exploring as a particular persona or role or job, I have a scenario of what I want to accomplish with the app, and I run into a roadblock. The persona is blocked, Lisa has learned that we didn’t provide a necessary capability.

We might be splitting hairs on words and semantics, but exploratory testing is called a process of learning, and it has seems correct to me.

Kris: For me it is very important to clarify what we mean by words. I always liked language (in Latvian we have more then 30 words how we call a mother), but as older I get as more aware I am about layers of language, coded messages and communication in general. People, who name things, make mistakes (just like everybody else). I am not looking for fight… It just feels wrong to call it “learning” if we only gather information.

Lisa: OK

Kris: The way how I understand whole team approach is that if we have situation as you described it, the tester in the team should be able to identify and categorise the problem. Is it functionality, usability or performance? then to decide what following tests should the team run to gather missing information.

Am I aiming too high?

Lisa: IME it works best if the tester collaborates with the team to do all that. We don’t want to be the safety net so that everyone relies on us to point out issues. We want to help teammates prevent the issues from happening in the first place by building shared understanding of features, using good tech practices for code correctness, fast feedback loops with automation, exploratory testing before committing changes…

More a consultant role than doing all the testing for the team.

You know, you have some interesting ideas here, it would be nice to discuss this on the AgileTestingFellow slack.

Kris: Maybe… but I don’t feel there yet. And I didn’t mean that tester is a safety net. What I meant is that tester has this knowledge about testing techniques and approaches and she/he guides the team. This is what I understand with tester as testing coach for the team.

Lisa: Sure but we have to be continually helping everyone else ramp up those skills. If we make all decisions ourselves, we take autonomy about testing away from the rest of the team. Guides, yes, that’s the ticket

Kris: Yes, helping others. But tester should be able to recognise it her-/himself first. Only then she/he can guide others.

Lisa: I like what you say there about recognizing it in ourselves.

 

Post Scriptum

I really, really LIKE how James Lyndsay phrased it:
“Systems are weird. Are you looking for trouble? Exploratory testing can help you to find unexpected truth, about what you really got.”

Exploratory testing is technique to find out, gather information. As a team we will decide later what we want to do with information with gathered. Maybe we will ignore it, because risk is too low, maybe we will use it and make decision based on it. And maybe we will learn out of it, adapt our behaviour and leave the issue in the past. If it will not reappear, then we really can tell: “we learned something!”

Trainer Notes

Agile Testing Quadrats

Weeks after Agile Testing Days were pretty intense. Every week another training. Business as usual? No. I do not know why… was something in the air or was it my students, or myself. We tackled agile and dig really deep. To experienced and guide it, made me very vulnerable.

To learn means to leave comfort zone and to realised that what we did so far was not OK. Learning can make you feel big discomfort. That feeling is not a good feeling, so sometimes to get it go, people turn the anger to the messenger. Trainers and coaches need to learn how to deal with it. Another thing next to anger is struggle. I see struggling people, who want to be really agile, not only on paper, but they have no idea how to do it in their environment. Sometimes I do not know which situations are harder – anger or struggle, but definitely since I attended Agile Couch Camp this summer it is easier to deal with situations like those.

Week before Christmas I had a group of people who had especially big emotional debt. No matter which topic we were discussing, it went back to the old stories about orders, ignorance (from managers) and silence (from employees because it does not matter if they say something). This group was special with another thing – there was one of managers sitting with them. She is one of the new managers, who joined the company not so long ago, but still – a manager. First day she was all about denial. Everything, what group said about bad practices, missing communication or management, was not true. On second day she started to listen and at the end of the day she said: “now I see that we have communication problem”. She realised that to talk or to share ideas is not enough with people, who were misused for a very long time. They do not believe you and they listen to something else. On third day the manager was missing for the first part of the day. I used the time and asked the group to reflect on training and how the manager reacted. It was interesting to observe that they collectively realised that maybe there is real change coming. The training they got, the manager, who listens when they complain and reacts when she realise something wrong. I felt very privileged to guide them through this moment. Felt like real transition to new level.

At the very end of the training group asked me for tips how to stick to ideas and how to keep agile spirit vivid. Maybe because of approaching Christmas or because of this something in the air, this time I chose to share story of my own vulnerability, my own struggle and my own insecurity and my tricks how I keep going and where they could look for tools what would help them to create a positive agile habit.

Sometimes giving a training can be exhaustive… but I still like it.

Dare To Question!

More then month ago together with Lisa Crispin we run a workshop “Questioning requirements: improving quality for everyone”. The reason why we came up with this workshop, was to teach and to empower people to question requirements. As a tester I know how important is to question statements, ideas, requirements, designs etc. As trainer I know that with a lot of confidence you can run for presidency.

This is the story how we did that (without particular details in case you want to take the workshop in some other event ;) ).

Setting up

We had some challenges: we did not know how many people will come to our workshop and our time block was less than 2 hours. We took those restrictions and created a workshop, which we could easily scale. At the SwanseaCon we had around 32 participants, which we divided into 6 teams. Each team had a particular context to role play in a simulation. We emphasised that we wanted people to experiment and have fun. We tried to build safe space to learn and to try new things. We presented several tools that participants were invited to use to explore stories and to structure conversations with stakeholders (you can download them here). They were also free to use any other tool or framework they prefer.

simulation

We explained that we as “stakeholders” wanted to create an app and gave each group a list of desired features. In our background story we used words like “deep analysis” and “market research”. User stories were written in ambiguous way with aim to provoke the need to ask questions. The task was to create a release plan, creating stories for the features. Especially noting what feature they would like to start with.

how it went

All groups were extremely motivated, except one. There were lively discussions within the table groups and it was interesting to observe team dynamics. Especially interesting was to see that the group which struggled the most – none of them left the table or whole workshop. They were struggling together till the end. Another interesting thing – we as stakeholders got not so many questions as we expected to get. Just like in companies, our fictional teams were so busy working that they forgot that stakeholders are there in the room… We tried to interact with the teams, but nobody wanted our help and it looked more like we are disturbing them.

After simulation was accomplished, each team presented their release plan. or the process they come up with. After that we started debrief and our attendees exceeded our expectations when they started to reflect on their working experience in their fictional team and usage of tools we presented. It was great atmosphere in the room and we all learned from each other.

I think we managed to create a good workshop and would like to do it again at future conferences or other events.

Some things what workshop attendees learned.

Happy creators

How To Create A Workshop: Follow-up

screen-shot-2017-01-16-at-01-29-02

End of the last year I wrote about starting to create my first testing workshop. This is follow-up with details how I did it and results after the workshop.

Ash’s MindMap

As I know Ash and loved his workshop in TestBash Brighton, I took his mindmap as a proved recipe. It helped me to tune it and to have an overview. Especially helpful was everything under “Principles”. Small adjustments from my side – I added a node “Emails/Communication” for the “Checklists” section.

Creating Mental Model

With map in the hands, first thing what I did, was to create a mental model of the workshop. I spent more than week to build it. Very classy with pen and paper – my two favorite thinking tools. Some of the ideas what went through my head during that time: why company asked me to do a workshop? What kind of problems do they want to solve? What are possible solutions? What would be my solution? What background has people who will attend the workshop? What kind of skills they have? What kind of skills they need to have? What is the main, core thing to be able to solve their problem? How can I teach it? Can I teach it? How to build it up in small stages/ containers?

Some answers I knew, for the rest I decided for two possible versions – positive and negative. As a next step – I simulated dialogs with me and workshop students, where the students where unwilling to learn, disagreeing with my ideas or frame of work, not cooperating and simply not understanding what I say because of different background and level of information about software testing. May be it sounds silly, but it helps me to prepare and to deal with potential situations. With every simulation I check my model – does it work? Should I improve something?

Test The Workshop

When the mental model is done and tuned, than I started to test it. First I tested it with two of my colleagues. One of them has test management background, never did test automation before and shortly started to learn it. She liked some of my ideas, but her main comment about the subject in general was: it is so difficult and it is not possible to learn in one day; people will block them out because of amount of information.

That gave me a lot of thoughts. I went through my mental model again, cut all advanced level stuff, noted that I need slides for basics and changed the structure.

After I was done, I looked for people outside my company with whom to test the idea. Got very valuable feedback and some tips.

Only then I started to create the slides. When slides were done, I gave a short presentation of it to my colleague, who said that it is not possible to learn TA in one day. My heart singed, when she said, that now I build a good workshop.

Outline

So what was my plan? I started with fusion of “Test Automation with Lego” by Richard and “Mob Testing” by Maaret. The goal was to write script how to build a tower and they had to write it in the team, where one was a driver and everyone should had a posibility to be a driver. After that we “run” the scripts. Next step – to analyse the scripts and think about modularity. First learning block we would end with a little theory about testing and test automation, just to assure that we are on the same page. Before the lunch I wanted to start practical scripting in the teams, which we would continue in the afternoon. I planned to end the day with second theory part with lessons learned and suggestions and to wrap it all with another mob-test-automation-lego to acknowledge what we learned.

Results

How it went? Like in the life – unpredictable :) Lego as an ice-breaker and illustration of test automation worked very well. Light problem was with mob testing – drivers did not want to give away their positions. All my effort went unheard. I stopped pushing and paid attention that everyone is envolved even if as contributer.

The idea to analyze the scripts and try to modulyse them did not work, because scripts did not work. I switched to back up and we analsed one of their test cases.

My light theory part raised a lot of questions and took much more time as I planned. That is why before the lunch we managed only to share the files and set up for practical part.

As we started practical part, team required to change the planned setting and instead of team work they wanted to connect one laptop to the beamer and have a shared understanding how to start scripting. I agreed and than problems started… first two students could not connect their laptops to the beamer, with the third it worked, but again we lost the time. After basics were covered I asked to join their groups. Mob part we skipped, because it just did not work for them. The technical problems kept following. One students keyboard did not work. I suggested to get an external keyboard, but it was ignored. A second student in that team had too old browser version and did not have admin rights to update it. I suggested several times to change the teams but it was ignored as well. On another team driver had a mac book and he missed some files as we diagnosed afterward. I have to be honest – I was not prepared for any of those situations. Who comes to the workshop about test automation with broken keyboard?! But I think the thing which disturbed me the most was – that was OK for them!

At one point it stopped to be an organized workshop in teams. Everyone, except one, tried to script the test case on their laptops, shoutting around, sharing excitment and frustration. I was running from one to another and helping to fix problems. For a moment I saw one blinking word in my mind. Disaster. I had to skip second theory part and lego wrap up, all students wanted to make their scripts to work. We used every minute till the end of the workshop. And you know what? They did!

That moment I switched off that blinking word in my mind. The technical problems were OK for my students, they hit the goals of the workshop and all of them were smiling when they let the workshop. And yes, before we cleaned up, it looked like a workshop. Mission accomplished!

Summary

I am glad that I had a chance to create (in less than a month) and run a workshop. I am happy how it turned out. I realized how spoiled I am with technology at work (new keyboard or mouse is never a question). The students said it was interesting and usefull.

What I will do differently next time? I will put more effort to make sure that there is less as possible technical issues. I heard it before, but did not really understand until experienced myself. Another thing – Andrei has a list of skills what he expects from his students and if they do not cover part of it, he refuses to give a workshop. It sounded a little bit overacted as I talked to him about it, but now I think it would be good to draw a line, to set up basic knowledge level for participants.