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

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.

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.

 

Feature Toggles

Gary Fleming introduced his talk by pointing out that if you don’t bring continuous delivery to your industry, Amazon will. Developers fret about

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?

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

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 life for most of us. As they said, the problem looks like Keith – white guys. It’s up to them to change the status quo. 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

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.

.