Agile Testing with Lisa Crispin.+Add.Feed Info1000FOLLOWERS
Lisa Crispin is a tester who enjoys sharing her experiences and learning from others.In 2012, she was voted by her peers as the Most Influential Agile Testing Professional Person, and given this award at Agile Testing Days.This blog of her provides practical agile testing guidance and contains in depth information on agile testing.
My team has 40+ members, distributed into seven or so “pods” and across several locations. It’s a challenge to communicate information among the multiple pods. In addition, we often face obstacles that cross over multiple pods. We usually have a “cross-pod retrospective” once a month. It’s typically in the “Happy/Puzzler/Sad” format. We collect items in those three categories for a few minutes, then figure out some way to prioritize the items, discuss them and come up with action items. When you have 40 people trying to do that together, with several of them participating remotely, there are a lot of people and pods that don’t get their most pressing issues addressed. It’s also tricky to have such infrequent retrospectives – people often don’t remember what was bugging them over the course of several weeks. Every so often, we try something a bit different.
Disclaimer: I don’t say you should try this exact retro format. I’m just sharing this in case it will help your team think of ideas for retrospecting and improving how you work.
Our team’s been trying lots of new experiments the past few months. Our big boss chatted with me about ideas for different retro formats to promote knowledge sharing as well as address problems that require help from the large team. One of his concerns was to make sure issues relevant to all the different groups within the big team, such as product, design, testing, support and marketing, are discussed and addressed, not only the development-related problems. We came up with a plan and I recruited an awesome teammate to help me plan and facilitate the retro.
To save time, we decided to collect topics in advance. A few days before the retro, we sent out a survey asking people “What’s holding you back or causing you pain that you / your pod/team can’t make better on your own?” We grouped related topics, and sent out another survey with a list of topics, asking people to vote for the ones they’d most like to address in the retro. We were pleased to end up with a range of topics, several of which were relevant to everyone on the team.
The actual meeting
We were able to get an hour and 15 minutes for the retro, and we required careful planning to squeeze a lot of activity into that time. We started the meeting with remote team members included in a Zoom video conference. We provided a couple of nice cheese platters and started the meeting with appreciations. Then we did a “psychological safety check”, asking people to put a sticky note on a chart where the X axis was “how safe do I feel to be honest” and “how willing am I to show up and contribute”. Remote people directed the location of their sticky note to my co-facilitator via Slack. Luckily most answers were “up and to the right”, and we brainstormed a few ideas to help people feel more safe. I assured the group that it was fine to choose not to participate, and there’d be an easy opportunity to drift away when we formed working groups. I had positive feedback on this – some people just aren’t in the zone that day and would prefer not to participate and that is totally ok.
We asked the team to self-organize into groups of 3-5 people, making sure their groups were cross-functional and diverse, including at least one remote person or one person in some other role. We recruited “buddies” for each remote person so that they could communicate with their group via their buddy’s laptop on a Slack video chat. Each group chose a topic, which we had put on wall charts around the room. We asked each group to design an experiment to address the problem area they chose, in this type of format:
We hypothesize by <implementing this>
We will <improve on this problem>
Which will <benefits>
As measured by <measurements>
I had expected people to first gravitate to the topic that interested them and groups would form naturally that way, but that’s not what happened. We had the wall charts too close together for people to gather by them, and the room was too small for the crowd. Plus, the remote people obviously couldn’t do that. So, this process ended up messy for a few groups. But we did end up with cross-functional groups and the remote people were distributed amongst the various small groups.
Small group discussions
Given our office’s lack of conference rooms, the small groups had to be creative about where they went to work. They did a super job of including the remote members on a video call on a laptop. We only had 20 minutes for this part. Some groups spent most of their time absorbed in discussion and had to rush to get an experiment ready to share. One team started off by thinking of a measurement, then going backwards through the parts of the hypothesis, which I thought worked really well.
I asked the groups to start off by spending 1 minute discovering one thing they all had in common, to get the discussion going. Some found this annoying, they preferred to just jump into the discussion. The laptop buddy for each remote worked really well, we got a lot of positive feedback on that.
With our tight timeframe, each group had only 90 seconds to explain their problem area and present their hypothesis, but that worked fine. To choose the experiments to try, we had the same small groups each decide how to use 3 votes and vote as a group. We ended up with two experiments that had the most votes. Then I asked for volunteers to sponsor each experiment, get volunteers to form a team to conduct the experiment. We had no shortage of eager volunteers.
One experiment team immediately implemented their idea to improve cross-team communication about upcoming releases. They incorporated it into the morning all-hands standup agenda. So far this seems to be working pretty well. Solutions don’t have to be difficult or complicated!
Ways to improve listening skills
The other experiment was around how team members can improve their listening skills. That experiment team took a section of whiteboard and wrote “I wish my teammates listened to me by…”, providing a supply of sticky notes and markers. They made this the “Thing of the Week”, which is mentioned each day in standup to help us be aware of something we want to improve. One of the experiment team members in the office makes the sticky notes on behalf of remote team members who want to add to the board. The suggestions have given me some good ideas on how I can be a better listener.
I don’t know if this experiment has more steps to it. Unfortunately, the experiment as written didn’t have any measurements. Measurements really are essential to measure progress of an experiment! It’s fine if an experiment doesn’t achieve the goal – we still learn, which is the whole point.
Some learnings about the retro format
I sent out a survey to get feedback on the retrospective itself. Overall, most people thought it was a worthwhile experiment, and almost 60% would do the same format again. Everyone liked the small group discussions, so I hope we will do more of those in the future, no matter what format we use for retros. Our team has been doing all kinds of crazy experiments lately, so having an experimental retro format was a bit too much for some. Some people said they’d rather select the topics to discuss in the meeting itself and have more transparency to that process.
Still, we got a lot of positive feedback. I hope we can build on this to have more effective retros in the future that lead to people feeling like we’re working a bit better and enjoying ourselves a bit more. Please share any interesting formats you have used for retrospectives, especially for large teams!
We use our story telling and critical thinking skills constantly as we test and develop software. How often do we practice those skills on something other than features we are going to release to production? Musicians practice their craft. Even coders can practice their craft with katas and code retreats. How can we practice telling stories and thinking critically? Another concern for software delivery teams are unconscious cognitive biases, which get in the way of critical thinking. How do we fight something that we’re not even conscious of? Enter VTS, Visual Thinking Strategies.
Work out your story telling and critical thinking muscles
When I participated in Alex West’s Visual Thinking Strategies workshop at Agile 2017, I experienced a huge aha moment. Here, finally, is a way we can practice telling stories together, practice thinking critically, and possibly expose and work around our unconscious biases. To quote Alex:
Visual Thinking Strategies , or VTS, is a cross-disciplinary technique applicable to anyone working in a collaborative setting where observation is key. VTS develops critical thinking skills by viewing and discussing works of art in a group.
Experiencing the creativity and insights resulting from a group of mostly strangers carefully observing artworks was a huge aha moment. What a powerful way to collaborate, benefit from many diverse perspectives, and succeed in spite of our biases!
What’s going on in the picture at left? What do you see that makes you say that? What else do you see? Simple questions like these from a VTS workshop facilitator get fascinating responses. What story can we tell based on the picture? Each person in the room sees different details, and as they share what they see, it inspires everyone else to see the picture from a brand new perspective.
A team VTS workshop – remotely!
Some of my teammates, including developers, testers, a product manager, a designer and a customer support representative, and I were fortunate to participate in a remote VTS workshop facilitated by Alex. The process worked as well in a Zoom meeting as it did in a room with co-located people at Agile 2017. Alex made us all feel at ease. Everyone contributed.
Alex showed us a painting and asked us what we saw. As each person shared an observation, Alex asked them to explain what prompted their observation or opinion. When I saw the fern cats, all I saw at first was how amazingly they were made of ferns. Then a teammate noted that the water was falling in only a small area in the picture. Where did it come from? Was it watering the cat for nourishment? Was the cat annoying the tree by scratching it and making it pour out water in self-defense? I didn’t notice the stormy-looking sky until another teammate pointed it out. Are the cats happy, agitated, what is their mood? Why are some of the trees and vegetation brown?
Generating ideas and stories
No knowledge of art is needed in a VTS workshop. There are no correct answers, and no attempt to get consensus. The facilitator is open, accepting, and helps the group link observations together. That’s probably why this doesn’t devolve into group think.
It’s such a collaborative experience – each person’s observations cause others in the group to see the painting in a new light. Diversity for the win! One picture we looked at appeared to be a kitchen – at least, there was a fridge. I assumed the object next to the fridge was a cabinet, until a teammate observed that it must be a window. Hmm, yes, that did look like a window! And truly, nothing else in the room was very kitchen-y. Were we really looking at a kitchen? I was able to let go of my assumptions much more easily when I could hear what others see.
At the very least, VTS is a fun team building exercise. We look at an interesting, puzzling picture and start making up a story about it. But it is so much more. It lets your team talk about something completely new and unfamiliar in a safe environment. You can’t fail because there are no right answers. You really can practice so many skills together: critical thinking, story telling, brainstorming, observing.
How does it apply to software delivery, especially testing?
VTS is used by medical schools to help doctors become better diagnosticians. Apparently the CIA has a big art collection for training its spies. It seems to me there is huge potential for software delivery teams who practice it. 30 minutes of VTS could be a great warmup to a product brainstorming session or a retro. I hypothesize that if I participate in more VTS sessions with my team, I will be better at finding issues with our product, better at asking questions, a better team member, less susceptible to confirmational bias. I’m going to test out this hypothesis!
If you do a workshop with an experienced facilitator like Alex, you can also learn how to facilitate a session yourself. I am keen to facilitate more sessions with my own teammates and practice critical thinking together.
Check out Alex’s recent post about VTS for more information. I highly recommend contacting Alex and setting up a workshop for your team.
Tester’s Island Discs from https://dojo.ministryoftesting.com/
As soon as I heard the introductory episode to Neil Studd’s Tester’s Island Discs podcast, I sent in my five song selections. I didn’t expect to be picked, but it was really fun to think of the five tunes I’d take to the Tester’s Island!
I’ve listened to every episode, and have learned a lot of new insights and ideas about testing, and discovered a lot of music that is new to me! There’s a playlist of songs from the show on Spotify that you can link to on the website.
I was thrilled to be selected to be on Episode 7! I had so much fun talking to Neil the day after Thanksgiving here in the States. I’m afraid I talked a lot, so it’s a few minutes longer than the average episode. He picked a really great clip for each of my songs, and I hope some of you discover something new! I enjoyed our wide-ranging conversation, from my “tester origin story” to diversity and inclusion at conferences. Oh, and a bit about how donkeys cope with winter.
You can submit your song list on the website – I highly recommend it!
Eeek, 2017 is over soon and I have one more post about the Agile Testing Days 2017 conference! Yes, it has been quite a few weeks ago now, but like most of you, the combination of work, side projects and holiday merriment have meant a lack of blogging time. I’m just going to squeak this in!
Most moving keynotes ever
After our last 7 am walk and Lean Coffee of ATD 2017, we had a really different kind of keynote to kick off the last conference day. Roya Mahboob was the first women CEO of a tech company in Afghanistan. She shared her story of overcoming obstacles such as no schooling at all for girls in the Taliban years to being able to employ and train many women in the tech industry. I live tweeted her keynote, her message blew me away. As she said, change starts with 1 woman, 1 girl, 1 dream, 1 computer. She is changing the world one step at a time. To paraphrase, “The answer to the world’s problems could be in the minds of women who previously had no chance to even have a dream.” Roya is helping them take their rightful place in society.
Afghan Girls Robotics Team member speaking, with translator at podium.
Roya was followed by one of the members of the Afghan Girls Robotics Team. Agile Testing Days and the agile testing community gave generously to fund the team’s participation in the conference. I don’t know the name of the young woman who spoke, but she had so much courage. She spoke clearly and unwaveringly without notes in her native language, as a fellow translated her words to English.
I live tweeted that too, but I didn’t have a unique hashtag for this speaker so it’s hard to give you a link. As Roya had also described, she talked of the many obstacles for girls interested in the robotics team, with family often against the idea. She told the story of how the team was ready to head to the U.S. for a competition, but their visa was denied. She compared it to climbing a mountain, only to be denied the chance to stand on the peak. But they finally got their visa, and got a second prize at the competition. She spoke of how proud everyone was back at home. For her, the IT industry in Afghanistan is a tiny bud, and she wants to see it grow into a great tree. She finished by describing how supportive her own father was, and how he was tragically killed by Isis just a few days after the team returned home. Yes, we were all in tears by this point.
Several other team members said a few words, some in excellent English. These girls seemed so quiet and unassuming throughout the conference, but they showed their courage here, as well as in their competitive triumphs. Roya Mahboob has helped over 10,000 women, and it looks like she has started something that may now grow exponentially.
Art auctioned for a good cause!
At today’s keynotes, Stuart Young auctioned off his amazing live sketches of the Agile Testing Days keynotes to raise money for Linnea Nordström’s experimental cancer treatment. Not only will this help a courageous young girl, but everyone who will benefit from the research and experimentation underway. I was outbid on my attempts. Oh well, all to a good cause!
Using what we learned
4Cs of Training from the Back of the Room
As usual it was hard to pick a track session. I liked the idea of “Take ATD to Work” with Eddy Bruin and Wim Heemskerk. We learn so much new stuff at conferences, but how do we apply it back at our real jobs? Eddy and Wim showed us through example how we can use the 4 Cs of Sharon Bowman’s Training from the Back of the Room to design our own workshops and share what we learned. It was fun to work in groups with other conference participants and help each other learn the basics of the 4 Cs and come up with workshop exercise ideas. I’ve used the TFBR approach for several years, it’s the best way I’ve found to help participants learn. I regret that I haven’t had a chance to do the exact workshop I planned in this session, but I’m still using the new ideas I picked up.
Learning by osmosis
I enjoyed a serendipitous lunch with Hilary Ridley and Gáspár Nagy (and someone else – now I’ve forgotten! Janet, maybe? Guna Pertrova? I needed sketch notes of lunchtime, too.) I had really looked forward to Maaret Pyhäjärvhi’s keynote, and she delivered! I love her monikers for herself: Feedback Fairy, Polyglot Programmer. Maaret has such a sense of fun and that’s so key to helping us learn. She talked about how individual contributors can make things move without energy – just like osmosis. Promoting collaboration is an effective way to do this, with activities like mob programming that let you get the best from the whole team. She emphasized the safety required for this to work.
Maaret told how her team moved so fast with mobbing that individuals fall way behind. She noted that she could have great ideas without needing to know how to write the code – that’s one of the beautiful things about mobbing.
I loved hearing how Maaret taught her daughter’s school class how to code. Kids really want to code when they see their friends doing it!
Maaret noted that programming is like writing – it takes years to master. I’ve heard that metaphor from Jonathan Rasmussen as well – it’s a great way to think about good coding practices. Being intentional about learning can also cause accidental learning, and we can always learn more! Discomfort leads to change, and learning. Experts don’t know the most, they just learn the fastest.
Several sessions at both Agile Testing Days and at BDD Exchange the previous week talked about change. We can have change through revolution, or we can have tiny, unnoticeable changes that add up to big changes over time. I’m going for those tiny, incremental changes.
Janet Gregory – Pivotal Moments
Between keynotes on this last day we had Open Space, which I was eager to join. However, I got subsumed into other conversations and meetings that needed to happen before the conference was over. I only had time to eavesdrop on a couple of open space discussions.
A smaller but highly enthusiastic crowd stayed around for Janet Gregory’s keynote. Janet wins for staying cool under pressure – the conference A/V system went nuts and it took them quite a few minutes to get her slides to show – despite everything working fine right before the keynote. Ah, the life of a tester.
Janet told her life story, starting on her family’s dairy farm in Alberta, with 24 cows, 3 cats and 3 dogs (Janet could say all that in Swedish). She worked hard on the farm and in school, though she was quiet and wasn’t the kid raising her hand in class. To support her own daughter’s desire to participate in gymnastics, Janet jumped in as a volunteer and, with other volunteers, kept the gym club going. Her takeaway – Get support, don’t be afraid to try! Living in far-off countries for her husband’s work meant Janet had to learn to be independent. When they got back to Canada, she went back to school as a “mature” student to get her CS degree and her first job. Her advice: Know your strengths. How can you use them?
Janet enjoyed mentoring from a helpful manager, but then an encounter with a bad manager made her realize the importance of your workplace matching your ethics. Another challenge emerged at a daughter’s wedding: she froze up and couldn’t make her intended speech. She joined Toastmasters, which would help lead to her successful speaking career. Remember to breathe! And don’t be afraid to share your failures.
Janet explained how she and I met thanks to Brian Marick, and she helped with the book Tip House and I wrote in 2000-2001, Testing Extreme Programming. We both attended XP conferences, and started presenting and writing together, eventually collaborating on Agile Testing. Co-writing a book opened more doors to Janet, who became a full time consultant and coach, traveling the world, building new relationships. She developed a three day training course with me, and we later wrote a second book and a video course. Her peers recognized her leadership with the Most Influential Agile Testing Professional Person award. Wow, when I write all that in one paragraph, those are a lot of accomplishments!
Janet learned to be fearless. She quoted a speaker from a recent conference (was it Fiona Charles?), ask yourself: who’s in your front row? Janet urged us to watch for pivotal moments, respond to them. Be true to who you are. That was a wonderful message to wrap up Agile Testing Days 2017!
“So long” is so hard!
Guna Petrova, my husband Bob Downing, Marianne Duijusst, Gitte Klitgaard, Jack Gregory, Janet Gregory, Stephan Kämper
Luckily, lots of my old and new friends were staying one more night, so we had a big crowd to go to dinner. I’m afraid I was kind of a b***h and said we should split up – it can be miserable organizing a large group and getting a table. We had to get up at about 3:00 am so we needed an early night. I think Mike Talks or someone else in one of the dinner groups later referred to this as the “A” and “B” groups, but I can assure you these were both A+++ groups! We had a wonderful last dinner at one of our favorite Potsdam restaurants, Valhalla. Guna and I went and “haunted” the other dinner group who were down the block at one of our other favorite places, by plastering our noses against the window by their table!
Day 3 of Agile Testing Days kicked off as usual with the 7 am walk/run (I walked!) to Sans Souci, followed by another excellent and well-attended Lean Coffee. This is already my third post about Agile Testing Days, so I’m going to try to stick to a few highlights!
Don’t be a template zombie
David Evans is one of my fellow veterans of all nine Agile Testing Days – along with Stephan Kämper, Alex Schwartz, and Gerard, whose last name I have forgotten despite knowing him for 9 years but he is awesome. David and I go way farther back, I first met him in 2003 when he invited me to speak at his company’s internal conference. I’ll never forget the hilarious skit he and his colleagues did to demonstrate agile development with a cross-country car trip. So I was prepared for plenty of laughs as he explored user stories.
After showing us the funniest/saddest stories ever, David gave us practical tips to combine the business and technical sides of each story, uniting the “why” and the “what”. David advised us to add “Whereas currently…” to each story to describe the current behavior. Leave room for options and other negotiation. Start with the current situation and flesh out options and possible solutions.
David’s alternative template goes like this:
In order to <improve an outcome> <– some value – will it save time, reduce risk, raise confidence?
For <beneficiary of story – someone who matters>
We will < new behavior, feature, output>
Whereas currently <the status quo, the current behavior>
This information is a great start to the conversations we should have among members of the delivery and customer teams to achieve shared understanding of the value we want to provide.
Finding a balance
Guna Petrova explains self-care
Guna Petrova talked about her “Deadly Sins”, all things that sound like GOOD things to do, but can sabotage our most important work. We all have habits, some are bad. I totally identified with Guna’s story, because I’m also a people-pleaser, an approval junkie, trying to help everyone. And if people admire and emulate me – they’re going to burn out too.
Guna explained how she sets limits. If people don’t get immediate help from us, they might help themselves! So when someone interrupts you with a request for help, tell them “I’ll get back to you in an hour”. Love yourself, learn to say no, and focus on the long term. Don’t let fear stop us from learning. Spend quality time in your head – rephrase that inner critic. I was reminded of Denise Jacobs‘ work, which has also been so helpful to me.
Guna’s talk has stuck with me since I got back to work after Agile Testing Days. I’m focusing on ways I can add value on my own team. When faced with the many demands from outside my team, I’m taking time to decide if I can help without detracting from my team’s success. There are lots of ways to help – I don’t necessarily have to do the work myself, I can help people learn to help themselves. It’s hard to fight ingrained habits. One key for me is to find the fun and playful opportunities in every day. When we enjoy the moment, everything goes better.
A MFA takes you a long way
I’ve followed Emily Webber’s work for so long, when I saw her at the ATD Speaker Dinner, I thought I had met her in person before. That’s
Emily Webber describes how a company values their employees
embarrassing! I’ve read her book on Building Successful Communities of Practice, I’ve read her posts from her awesome Agile on the Bench meetup. So I was thrilled to get to watch her keynote.
An artist with a master’s in Fine Arts is bound to have the most amazing slides ever, and Emily’s slides did not disappoint. I think Emily’s artistic background and creativity give her a unique perspective. One of her messages was the importance of diversity. We don’t want superstars, we want people who are empowered to delight customers. Emily warned that the downside of long-lived teams is they may develop group think and homogeneity. I’ve worked on long-lived teams and found the trust we built actually allowed us to freely discuss opposing ideas without taking any personal offense. I have to chew on that for awhile.
What if we trust people and put customers first, followed by employees who work with customers, all the other employees, and the management? It’s the opposite of the usual triangle of power we see where management is the tip of the pyramid. I was so excited about this concept that I immediately slacked my teammates in our Test/Support team. Emily related stories about a company that empowers employees to spend up to 500 GBP to settle customer complaints. My own team is thinking how we can take more ownership of solving our customers’ problems. We shouldn’t just be implementing something that product and design comes up with – we might have great ideas ourselves, given that we work in the same domain as our customers.
My favorite slide of all time conveys a really important point – don’t drag people along. Emily cited a study showing that people fear uncertainty more than they fear pain. That explains why so many people cling to Gantt charts – they don’t work, but they’re familiar. I’ve always wondered why people can experience success with new techniques, but abandon them for the old, non-effective practices that they’re used to. Emily said that people have learned they’re not allowed to change. That shows how critical it is to create a safe environment.
One of my favorite insights from Emily’s talk is her point that change == unknown new skills. We need to make it easy to learn. People need to want to change. Emily walked us through Virginia Satir’s change curve. That’s one way to change. But, we can approach it another way, by avoiding chaos with pragmatism. We can achieve a balance of making small changes over time. For me, that resonated with something I learned from Llewellyn Falco at Agile 2017 – we humans don’t notice tiny changes over time. We can learn without needing to have a revolution, by tiny baby steps over a long period of time. Can you tell that this keynote was one of my big takeaways from Agile Testing Days?
Sofa Session with Mike Sutton
I always find huge value in open space sessions, but I was suffering on FOMA – Fear Of Missing Out – throughout Agile Testing days. There were just so many amazing-sounding sessions in each timeslot. But I made time to go to an unconference-style session, on the sofa in the Havana bar with Mike Sutton.
Sofa Session with Mike Sutton
This turned out to be a bit of an adventure. A large group of us gathered in the Havana Bar, a cool-looking bar that has never before been used at Agile Testing Days. It was not actually a functioning bar – people had to go to the other bar to get drinks. More problematically, we were missing Mike, and it was getting dark and there were no lights. I rooted around behind the bar and found a panel of buttons with labels in German. I’m happy to say that my rudimentary German allowed me to turn on the lights on the first try. I followed this up with going outside the bar to the open space area where I found Mike, whom I hounded into coming into the bar for his sofa session.
I’m afraid I did not take any sketchnotes in this session, I recall that it was a fascinating philosophical discussion but that is all I remember. I hope someone who was in there will comment here and fill us in.
Gary Fleming introduced his talk by pointing out that if you don’t bring continuous delivery to your industry, Amazon will. Developers fret about
Gary Fleming and cat
when their code will get released. Product owners wonder when the value will go live. Testers wonder where the feedback from the release is. We all fear change. Gary started with basic explanations of continuous integration, continuous delivery and continuous deployment.
Gary’s view that feature branches – including git pflow / pull requests – are anti-continuous-integration caught my attention, since this is exactly what my team has been doing. He has a good point – integration != keeping everything apart. What’s the answer? Feature toggles let you keep all the code in the trunk or master all the time. Just use switches in your code.
Gary characterized these switches as glorified if statements. He advised that we shouldn’t write our own feature toggle code, but use existing libraries such as Togglz and featureflags.io. With feature toggles, deploy != release. We can deploy code to production that is behind a feature toggle so that no customers see it until we’re ready to turn it on for them.
One of my favorite highlights – Gary asks, “Be the hero? I’d rather sleep!” I’ve suffered in that hero culture where the person who brought the website back up in the middle of the night was hailed as the hero. Good, healthy software development means it’s a bit boring, with no drama around releasing to production. What would make you feel safe to do continuous deployment, where each successful build of master/trunk gets deployed to production? Boring releases and technical excellence lead to no fear of change.
Continuous delivery has been done safely in many domains. Amazon will soon do it in ours. You might want to get ahead of that.
Making people feel great when you tell them they failed
Whoa, this is already a super long post and I haven’t even gotten to Liz Keogh‘s amazing keynote. Can you understand why I’ve been to Agile Testing Dyas 9 years in a row?
Liz Keogh and updated Cynefin model
I was super excited to learn about the updated Cynefin model with “liminal cynefin” If you aren’t familiar with Cynefin, go search around in Liz’s blog for her amazing posts on it. And you can go look at the official posts about it. I’m going to limit myself to saying that we should do small experiments into the complex area, where we are coming up with new products, and be happy whether we succeed or not, because we are going to learn and create value.
Deliberate discovery will slow you down. “You failed – but we expected it”. Anchor what’s valuable, and end up with a bright future. Real options help to build the safety net that makes it safe to fail – we can buy time for ourselves by keeping out option open. Problems don’t always have one root cause, and we can find multiple opportunities to try something new.
As with all the keynotes, this was recorded, and I encourage you to watch it. Liz reinforced the idea that we should say ‘and’ rather than ‘but’. Don’t suppress ideas or experiences that already happened. Don’t mention failures – talk about what we have learned. Come from a place of care. Create safety, along with options. Run multiple parallel ‘probes’ or experiments into the complex domain where we have unknown unknowns. Teach everyone the Cynefin model, explain that we’re on a journey to a better place.
When working in complex areas, be careful about metrics. We know things WILL go wrong. Think responsibility rather than accountability. Let everyone feel safe to fail – because that means being safe to learn.
Culture is more than a mindset
Yes this is the longest conference day ever. I snuck out to a nice bowl fo soup at one of our favorite restaurants in downtown Potsdam in
Ash Coleman and Keith Klain
between keynotes. But I made it back for Ash Coleman and Keith Klain’s talk. I live tweeted this rather than sketchnoting, so my memories are not as crisp. One of my favorite aspects is that Ash did most of the talking, and Keith listened. Hmm, that is a lot different than daily oife for most of us. As they said, the problem looks like Keith – white guys. The programs our well-meaning companies come up with don’t work. Change is hard, we all have unconscious biases. And I wish I remembered more, but this was recorded also, please go watch it when the video is available!
Women and Allies
Anne-Marie Charrett introducing Women and Allie event
Probably thanks to Ash and Keith’s keynote, we had a great turnout for the Women and Allies event at 9:00 pm (!) Anne-Marie Charrett, Maaret Pyhajarvi and Deborah Pruess facilitiated. We started out with one-on-noe conversations with a stranger. I talked with a single mom who has been told she can’t expect career advancement because she only works 4.5 days per week (she needs time with her kid). Then I talked to another young woman who, like the first, had few women in her degree program, but in her case, she was able to be ‘one of the guys’ in her first job and enjoy career advancement.
We then did an open space sort of thing with different topics. I joined a group talking about both invisible and visible disabilities. This was an emotional experience for me because participants were so willing to reveal their vulnerability. My takeaway: just ask! if someone has an obvious physical disability, ask how you can help. If it’s not visible, that’s a bit more tricky, but I guess it boils down to trying to get to know our teammates and finding out how we can find opportunities to ask how we can help them.
Another 7 am walk followed by Lean Coffee got me going for day two of the conference. One of my takeaways from Lean Coffee was from Viktorija Manevska, who started asking her team this question every day at standup: “What did you learn yesterday?” Though her team treated it more as a joke at first, it led to more interesting standup discussions. Writing this reminded me I want to try this with my team, will start with that tomorrow!
Our Continuous Testing Workshop
Dragan, Lisa and Lisi
I missed the keynote the 2nd conference day to prepare for my Continuous Testing workshop with Lisi Hocke. This was a hands-on workshop, so there were lots of materials to distribute and get to all the tables and onto walls. Luckily, we had Dragan Spiridonov as our awesome volunteer. He helped us facilitate as well as prepare and clean up. With around 80 people in the room, we couldn’t have succeeded without him.
One of the experiments from the workshop
We had two hours of amazing energy in the room as teams identified their biggest obstacles to testing in a continuous delivery environment and came up with hypotheses and experiments to address those problems. Each team did a super job of explaining their problem, hypothesis, experiment and – so important – how they will measure whether the experiment is succeeding. I hope participants will try their experiments back on their own teams!
Our slides are available, but, the slides without the experience of participating aren’t that interesting. Lisi and I would be happy to repeat the workshop at another conference!
I had planned lunch with Steph Desby (I’m happy to say she has agreed to pair with me on a workshop for the next Agile Testing Days!) and – at least one other person, if it was you please remind me! – it is all a blur now but I know we had a great conversation. I love the chance to hear about sessions I had to miss – so much was going on during each time slot.
Katrina Clokie kicked off the afternoon with lots of great ideas in her keynote on testing in DevOps. She began with a story from her school years, when a teacher explained the world is made of atoms you can’t see. Just because you can’t see testers in the Venn diagram of Dev and Ops doesn’t mean we aren’t there!
I highly recommend reading Katrina’s excellent book. She illustrated ways testers contribute in DevOps with several real-life stories, including one about A/B testing experiments. One interesting term she used was “risk appetite” – that could apply to a company or teams as well as to people using our products. I particularly like her mirrored pyramids model with logging, monitoring and alerting combined with unit, integration and end to end testing. We need to find the right combination of all those activities and tests to make sure we delight our customers.
I spent most of the afternoon talking to people at our Agile Testing Fellowship table, telling them about how Janet Gregory and I are expanding the reach of our three day training course. When that’s all ready to roll, you’ll read more about it here, but feel free to ping me if you have questions!
CESAR testing community t-shirt!
I did get around to talk to folks during the breaks. I was thrilled to run into Rodrigo Cursino and his colleague Viviane Lyrio who gave me this amazing t-shirt from the brilliant CESAR testing community.
Breaking down silos with Natalie Warnert
One thing I like about this conference is the diversity of participants. “Testing” is in the name, but there are people in all sorts of roles who are passionate about testing. Natalie Warnert said she’s not a tester, but she knows plenty about how to delight our customers. She pointed out that cross-functionality on teams goes way beyond developers and testers. I loved her story about how all employees at Waste Management have to ride along on the trash trucks to understand how the company serves customers. One driver noticed another brand of dumpster as he made his rounds, and immediately picked up his phone and called someone in sales to tell them about the opportunity.
Natalie advises us not to reward the developer who fixed the bug and saved the day. I’ve worked in that hero culture, and it’s really hard to change. We need to go even further and break down our own individual silos of identity. Good ideas can come from anywhere. Cross-pollination is vital for teams. I love being a butterfly, taking ideas and issues from one group to another within my own team and getting the right people together to talk about them. Natalie had a great story of a janitor at NASA who, when asked what his job was, replied “I’m putting a man on the moon!” Natalie reminds us that we need the courage to care.
Natalie has done such awesome work with the Agile Alliance Women in Agile initiative and conferences. Ping me if you’d like to join the Women in Agile Slack channel.
The sponsor reception following Natalie’s keynote featured good finger food, wine and beer. I enjoyed a lot of great conversations. The main evening event was the Agile Games Night. So many people told me that this was a perfect opportunity to meet new people in a low-stress setting. There were plenty of innovative games and it’s such an inclusive activity. I had to skip the late night Cabaret, since I had to get up at 5:45 in order to do all that walking and Lean Coffee-ing the next morning, but I heard it was a hoot. You can find great photos of the action there and at other conference events on the official conference photos site. Cirilo Wortel also took brilliant photos. As did Eric Roeland, find his here. These folks have generously let us see the photos, please remember they are for private use only and respect the copyright.
I was hoping to get farther along in the conference week, but that will wait for my next post!
I promised myself I would blog about some of the sessions I attended at Agile Testing Days, mainly to help myself reflect and incubate new ideas. I have sketch notes from a lot of sessions so that should help me remember!
We tamed technical beasts together!
Janet Gregory and I facilitated an all-day workshop on Monday where a couple dozen participants joined us as we explored ways to “tame our technical beasts”. So many of us feel we aren’t “technical” enough to succeed as a tester these days. When we started inventorying the technical skills our participants had, it was clear that our fear is unjustified. And even when do lack skills, we found there are many ways to learn them. One fun way that we tried in the workshop was mob testing to practice things like shell commands.
We supplied participants with paper dragons to put together as well as pipe cleaner materials to visualize their own “beasts”, just for fun. Quite a zoo resulted!
Daily Jump Start
Each day at 7:00 am, Søren Wassard got us going with a morning run. Well, I chose to walk, but so did a few others and we had a lovely stroll down to the Sans Souci park. I just had time to get back and grab my stickies and Sharpies for Lean Coffee, which I co-hosted with Janet Gregory, along with various volunteer facilitators. Great way to start the day, even if it meant missing the late-night conference fun.
The opening keynote was from one of my heroes, Jez Humble. I refer you to Pete Walen’s blog for notes on that. I had seen the same keynote at Agile 2017, along with Jez’s awesome takedown of Damore’s Manifestbro, and I didn’t take new notes.
Susan Bligh explains how we can put the puzzle pieces together
can go wrong. We have puzzle pieces that we struggle to put together. Jane the analyst feels that Bob the tester is trying to do what should be her job. Susan took us through a “reset focus” exercise where we thought about what we want, then what other people want. We can view our team through a different lens. What does the team need to succeed? Susan explained that trust is required, which means rewarding team success, not individual success. This was a theme I heard in other ATD sessions too.
Susan advised us to care about our team and engage on a personal level. Find out what people are interested in. What’s their favorite part of being on a project? What do they like about <fill in the blank>? Move away from the blame game. If Bob likes to coach people, ask him if he’d like to do the sprint demo. Share accountability for quality – if one person fails, we all fail. That allows a team of people with diverse perspectives to really rock.
Learning Agile Testing
The next new speaker was Lisi Hocke, who has recently become a pretty experienced speakers, I think she gave four talks over the course of two months. Full disclosure, we did a workshop together on the following day, so I’m a biased audience member. I am pretty much ignorant of the Guardians of the Galaxy, so the whole Groot thing goes over my head. But Lisi’s learning journey resonates with me, as does her message – don’t let fear hold you back. Failing is learning. Lisi adopted a growth mindset and looked for inspiration in Twitter, books, everywhere. She made her job her own, she chose her own identity, she shared what she learned. She engaged her team in experiments like mob programming. She connected via meetups and online communities, and decided to do something that scared her – speak at conferences! I hope Lisi’s story inspires more people to share their experiences with speaking and writing. She’s inspired at least one person, Steph Desby, who agreed to pair with me on an Agile Testing Days session next year!
Gitte Klitgaard & Andreas Schliep discuss responsibility vs. good and evil
Do Good and Evil Exist?
Gitte Klitgaard & Andreas Schliep donned their Jedi robes, picked up their light sabers, and debated whether there is right or wrong, good and evil in the world. They drew on analogies from Star Wars as well as real life to discuss whether people can be inherently good or bad, or if judging people puts them in a box. Perhaps we invite bad behavior with our own actions? Or perhaps we need to invite them to lunch and listen to them. This was such a unique and creative session, I’ve not seen anything like it, and it really made me think.
I made the most of my lunchtime by having made plans in advance with a few people and then having others join us along the way. This first conference day, I managed to eat lunch with Cassandra Leung, Marianne Duijst, Alex Schladebeck, and Guna Petrova – at least I think so, because lunchtimes have run together in my mind and I neglected to take pictures. Just being around their energy picks me up and recharges me so that I’m ready for the rest of the conference day.
Owning Our Own Narrative
Angie Jones inspired us with an illustration from the music business of how we can learn from the past, adapt
Angie Jones explains why and how we should own our narrative
for the future, and write our own success story around test automation. As Angie explained, musicians have a role of entertaining us. Over the decades since the late 1800s, their tools changed, but their role remained the same. When they resisted change, and complained that automation – in the form of phonographs and juke boxes – was ruining their careers, they failed. When they embraced change – used jukeboxes, and later the web, to promote their music – they soared ahead. Angie advised us no to mope, complain, degrade automation, or become “vocabulary Nazis” because we don’t want to give power to test automation. Automation is here to stay. It doesn’t replace anyone. It’s a tool. We need to learn to use new tools, new techniques, new thought processes. It’s more than “shifting left” – shifting can be limiting. It’s about joining your team to learn about design, ask questions, get the team engaged, finding new ways to measure success. We provide value in preventing issues.
I now know what a chatbot is!
Personifying an early video game
I spent the afternoon learning about chatbots with Mike Talks. I took notes somewhere, but they aren’t in my sketch notebook, and I don’t have time to hunt them down. Suffice it to say that getting to create a chatbot for realz was amazing. I paired with Stephan Kämper to create a chatbot that personified his lovely dog. I learned about the benefits a chatbot can provide, and plan to work with my own support team to create our own chatbot and see if it helps our customers have a better day.
Embracing new hires
Poornima Vijayashanker told us some surprising stories about onboarding new hires and how easily that can go wrong. Again I plead bias, as my Pivotal Tracker team sponsors Poornima’s awesome videocast, and is currently offering a free download of her book Present: A Techie’s Guide to Public Speaking. And, i did’t sketchnote so see Pete Walen’s writeup.
So many great costumes, so much fun
Super Agile Person
The Agile Testing Days costume party is always the highlight of the week. Always great food, a great band, amazing costumes. Please see Cirilo Wortel‘s amazing photos for a look at some of the many awesome costumes, as well as the many awesome people throughout Agile Testing Days. I leave you with Super Agile Person, a super hero born of Agile Testing Days and destined to be at this party.
I’m committed to posting more on Agile Testing Days, please be patient, it will extend the enjoyment!
Thanks to everyone who posted ideas on ways conferences can be more inclusive of newcomers and avoid the perception of having “cliques” of speakers and veteran attendees, in response to my post. I’d like to share some of them here.
Liz Keogh‘s keynotes and workshops are always so inspiring and helpful to me. A few years ago she took time in the lobby of the conference hotel to explain ways I could use Cynefin (TM) to help with testing. She suggests giving speakers (or anyone!) signs or cards to pass along, saying when we’re available for random conversations. She added that “newcomer” is a welcoming term for first-year participants; other labels often imply lack of experience or skill.
On the topic of labels, Elizabeth Zagroba suggests we give people the option to identify as newbies, speakers, or whatever. Conference organizers could give each attendee stickers or labels along with their badge, and each person can opt to attach them or not. Elizabeth also related her practice of introducing herself to whoever is sitting next to her right before a session starts. That way she doesn’t have to think of something to say immediately. That’s a great lead-in to a conversation after the session.
Emily Webber says that at meetups, she has given people a question to ask of someone they haven’t met before. “It helps to open a conversation when you have words to use”, she advises. Emily is an outstanding speaker and community builder. I’m definitely going to try that idea.
I’ve watched Stephan Kämper go from a new conference participant to an experienced workshop presenter/facilitator over the past 9 years. At conference lunchtime, he sits at an empty table and waits for others to ask to join – which of course they do. He explains, “Apart from getting to have lunch with someone I may not know yet, I don’t have to ask to join a table. Yes, I’m an introvert.” He likes having the labels on the nametags to know if someone is a rookie, alumnus, speaker, volunteer or organizer. It helps him reach out to first-time attendees. I have to say that I also like the way these labels can help start a conversation. I always thank volunteers that I see. And I can ask questions like “What are you speaking about” or “How does this year compare with last year” or other questions, depending on what I read on the badge.
Ingrid Sutherland notes that it’s up to veterans and newcomers to create the conference atmosphere, but that’s difficult if speakers are treated as celebrities. She tweeted, “I don’t want to be a groupie, I just want to say thank you or ask a question”.
As a speaker, I sure don’t want to be treated as a celebrity. The reason I speak at conferences (which is way outside my comfort zone, even though I’ve been doing so for decades) is so that I can attend the conference, meet people and learn new ideas. If I don’t get a chance to talk to other participants, my learning is going to be awfully limited.
Several people said that the CollabLab at Agile Testing Days, as well as TestLab and similar activity centers at other conferences, are particularly inclusive and everyone, including newbies, get lots of help there. I talked to several first-time attendees who got help with public speaking skills in the CollabLab. Several Agile Testing Days attendees also raved about the Agile Games Night as a wonderful place to get to know people in a comfortable, safe and fun place. I heard from TestBash Philly attendees that the TestBash Circus there was a fun and inclusive activity. Richard Bradshaw shared a link describing it, but I’d love to hear from more people who got to experience it.
Lean Coffee at Agile Testing Days 2017
We had lots of first-time folks at the Agile Testing Days Lean Coffees, and several of them told me they really appreciated the opportunity to get to discuss a variety of topics with a variety of people. If your next conference doesn’t have a Lean Coffee, consider hosting one yourself.
If I failed to include your suggestion, please leave a comment. I was so excited to get so much feedback on this.
I went to my first testing conference back in the early 90s. I learned a lot, but I was too intimidated to try to “network” with anyone. The speakers seemed standoffish, the feeling I got was “You’re a nobody, so don’t try to talk to us.” Maybe that was an unfair interpretation on my part, but there was no effort to make non-speaking participants feel included. Since much of the value of conferences is the people you meet and the learning you do outside of the official sessions, being inclusive of all participants is vital.
A more welcoming community
What a difference I found at XP 2001 in Raleigh (one of the precursors to the current Agile 20xx conference). The people who “wrote the books” were all so welcoming. Even being such a shy person, I had conversations with many of the leading XP authors and practitioners, and met people who still help and support me today.
I can’t put my finger on what made the XP conferences so welcoming, other than the humility and friendliness of the “big names” there. Perhaps because it was a new and passionate community. I think we need to identify the factors that make everyone at a conference feel included, and make sure they are in place.
I’ve been to several conferences where I felt part of a friendly and helpful community. Agile Testing Days and TestBash are both good examples – to me.A few months ago I had read a post by Chris George in which he discussed conferences, cliques and community. (I had forgotten who wrote the post until after I published this, so I’m giving credit where it is due). It raised my awareness of how many conference participants can feel like their “outsiders” and not getting the full benefit of the community.
Since then, I’ve heard myself from first-time participants of both of these say that they found that the “veterans” of the conference formed cliques and that new participants felt excluded. Stories like this: “While I was talking with <name of person who is well known in the community>, someone came up and hugged her and started talking to her, excluding me. It was so rude.”
I know how hard the organizers of these conferences work to promote a welcoming environment. Agile Testing Days 2017 had a Meet and Greet evening the night before the conference. They made reservations for groups at several different restaurants, let people sign up for a group, and had a volunteer escort each group to dinner. This gave each person a group of familiar faces, with whom they connected throughout the conference. Even so, some people who participated experienced rude behavior on the part of conference speakers and other conference alumnae.
A group of friends at the hotel bar, might look like a clique to newbies
I love hanging out in the hotel bar with friends I have known for years. But I want everyone to know we would love them to join our group. I have to work a lot harder at this.
How can we make conferences inclusive?
Cassandra Leung came up with a terrific way to motivate herself to meet people at conferences: Tester Bingo, which she explains on the Tester’s Island Discs podcast. She provided Tester Bingo cards for Agile Testing Days, they were available at the registration desk. As a shy person, I found it a great excuse to walk up to a stranger, introduce myself, and ask them to write their name on my bingo card. Unfortunately, a lot of participants somehow didn’t learn about the Tester Bingo. I think the bingo cards would help a lot of people be brave enough to go introduce themselves to both the people pictured on the card, and to other people to fill in the blank spaces.
At Agile Testing Days, a first-year participant noted that the conference name badges were color coded. Speakers had one color, first-time participants had another. The idea might have been to let veterans know who was new and help them feel welcome. And it can be a great conversation starter to ask a speaker “So, what is your session about?” Still, it could also make people feel categorized and excluded.
I think conference organizers can do a lot, as seen with the Agile Testing Days dinner idea that I described above. But they can only do so much. I think it’s up to us, the veteran speakers who love to catch up with each other at conferences, to include delegates that we don’t know. I tried to be really mindful of this at Agile Testing Days, but I fear I probably was sometimes the one who interrupted a conversation to hug a friend. I did work at speaking to new people (filling in my bingo card!) and sitting down with strangers at mealtimes.
Make an effort
I had a lovely serendipitous moment at breakfast on the last day of Agile Testing Days. It was early and the restaurant was pretty empty. I saw a young woman who looked familiar and asked if I could sit with her. This was way out of my comfort zone – I’d rather eat alone than with a stranger, and I wasn’t even sure she was there for the conference. She was there for only the last day of the conference, because she had to pay for it herself and she had traveled from Budapest to Potsdam to participate. She made the most of her one day: she attended the Women and Allies workshop the night before (which is why she looked familiar), she came to the 7:00 am Run/Walk, the 8:00 am Lean Coffee, and the regular conference sessions. It turned out that we had a mutual friend, and we accidentally all had lunch together. That was a wonderful connection for me, I enjoyed learning about her testing community in Budapest. I hope she found value as well.
What ideas do you have to make sure everyone feels welcome at conferences, and avoid these sort of high-school style cliques? Intentions are good all the way around – but we need to change the reality.
My article on pairing with developers is live on the Ministry of Testing. I love pairing with developers. It’s fun, and I learn so much. I feel we are really building quality in together, catching issues early, finding inconsistencies or questions to discuss with the product owner.
Whether you’re a tester or a developer, I hope you’ll try pairing! And no matter what your main specialty, pairing with someone in another specialty is so rewarding on so many levels. You’re bringing different perspectives together, which helps overcome your unconscious biases.
If you’re participating in the Ministry of Testing’s 30 days of agile testing challenge, I hope this article will help you with the pairing challenges! I didn’t mention it in the article, but pairing works well if you and your pair are not co-located. We have great tools these days like ScreenHero for screensharing along with audio and video.
I’d love to hear your experiences with pairing.
I also recommend publishing articles with Ministry of Testing. For one thing, they compensate you. And you have the option of donating your comp into their Scholarship Fund. They have expert editors to help you. Whether you are a newbie or experienced author, you will enjoy the experience.