Loading...

Follow Agile Testing with Lisa Crispin on Feedspot

Continue with Google
Continue with Facebook
or

Valid

I’ve had such an exciting time the past year and it has led me into an amazing new opportunity, I’d like to share my learning journey so far!

Modern testing and data science

For the past year, I’ve been inspired by Alan Page and Brent Jensen’s A/B Testing podcast discussions of their “Modern Testing” principles. One facet of Modern Testing (as I understand it) is that as testers, we have to learn how to analyze and learn from production data. How do our users use our products? What errors do they have? How quickly can we act on these? In the era of continuous delivery, we can’t possibly do enough testing to be confident we’re consistently releasing a quality product. The modern tester has to learn about data science.

Continuous Delivery and DevOps

Continuous delivery is another huge area of interest for me. I’ve been working with operations experts since the 1980s, and I’ve always enjoyed configuring CI tools and helping the team shorten our feedback loop for automated tests. I was lucky to pair with Abby Bangser on a pipelines workshop at European Testing Conference this year, i learned so much from her. I really enjoy helping other people learn how they can make their pipelines more robust. I’ll be doing an all-day tutorial with Ashley Hunsberger at CAST 2018 on the Whole Team Approach to Continuous Delivery. I’ll be doing another all day workshop, this time with Christin Wiedemann, “Build Your Own DevOps Roadmap”, at KWSQA. (Am I lucky to co-present with these amazing people, or what?)

Machine learning and test automation

Several months ago, my manager on the Pivotal Tracker team, Jo Webb, suggested that we look into how people are using machine learning for test automation. I’d heard about mabl from Joe Colontonio’s TestTalks podcast. Somehow I also discovered that my friend Stephen Vance works on the mabl team! Just to fast forward this story, I got lots of help from Steve to start doing smoke tests with mabl. I was impressed with how mabl takes in so much information about each UI page and can intelligently attempt to repair a test if it can’t find an element for an assertion or action. Another huge benefit is that each test runs in its own container, so that no matter how many tests you have in your suite, your feedback loop is only as long as your longest test! And, it runs the tests simultaneously in multiple browsers. The speed is really impressive to me.

An opportunity!

mabl

My husband and I are moving to Vermont, and I want to work remotely from there. Since Steve lives in Boston, I asked him to let me know if he heard of any remote working opportunities there – it is pretty close to Vermont so that seemed like a good option. One thing led to another, and I am thrilled to announce that I will be working for mabl, starting July 30!

We haven’t quite figured out what to call my job, but I’ll be a test consultant of sorts. Once I learn enough about how machine learning can help with difficult test automation challenges, I will start blogging and speaking about it to help others learn. I’m not going to try to sell you on mabl – maybe it is a great tool to add to your toolbox, and maybe it is not a good fit for your context. But I believe that Alan and Brent are correct that we all need to learn data science, find ways we can learn from production use data, find ways we can leverage machine learning to help our teams succeed with continuous delivery.

Let’s learn together! I’d love to hear your own questions about data science and machine learning. I’d also like to hear what challenges your team runs into as you try to succeed with continuous delivery. Many of us deal with “flaky tests”, failing pipelines, lack of visibility of these failures, lots of frustration in reliably delivering value to our customers at a sustainable pace.

Lisa’s Excellent Adventure

I am so excited about this new adventure – moving with my husband and all our animals to beautiful Charlotte, Vermont, and giving myself a huge challenge of learning a new technology. I know I’ll be working with an awesome team, so I’m not too scared. I’m so grateful to the mabl folks for this opportunity.

Oh, and if you know anyone who would enjoy an amazing horse property with a built-in brewery near Parker, Colorado, we have one for sale!

The post Continuing my learning journey appeared first on Agile Testing with Lisa Crispin.

Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

In February I wrote about the experimental retrospective format for our team’s “cross-pod retro” (so-called, because our large team is divided into smaller pods). Since then, my manager Jo Webb and I have continued to tweak the retro format, based on feedback from surveys done following each retro.

Building on feedback

Our teammates said they got lots of value from the small group discussions. They also liked the way we included remote team members via laptop and video chat for each small group. On the down side, they found self-organizing into the small groups awkward, they were disappointed with the followup on action items and experiments, and some people weren’t satisfied with the range of topics to discuss.

All-remote for better communication

For our latest cross-pod retro, Jo and I had trouble booking the only large conference room in our office which will fit our on-site team. Our team had recently tried an “all-remote” meeting for our bi-weekly “share and tell”, where each pod demos what they’ve been working on. It worked really well, so we decided to try an all-remote retro. Jo is remote, and I am remote two days a week, so we both especially value letting remote team members be on an equal footing with the local team.

Technology

We use Zoom for meetings, and Jo discovered that it has a “breakout rooms” feature. The meeting host can put participants in separate breakout rooms for small group discussions. The host can send messages to each breakout room, although participants in the rooms can’t reply back. We tested this with a few people and found it worked well for our purpose. Jo was kind enough to act as facilitator so that I could participate.

We planned to have each small group use a shared Google drive document to record their discussion as well as their outcomes in the form of experiments and action items. Each group would free to use their own retro format within their discussion, such as a “happy/puzzled/sad” collection and discussion.

The process

For the actual meeting, once everyone was in the main zoom, Jo started the meeting by soliciting appreciations. Since it’s a cross-pod retro, we ask for people to shout out people in other pods or roles who helped them or had an awesome achievement. We’ve continually gotten positive feedback about this nice way to get the meeting started and the energy up.

Jo explained the goals of the retro, to reflect on challenges and problem areas in small groups and design experiments to address them. After 30 minutes of small group discussion, each group would present their outcomes. The topic areas this time were process, culture, learning, psychological safety, empowerment and effecting change, and remote collaboration.

We had a shared spreadsheet with a column for each topic, so that each of us could put our name in the column for the topic we wanted to discuss. We asked that if a group got larger than five people, they divide themselves into two groups. It took a bit longer than we expected for Jo to create the breakout rooms with so many people.

Great discussions – face to face

I joined the psychological safety group. I found this particularly interesting because a new designer had just joined our team, and she chose to join our discussion. She had some experience working on inclusion activities in another company office. We also had someone visiting from our Dublin office who asked to participate to see how we do our retro. Having these fresh perspectives along with long-time team members added so much to our discussion. We collected topics with a “Happy/Puzzled/Sad” format on a shared spreadsheet. We didn’t have time to get to all of them but we felt we addressed the most useful ones. Our action items included learning more from the activities in the other offices that our new designer and visitor volunteered to research.

Jo messaged each breakout group 10 minutes and 5 minutes before the time limit to remind us to be ready to share our outcomes when we joined back together. That was super helpful to keep us focused.

I felt it was a huge benefit that we could all see and hear each other equally well. When the co-located team is in a conference room with remotes on the monitor, it’s hard for remotes to see and hear everything. I’d like to hear all the jokes, whether I’m physically in the room or not!

Debrief

At the request of our facilitator Jo, we all joined the main meeting again. Zoom’s breakout feature made this all really easy. A spokesperson for each group gave a summary of their discussion and action items, including how they might measure progress towards their goal. This went really quickly.

Jo asked that anyone willing to co-facilitate a future retro let her or me know. Our plan is to continue to pair – one experienced facilitator can pair with the next volunteer.

One of our teammates suggested that next time, we do the topic selection and group-joining ahead of time, so that the breakout rooms can be created faster. We will definitely try that.

We ended up being able to stop a bit early. Each group put their shared document or spreadsheet into our “cross-pod retros” folder so that we can all read through them.

Followup

I created and sent out a feedback survey to see how people like the all-remote format and get ideas for more improvements, as well as remind everyone to let us know if they’d like to help facilitate in the future. We already have one volunteer!

We are waiting for survey results, but the vibe seemed quite positive to me. The group that discussed challenges for remote people pointed out that the company has an initiative to improve inclusion for remote collaboration and encouraged us to join the #remote Slack channel.

One recent improvement in our team was to attach high quality noise-cancelling headsets to each pair workstation so that it’s super easy to pair or mob with remote team members. Thanks to that, many of our pods and wedges have all-remote standups, mob programming and testing sessions, and retrospective meetings where everyone is remote. I feel like this is transforming the atmosphere and helping remotes (including myself two days a week) feel so much more included and valued.

Learning

Dual lessons here: keep experimenting with retro formats so that the team gets more value from them, and keep finding ways to include remote team members and let them contribute their maximum value. I’d love to hear your own experiences with all-remote retros.

The post All-remote retrospective appeared first on Agile Testing with Lisa Crispin.

Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 
Mob all the things!

I’m so excited that I get to participate in the Mob Programming conference next month- April 12-13 –  in Burlington, MA. Check out the program and registration details. This is an amazing opportunity to work in small groups with leaders like Lisi Hocke, Woody Zuill and Llewellyn Falco. An even better way to learn about the “moberators” and their sessions is to check out the awesome blog posts.

I’ll facilitate a mobbing session for exploratory testing. This is such an effective way to get lots of perspectives looking at a feature. Since we all have different unconscious biases, observing and testing with several people together helps us overcome those biases.

In my other workshop, I’ll facilitate a Visual Thinking Strategy workshop. Visual thinking strategy sessions let you practice and improve the skills of observation, critical thinking creativity, curiosity and more that you need to test effectively.

I hope some of you can take advantage of this opportunity to actually DO mobbing with the leading mob programming and testing practitioners today.

The post Mob all the things! appeared first on Agile Testing with Lisa Crispin.

Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

You might notice that my posts here aren’t necessarily about actually doing testing activities. For the past several years I’ve been one of only three testers on a team of 25 or more coders. Currently, I’m the only tester spread across several mini-teams that add up to around 17 coders. I can’t possibly test every story that the teams deliver. My best hope of helping our team deliver value to customers at an acceptable quality level is to help the team learn more ways to accomplish that themselves.

I’ve been learning about the “modern testing” approach from Alan Page and Brent Jensen. They describe it as basically what’s in Janet’s and my books plus the tester acting as a tester coach, helping the team learn testing skills. For me, it’s not only about what we might call testing skills, but lots of other skills that help us be more effective testers and team members.

Retros Learning together FTW

Providing leadership in building quality into our product takes me way outside my comfort zone. Some people may say it’s not the tester’s job to facilitate retrospectives. Wait a minute – retrospectives are one of the main ways that agile teams can identify problems and design experiments to address those problems. That’s how we improve quality.

I posted recently about facilitating a retrospective for my entire large team. Our team does these “cross-pod” retros every month, but being so busy, I failed to notice that the next one was coming up. Fortunately, my manager did notice, and checked with our VP that he wanted us to facilitate.

At first I shrank from the idea. Yes, I had gotten a lot of positive feedback on the previous retro that I co-facilitated. But there was some negative feedback too. At one level it just feels too hard to add this burden to my “day job”.

Then I reminded myself that I want to help my team find ways to improve and thought, “OK, i’ve got this”. My manager and I used the feedback from the previous retro to adjust the format, keep the things that everyone really liked, and adjust for things that some didn’t like so much. Since I really wanted to be able to participate, my manager agreed to facilitate, after we had laid the groundwork together. It was another useful retro with a few new experiments coming out of it.

Visual Thinking Strategy

Another recent post here was about the Visual Thinking Strategy workshop that Alex West facilitated for quite a few of my team members. Feedback from my team members was enthusiastic. I’d participated in two workshops with Alex, and she is generous at sharing how to facilitate one of these workshops. I gathered my courage and scheduled another VTS workshop that I would facilitate myself.

I got just enough people interested (advertising fancy cheese was a plus) to make this VTS workshop work. It was a fantastic experience and everyone reported benefits. My teammates who participated felt I had done a good job of facilitating. So, I have volunteered to do a VTS workshop for anyone in our office – which consists of several different areas of the company – who is interested during one of our office “Tech Talk Wednesdays” where lunch is catered. I hope I can spread this practice to other parts of the company, because I feel it has so many benefits.

In addition, a couple of my team members were keen to do more VTS in the context of working on our own team’s features and infrastructure. Our PO suggested I might facilitate our next “pod” retro and spend the first 30 minutes doing a VTS workshop as a way to build psychological safety and warm up everyone’s creativity, collaboration and observational skills. I feel confident to do this. But, we’ve been doing so many experiments lately, I’m worried that some teammates are “new thinged-out”. I’ll talk to my teammates and see what they think will work for them, and forge ahead. Because the truth is, I’ve got this.

Yep, I’ve got this

My team has the courage to try some pretty radical experiments. We’ve succeeded in getting a lot of new features out that our customers find valuable. And yes, there have been a lot of problems in production too. We are learning!

I know I have the skills to be an effective testing coach for my team.  I can find the courage to make my own best contributions, whether they are about explicit testing activities, or less obvious skills and practices that help us build more quality into our product.

What can you do to help your non-testing team members learn ways to build quality in? Find the courage to try experiments. Even if experiments fail, we all learn something. Not your job as a tester? If we really want to help our team deliver a quality product, we will use our leadership skills as best we can.

The post Courage to coach appeared first on Agile Testing with Lisa Crispin.

Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

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.

Experiments

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.

Choosing experiments

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.

Doing experiments

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!

The post Retrospectives for large teams with many sub-teams appeared first on Agile Testing with Lisa Crispin.

Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

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!

Fern Cats

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.

The post Telling stories together while practicing critical thinking with VTS appeared first on Agile Testing with Lisa Crispin.

Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 
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!

The post My Tester’s Island Discs! appeared first on Agile Testing with Lisa Crispin.

Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

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.

Pivotal moments 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!

I miss all of these people so much right now! I can hardly wait for Agile Testing Days USA and Agile Testing Days 2018.

The post Wrapping Up Agile Testing Days 2017 appeared first on Agile Testing with Lisa Crispin.

Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 
Mob all the things!

I’m so excited that I get to participate in the Mob Programming conference next month- April 12-13 –  in Burlington, MA. Check out the program and registration details. This is an amazing opportunity to work in small groups with leaders like Lisi Hocke, Woody Zuill and Llewellyn Falco. An even better way to learn about the “moberators” and their sessions is to check out the awesome blog posts.

I’ll facilitate a mobbing session for exploratory testing. This is such an effective way to get lots of perspectives looking at a feature. Since we all have different unconscious biases, observing and testing with several people together helps us overcome those biases.

In my other workshop, I’ll facilitate a Visual Thinking Strategy workshop. Visual thinking strategy sessions let you practice and improve the skills of observation, critical thinking creativity, curiosity and more that you need to test effectively.

I hope some of you can take advantage of this opportunity to actually DO mobbing with the leading mob programming and testing practitioners today.

The post Mob all the things! appeared first on Agile Testing with Lisa Crispin.

Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

You might notice that my posts here aren’t necessarily about actually doing testing activities. For the past several years I’ve been one of only three testers on a team of 25 or more coders. Currently, I’m the only tester spread across several mini-teams that add up to around 17 coders. I can’t possibly test every story that the teams deliver. My best hope of helping our team deliver value to customers at an acceptable quality level is to help the team learn more ways to accomplish that themselves.

I’ve been learning about the “modern testing” approach from Alan Page and Brent Jensen. They describe it as basically what’s in Janet’s and my books plus the tester acting as a tester coach, helping the team learn testing skills. For me, it’s not only about what we might call testing skills, but lots of other skills that help us be more effective testers and team members.

Retros Learning together FTW

Providing leadership in building quality into our product takes me way outside my comfort zone. Some people may say it’s not the tester’s job to facilitate retrospectives. Wait a minute – retrospectives are one of the main ways that agile teams can identify problems and design experiments to address those problems. That’s how we improve quality.

I posted recently about facilitating a retrospective for my entire large team. Our team does these “cross-pod” retros every month, but being so busy, I failed to notice that the next one was coming up. Fortunately, my manager did notice, and checked with our VP that he wanted us to facilitate.

At first I shrank from the idea. Yes, I had gotten a lot of positive feedback on the previous retro that I co-facilitated. But there was some negative feedback too. At one level it just feels too hard to add this burden to my “day job”.

Then I reminded myself that I want to help my team find ways to improve and thought, “OK, i’ve got this”. My manager and I used the feedback from the previous retro to adjust the format, keep the things that everyone really liked, and adjust for things that some didn’t like so much. Since I really wanted to be able to participate, my manager agreed to facilitate, after we had laid the groundwork together. It was another useful retro with a few new experiments coming out of it.

Visual Thinking Strategy

Another recent post here was about the Visual Thinking Strategy workshop that Alex West facilitated for quite a few of my team members. Feedback from my team members was enthusiastic. I’d participated in two workshops with Alex, and she is generous at sharing how to facilitate one of these workshops. I gathered my courage and scheduled another VTS workshop that I would facilitate myself.

I got just enough people interested (advertising fancy cheese was a plus) to make this VTS workshop work. It was a fantastic experience and everyone reported benefits. My teammates who participated felt I had done a good job of facilitating. So, I have volunteered to do a VTS workshop for anyone in our office – which consists of several different areas of the company – who is interested during one of our office “Tech Talk Wednesdays” where lunch is catered. I hope I can spread this practice to other parts of the company, because I feel it has so many benefits.

In addition, a couple of my team members were keen to do more VTS in the context of working on our own team’s features and infrastructure. Our PO suggested I might facilitate our next “pod” retro and spend the first 30 minutes doing a VTS workshop as a way to build psychological safety and warm up everyone’s creativity, collaboration and observational skills. I feel confident to do this. But, we’ve been doing so many experiments lately, I’m worried that some teammates are “new thinged-out”. I’ll talk to my teammates and see what they think will work for them, and forge ahead. Because the truth is, I’ve got this.

Yep, I’ve got this

My team has the courage to try some pretty radical experiments. We’ve succeeded in getting a lot of new features out that our customers find valuable. And yes, there have been a lot of problems in production too. We are learning!

I know I have the skills to be an effective testing coach for my team.  I can find the courage to make my own best contributions, whether they are about explicit testing activities, or less obvious skills and practices that help us build more quality into our product.

What can you do to help your non-testing team members learn ways to build quality in? Find the courage to try experiments. Even if experiments fail, we all learn something. Not your job as a tester? If we really want to help our team deliver a quality product, we will use our leadership skills as best we can.

The post Courage to coach appeared first on Agile Testing with Lisa Crispin.

Read Full Article

Read for later

Articles marked as Favorite are saved for later viewing.
close
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

Separate tags by commas
To access this feature, please upgrade your account.
Start your free month
Free Preview