Test Retreat

Welcome to the homepage of Kris Corbus

Archive for the tag “training”

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

None

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.

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.

Today I Learned

Last September I joined trending and became one of the ISTQB trainers. I have a whole story “why?” and I plan to share it one day, but today I want to talk a bit about learning.

How I see learning from the trainer side is pretty ugly – mostly students do not want to learn. It is trendy to talk about learning and training should be safe place where to learn, but in many cases ISTQB is something where they have been sent by a boss or something, what they think they have to do, to get a next shiny job title. I try hard to make trainings entertaining (e.g. I carry different testing games with me) and informative (learning materials, stories from the past), but sometimes it is simply not working. Sometimes I am happy that at the end of the day everyone simply memorised what negative test is and why we should do it. Most challenging are the ones who refuse to understand some definitions or concepts, for example, difference between validation and verification. Most frustrating if this person has 20 years of experience in IT. In those moments I ask myself, is this really for me? But then I remember my “why?” and everything is OK again. Part of that “why?” are students, who are engaged and eager to learn everything I can share with them. They do some research upfront and have clear vision what they need. It is highly rewarding to work with that kind of students. Discendo discimus – while teaching we learn.

In trainings I invite people to embrace failures, to share experiences, to learn from each other, to use synergy. To help them to do that, I point to my own mistakes. Something like the picture on the top of this post. Few month ago I put whiteboard into our home kitchen. We use it as drawing board, as shopping list, as design board for next game we will program and sometimes I write citations. I guess, now till end of my days, I will spell “intelligence” correctly. I must to admit, not always I was so cool about my mistakes. Few years ago I would feel ashamed and embarrassed, would try to hide it, put a lot of energy to deny it. Today I share it with the world. I know who I am and spelling mistake will not make me less me. I better put my energy to think why did I spell it wrong? Am I writing too less on an analog information carriers? Do I assume that software will catch all my spelling mistakes?

Since this month we have new colleague Dani. One thing what he did, he created channel in our company slack #todayilearned to share our learnings. It has became simple but effective training for me to identify what did I learn new today. Sometimes it is simple stuff, like, how to spell “intelligence” or that I am afraid to sit in the car which moves faster than 210kmh on busy autobahn, or that people who smell lavender fragrance make less typos and are more productive (I sent this fact immediately to my colleague with whom I used to share an office and passion to lavender). Or sometimes it is realisation that not everyone reads and spends on learning about a software as much as I do. I left digital transition domain because I was sick of explaining software development basics again and again. Now I explain them on weekly bases :D . I like to think that I can assume correctly about previous software development experiences of my respondent and explain missing parts accordingly his/her level of understanding. And almost every second time I fail, because of aiming too high. People try to write an essay without knowing the alphabet! Yes, even in 2018 you have to explain, with patience and empathy, what is a smoke test, what is a negative test and regression test to a developer with 10 years of experience in software development. And this is OK. We all make mistakes and wrong decisions, important is to use it as learning possibilities.

 

 

Post Navigation