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.
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.