Sunday, September 23, 2018

Agile Greece Summit 2018 - Speaking, Sketchnoting, Conversing and Exploring

The 4th Agile Greece Summit is over! Glad I was a part of it. I spoke, I sketchnoted, I had great conversations with a lot of awesome people and I explored the city of Athens. It was awesome.

Speaking

Maaret Pyhäjärvi gave me a great opportunity by recommending me as speaker at Agile Greece Summit 2018. The organizers were intrigued to hear my talk "A Tester Exploring Developer Land", so this talk it was - and the audience obviously liked it. I received lots of feedback and people told me they got new ideas what to try in their teams - awesome! Following Maaret's recommendation, the organizers asked me to give my mob session "Learning to Learn in a Mob" in addition to the talk and I'm glad I agreed to do it. The workshop attracted a lot of people, way more than expected. We had to close it early, allowing more people to observe the mob than planned. Fortunately, we could still make it a safe space for everyone to learn.

Sketchnoting

All the feedback I received on my sketchnoting experiment last week at TestBash Germany 2018 really encouraged me to give this technique another try. Reflecting on my time balance, when I spent my time on what, I had also experienced a positive outcome. Therefore I decided to sketchnote the talks of this conference as well, enabling me now to provide you the most complete overview of the talks I attended that I can provide. Reviewing my notes and comparing them with the #agrs2018 live tweets of others attending the same sessions, it's clear that I got some things wrong and missed some other parts. Still, these notes are as honest as they can be, showing what message I received and which thoughts stuck long enough so that I could commit them to paper.
By the way, if you fancy another write-up on the conference and the keynotes, check out Marcus' great post Reflections after Agile Greece.

Back to sketchnoting. Once again, I received lots of positive feedback on sharing my notes. Constantine reached out and asked whether I would rewrite the notes in a digital form like a mind map and share them. This made me think. My original intention behind trying sketchnoting was to get rid of the duplicated effort of scribbling down notes and then having to transfer them into digital notes. The idea was that if I write notes in a good enough manner already during the conference and digitalize them by photographing and tweeting them, I will save the follow-up time at home, which is my free time I'd like to spend on other things. So far this experiment worked out for me; though I already realized that this format does take its time as well. The benefit of sketchnoting, however, is that I can share those notes with the world, giving others an impression what the talk was about, sharing knowledge and also getting feedback on what I understood incorrectly. Therefore trying sketchnoting was worth it so far and only time will prove if it does on the long run.

Conversing & Exploring

The people were wonderful. Organizers and volunteers were really supportive and made a great conference happen. Attendees were interested and actively socialized. The other speakers delivered insightful content. Like at all conferences, I especially enjoyed all the great conversations I had. The following people I'd like to thank in specific.
  • Marcus Hammarberg: Thank you for sharing your insights about mob programming, collaboration and learning. I really enjoyed our dinner before the conference, and just love the movement you started of paying dinner forward.
  • Anka Miedzianka: Thank you for sharing your experiences as speaker with me, I could so much relate to them! I really enjoyed our dinner conversations and already look forward to meeting you the next time.
  • Linda Rising: What can I say? You are wonderful and it was an honor and pleasure to meet you! Thank you for our deep dinner conversations and especially for listening. And even more, thank you for reminding everyone to do so.
  • Alison Coward: Thank you for our great taxi conversation how to increase flow in teams. Would love to hear what you think about the mob approach once you dived deeper, especially when it comes to your work with teams!
  • Gwen Diagram: Thank you so much for spending the day after conference with me, exploring Athens by foot, discovering so many interesting places, hugely different quarters and amazing views together while sharing so many life lessons! It was wonderful and I'm already looking forward what we might explore and find next together.
I'm heading home inspired, with more ideas in my head and more people in my heart. Thank you all.

Saturday, September 15, 2018

TestBash Germany 2018 - My First Attempt In Sketchnoting

Why write down again what had already been written down by someone else? Therefore, here's the condensed form what the second edition of TestBash Germany was like. At least, what it was like for me. ;-)

This year I was not speaking but only attending the conference, so I had time to focus on having conversations with great people and enjoying the talks. Too easy? Well, that cries out for an experiment! Or two.

Experiment #1: Sketchnoting

Seeing all the masterpieces online, I also wanted to give sketchnoting a try. I mean, a real try - not giving up the first minutes into the talk when I saw my notes will never ever fit one page only. The evening before the event these thoughts kept buzzing in my head so my brain kept me awake until I finally resolved upon actually sketchnoting at TestBash Germany.

The following two persons inspired me heavily when it comes to sketchnoting: Marianne Duijst with her awesome collection of sketchnotes and constant encouragement to try it; and Ekaterina Budnikov who lately shared great advice how to get started. Now, I always did take notes on conferences before. I wrote everything down in great detail without thinking about it, and later on at home I transferred my messy scribbled notes into a readable and structured digital form. Doing so cost lots of time. As I'm now going to more than one conference per year I wanted to see whether I could reduce that time investment while still having proper notes for later reference.
The result: I really did it! It was quite exhausting, but I learned a bunch.
  • It was good that I brought some pens with me already: black, blue, green and red were the colors of my choice. I used a simple squared notebook.
  • I quickly noticed that the black pen was dry, so I had to switch to blue. At least this is only visible in my first sketchnote. The other colors stayed usable until the end.
  • The different colors were really helpful for additional structure elements, like marking section headers, as well as navigational elements, like linking different areas of the sketchnote. In the end, two colors were sufficient, blue and green.
  • I did not take notes on a separate sheet for adding them later to the sketchnote, but I did take photos of content-heavy slides so I could look up what I missed in case the speaker was faster than me.
  • Most of the time I focused on text, but over time I realized when there was time to add some small images as well. Doing so, I noticed which image vocabulary I already had learned for preparing workshop posters so I could quickly express ideas visually, and which images were not already accessible so I had to think about them, taking more time.
  • Some talks were way easier to sketchnote than others. Surprisingly, there was one talk without slides - but it was one of the easiest to sketchnote due to the storytelling.
  • In the end, I did manage to fit everything on one DIN A5 page for each talk. For some talks that was really, really hard. I did not yet bother how to fill the page's whitespace in a visually nice way when I did not take up all of it. Most times, I had the challenge what to leave out instead, as I tend to write down everything and therefore run out of space. Also, at times I lost some space I would have needed just because I started not on the very top of the page or had some useless gaps in between.
  • My hands got all blue from the main pen, and I happened to blurr some notes. Couldn't help it, so I kept going.
  • I'm so much in awe for those great sketchnoters out there who manage to extract the essence of what they hear in a split second and record it in a visual and informative way. At least, I would say I got better over the day, but judge for yourself.
Most sketchnoters make a photo right after the talk and instantly tweet it. I did not dare to do that, and also felt I lack the time. So I postponed this decision for after the conference, and then got inspired to just give it a try and shared them. The feedback I received was indeed heavily encouraging, I think there's going to be another round of sketchnotes coming! But next time I'll get me some proper pens. ;-)

Experiment #2: Tweeting Continuously

To follow the same theme of reducing my time investment after the conference, I wanted to go through the Twitter stream of the conference's hashtag continuously throughout the day in small pieces, to stay up to date. I decided to do this directly after each talk. I succeeded, however, also missed some great questions and answers by doing so. An accepted trade-off for this experiment. Also, I decided not to live tweet myself as I had tried that already at another conference and it would have clashed with the sketchnoting experiment, but merely retweet great live tweets of other attendees.

The result: Tweeting rather "just in time" was a quick and easy way for me to share content without having to do it in my free time. It was also nice to get instant feedback from those who could not attend the conference, they really appreciated to experience it from afar this way. However, this might only have been feasible because it had been a one track conference with only a few live tweeters, so the amount of tweets I went through after each talk were not too many. I can imagine this might not work out for conferences with multiple tracks and / or more live tweeters. Also, doing this right after each talk meant that I joined the breaks later than others and had less time for socializing in the real world. Another trade-off to consider.

This Was TestBash Germany 2018

Here's the list of talks, linking to the awesome live blog posts from Alex Schladebeck - I can only add my sketchnotes to that! Just like last year, TestBash Germany offered meetups the day before, as well as on the evening right after the conference day. Yet again I really enjoyed these additional opportunities to have great conversations with great people. Unfortunately, however, the open space tomorrow will take place without me this year. All in all, it was once again a great conference. Thanks to everybody!

Wednesday, September 12, 2018

SwanseaCon 2018 - Celebrating One Year of Public Speaking

It's this time of the year again, the SwanseaCon time. What can I say?
This conference is dear to my heart. I am most probably biased here, so I'd like to invite you to come and judge for yourself! I'm biased as this was the first conference that accepted me as speaker. Last year, on 26th September 2017 I gave my very first session on a conference stage. Coming back this year, again as a speaker, feels like closing a circle. Even though it's already more than a year of public speaking, and only nearly a full year of conference speaking, I consider my return to SwanseaCon as a personal anniversary. Biases aside, I overheard several others that they enjoyed the event just as much.

This year the conference took place on one day offering four tracks instead of two days with two tracks. Shorter with more options to chose from can be both better and worse, depending on your personal preferences.
The good thing of a one-day experience is that it's nice and condensed, and afterwards you can celebrate all the learning with all the great people. As a speaker it's nice to relax, too, you simply can't be scheduled for the next day! Still, more tracks mean more options and increased fear of missing out. It was indeed hard to chose the most favorite talk of this year's awesome SwanseaCon program. I love the fact that it was really diverse regarding content and speakers again, just like last year. The audience was quite diverse, too! A nice mixture of local and international community, of many different roles. Lots of women around as well. My personal impression, was a good one and I perceived the atmosphere as very friendly and open.

Now what about the content? The sessions I've joined were very insightful, I learned from each of them.
  • It started with the opening keynote of Hadi Hariri: "Where's My Free Lunch?". He vividly made clear how people in today's society pay for free apps with their privacy and time, becoming more and more indifferent; just because it's so convenient. "Personalized experience" a.k.a. manipulation. It's also convenient to not contrast any presented "fact", validate it, and only then share it; we have our part in producing and spreading fake data. Hadi's conclusion: We're screwed. So what we can do? Raise awareness and think before we act.
  • Next up: Gem Hill with "Anxiety Under Test". Gem talked very openly about her mental health issues and how she learned to live with them. Companies like BBC discovered the benefits of mental health first aid programs, offering trained contact persons for people in need. There are many more places we can reach out to, Gem shared a list of resources in her slide notes. Key is to learn our individual signs of upcoming issues, and find out what helps us mitigate them. Self-care is essential in these cases. What a very hard topic to talk about - and so incredibly important.
  • An interactive workshop! That's a first-timer for SwanseaCon as far as I know, and it was great. Lisa Crispin and Kristine Corbus took us on an experiment of "Questioning requirements: improving quality for everyone". The small room was crammed with interested people! Time flew while all groups tried different approaches to come up with a first release plan for a new product, given only a few ambiguous requirements. It was great fun and we learned a lot!
  • After lunch, it was time for my own talk, "Cross-team pair testing: lessons of a testing traveler", sharing lessons learned on my testing tour.
    The goal of this talk is to inspire people to go on their own learning journeys by giving an example. An idea to take, adapt to their context and make it their own. And it worked, just like the last times I've given the talk. Right after the Agile Testing @Munich meetup Guna Petrova signed up for my tour. After CAST Alex de los Reyes scheduled a pair testing session with me, and now it was Gem Hill! Also, further people came and discussed how they could start their own experiment. This makes me unbelievably happy. Moments like these made my journey out of my comfort zone by public speaking and the testing tour so much worth it.
  • This time I was eager to give my best to not fall into my usual post-speaking state of total distraction and lack of focus but instead closely listen to Nick Tune's talk "Strategic Autonomous Design: Patterns and Heuristics". I knew Nick as great story teller, he could really engage and entertain me last year. Now, following the talk worked out well at first. But then: technical problems. The projector refused to show the slide deck. One slide was displayed, the next one not. They had to reactivate sharing, it worked for one slide, and so on. In the end they had to use another computer. Nick got constantly interrupted and it cost a lot of time overall so that he could not present the whole talk - what a pity.
  • Erkki Salminen and Mari Wuoti's talk "Culture for the win" was my last choice of the day. They shared how the culture at their company Gofore evolved. They values they have are used as guideline for everyone to decide to the best of their and the company's needs. The nearly 500 people only have one "middle manager" - a Slack bot! Culture is strategy for them, it's a lot about the mindset. Great example that you can indeed grow your own culture and related structures; maybe inspired by others but not copied and pasted into your context.
  • The closing keynote was given by Seb Rose: "Whatever your job title, you’re actually being paid to think!". Wonderful talk around his rant for the FFS Tech Conference, sharing why metaphors, acronyms, templates and models can be confusing, ambiguous and generally unhelpful - if you don't think. That's our job, we're creative thinking professionals! Seb asked everyone to not just belief him, but really think about it first and make up our own minds. Wonderful closing keynote that was fitting so well to the opening keynote.
There were several more talks I would have loved to see. The good thing: There was again a post-conference meetup hosted by Equal Experts - with great lightning talks!
A great conference ended with even more great and fun talks and long conversations with awesome people. Just perfect.

Tuesday, September 4, 2018

Testing Tour Stop #19: Session-Based Pair Testing with Guna

Guna Petrova had listened to my testing tour talk at a local meetup end of July. Right afterwards, on the same evening, she scheduled a pair testing session with me. What a wonderful feedback! We had a great time testing together.

When it came to selecting our topic, we had lots of ideas and areas we would like to dive into or improve our skills in. For our session we agreed to try an approach we've known for a long time but never actually tried out ourselves: session-based testing.

Prepare and Align

As neither of us was really familiar with session-based testing or session-based test management we had to first read about the approach. The following resources helped us prepare as well as guide us during the session.
We agreed to try this approach to support our exploration, so we needed a test target. We decided to go for the Hours time tracking web application. The domain is not unfamiliar, the product still unknown to us.

We also needed to decide where and how to take notes. As far as we could see, usually a simple text file is used which can easily be parsed for automatic reporting. For our session we did not care about the automation part, so we decided to have the sample session reports guide us, but not limit us. We wanted to create a mind map instead.

Taking the template and making it our own, in a visual way, was a great exercise in itself. We had to discuss and align which information to take over, where to put it and how to structure it in the beginning, knowing we will adapt it as needed during our session. We agreed to use child nodes along with notes on them to store more detailed information. Later during the testing session we also decided to use icons to mark issues so we could quickly get an overview on our findings.

While creating the mind map and aligning on everything, we agreed on our mission and our first charter to focus on.
  • Mission: Evaluate the web app whether it's suitable for a first time user
  • Charter: First interaction with the system, namely the
    • Web home page
    • Registration
    • App landing page & content
We noted down areas to test and session metrics. We planned to report issues and opportunities for future charters, as well as test data and tools used.

We agreed to time box our testing session to 45 minutes. We also wanted to pair the strong-style way, frequently switching the navigator and driver roles, having a mob timer support us. Finally, all agreements were made and we felt ready to start our session.

Time Flies

We started testing, tackling the very first contact point of most first time users of Hours: the web home page. If we would want to evaluate the product, this is where we would start to learn more about the application and create an account.

We found several issues already on this home page. We frowned upon lots of things we would not have expected. We also found praise! We took note of all these findings in the report section of our mind map. Besides that, we also stored details on what we tested in the notes section of our charter. I wondered whether I really would put down so many notes myself (I normally don't). The benefit I saw was that it would definitely help tell the testing story in the end when discussing findings. Guna added that this was also proof what we did, it felt safe to do it, especially in situations were you needed to show evidence of your testing.

Our mind map evolved quite naturally. We discussed and aligned ourselves. Suddenly we realized that not much time was left and we were still on the web home page, not even close to the other parts we wanted to look at. We decided to keep it with that, and still we went overtime. We tested for 55 minutes and therefore exceeded our time box by 10 minutes.

Debrief!

In session-based testing the session is debriefed right afterwards. We agreed to not use questions of the offered debrief checklist, but try the PROOF approach of Jon Bach.
  • Past. What happened during the session?
  • Results. What was achieved during the session?
  • Obstacles. What got in the way of good testing?
  • Outlook. What still needs to be done?
  • Feelings. How does the tester feel about all this?
This felt pretty fast and easy, straightforward, and indeed helpful. Mental note to myself: Do debriefs more often for your own testing; you might learn a thing or two.

Looking Back

In retrospect, both Guna and I liked our session. It was great to try something - together. It's way easier this way. As Guna put it: She wouldn't do session-based testing alone. Cassandra did it alone and struggled. But together it provided value. It's not a bad format.

What I liked about our approach was that we took the format and template, tried to understand the essence and then transferred it to a visual mind map, thus making it our own and adapting it to a setting which might be useful in our everyday life. Guna said documenting testing and findings like this seemed to be a neutral way to not force your own style on the other person. It felt great for multiple people working on the same stuff and it was a good reminder that there's more to consider for testing sessions.

Regarding our strong-style pairing, Guna offered interesting thoughts on it as well. We had to communicate and align ourselves. Whenever we felt we were not aligned, we explained why we would want to do this or that. We had to hold back sometimes, especially when we wanted to bring up something but it wasn't our time yet. These cases were the only time she noticed the pairing part. Besides that we were still having a natural conversation and flow. Her conclusion: we should do more pairing. I agree!

Monday, September 3, 2018

Testing Tour Stop #18: Mob Exploring with Amitai and codecentric

This stop on my testing tour was really special. Why?
  1. I saw Amitai Schleier again! We had read each other's tweets since longer and first met in real life at the Mob Programming Conference 2018.
  2. Amitai went on a coding tour this summer, joining several companies for one week each to learn together (find more about it on his blog). Most of the tour happened to be in Germany, and the last two days in Munich at codecentric. He knew about my testing tour and imagined us to have a common stop in my home town.
  3. We mobbed. My original hypothesis for my tour was about either pairing or mobbing, however, I only had the chance to pair before.
  4. The people on the mob identified as developers and had no experience with exploratory testing. My tour was about learning from testers, still, this promised to be interesting. I did not join the mob myself but stayed the facilitator. Though my tour was about hands-on testing, with me included, I learned a lot about teaching testing.
  5. My previous stop with Simon Berner was about pairing and mobbing itself. Only a few days later I could put our exchange into practice!
At first I saw this session as guest visit on Amitai's coding tour. Amitai, however, wished for counting it as stop on my testing tour as well. Even though I was not on the mob myself, this indeed felt like a bonus stop on my tour. So be it! :)

Setting the Stage

Amitai and Thorsten Brunzendorf already welcomed me at the entry. We had a nice chat, set up the room intended for our mob and waited for interested people from codecentric to join our session. They came, and even brought a test target we could use where they would value feedback on. Great, I really like to have our sessions to not only have the training effect but also have real-life impact.

After Amitai and I introducing ourselves and sharing some words on our tours, the session started. I decided to have a short introduction round in the mob as well, asking them for their name and core expertise. I knew everybody was identifying as developers, however, it was still very interesting to hear the different backgrounds, interests and specialties. Some people were into DevOps, some preferred backend development, or even tended towards security testing. I was pleasantly surprised to hear most of the group already had mob experience, only two persons didn't. After giving them a short heads-up, I went over to introducing testing, and especially exploratory testing. I presented my preferred definition by Elisabeth Hendrickson, as well as her charter template that I find useful especially for people new to exploration.
"Simultaneously designing and executing tests to learn about the system, using your insights from the last experiment to inform the next."
"Explore (target)
With (resources)
to discover (information)"
(Elisabeth Hendrickson, Explore It!: Reduce Risk and Increase Confidence with Exploratory Testing)
I wanted to keep the basic theory short and have people learn by hands-on testing as soon as possible. I asked the ones who provided the test target to shortly introduce it and afterwards asked the mob to write their charter. They, however, were really unsure what they wanted to focus on as they felt they didn't know the product well enough yet. So I decided to have them do a recon session for the first rotations in the mob, mapping out the system. I also recommended to already jot down notes together as a mob, for example in a mind map. And off they went!

Let the Mob Explore

It was really interesting to observe this mob explore a product most of them saw for the first time. They were unsure about their procedure, trying to align themselves as a group. They jumped all over the place, already finding great issues; not taking notes of them. They started a list of assumptions and wishes they had for the product. And they shared lots of implicit knowledge with each other, just as I have witnessed it in so many mobs before.

After nearly one full round of rotations, I had them stop. I shared some of my observations and provided recommendations. I also asked them whether they now felt ready to write a charter so we could do more focused exploration, using a simple Roman vote for quick decision making: thumbsup - I feel we're ready, thumbsdown - we need more information, thumbs sideways - not sure which way to go. Half of the group voted up, half sideways. I could have used the mostly positive result to have them write a charter now, but decided to have them finish a full round of rotations before asking again. Now all thumbs went up! Chartering didn't come easy to them. I helped them through, trying to not enforce my own suggestions or opinion. They managed to come up with a first charter to start with, providing them the needed focus. Interestingly, they decided to explore user experience with the help of the source code! That promised to be interesting, and it was indeed.
  • They used the code as oracle - great.
  • They looked for existing unit tests - nice.
  • One person shared: "I still don't understand the test, can you shortly walk me through?" - liked that.
  • They fed different values to unit tests, in an attempt to use it for exploration - awesome! Unfortunately, they did not follow up on it, or left a remark for future sessions.
  • They said they should also test the feature from user perspective - exactly! It might be the code they saw was actually never executed, right?
Towards the end of our mob session they started a discussion of whether a certain feature was useful at all. They brainstormed ideas how a different solution might be way more valuable to the user in the end. They questioned the context the product might be used in. Many great points were made.

Retro? Debrief, Discussion, Feedback

On my testing tour sessions, I normally do a short retrospective in the end so we can learn how to improve (I learned their value on my very first stop with Maaret). This time, I did a debrief of the testing session with the mob instead, to have them reflect on certain aspects. It proofed really valuable to get them thinking about what they did. Mental note to myself: I should do that more often for my own testing as well.
  1. What was our mission?
  2. What did we test and what not?
  3. What did we learn?
  4. What feedback can we provide about the product, can we quickly derive it from our notes?
  5. What to focus on as next highest priority with the knowledge we have now? 
The response on the last question was my personal favorite. They wanted to talk with the product owner as next step to see if they were going in the right direction or whether other areas might be more risky.

After a short closing, the mob session was officially over. Still, the group stayed and started an informal discussion. One of the persons who proposed the test target now shared that he didn't want to spoil the session, but the tested product version was outdated already and they had indeed agreed to remove the challenged feature - so the mob's feeling was indeed correct here!

It was great to hear people's experience with testing, mobbing and knowledge sharing. I really enjoyed the conversation to conclude a great session. Afterwards, Amitai shared personal feedback with me. He said he could clearly see I did these sessions very often already. This feedback took me by surprise. I had facilitated several mob sessions since beginning of the year: three in my company, one at a meetup, and three at conferences. So this session had been my eighth only. Amitai shared it was received as really professional and it was exactly what he was hoping for. This showed me I had learned a lot and it also triggered me to reflect. The session had indeed felt good. Maybe because I taught developers new to exploratory testing? Would it have been the same in case they would have been other testers? Still to be answered. This I know for sure: I had shared a lot about testing and testers during the session while people were doing hands-on testing. The mob approach is just an awesome way not only to learn but also to teach testing.
Bonus: Amitai also shared what he learned on his blog as well as recorded a conversation with codecentric sharing their highlights from this stop; including my exploratory testing session! :D

Sunday, August 26, 2018

Testing Tour Stop #17: Pair Evolving a Mind Map about Pairing and Mobbing with Simon

On my latest stop on my testing tour I had the pleasure of pairing up with Simon Berner on the topic of pairing and mobbing.
We only had contact via Twitter before. It's always a great experience to put a real face to this sort of virtual connection and have a meaningful conversation with them.

Going on a Meta Level

Simon put a lot of thought into our session already in advance and proposed our topic as follows.
Hi Lisi
There are so many great things out there that I would like to discuss and explore with you, but so little time. I have something specific in mind where I know little about yet: to Mob. As you seem to have quite some experience around this topic, I would love to pair up with you on the topic of “to Mob” and elaborate a bit on it, if you are up for it. What are our experiences with MobTesting and MobProgramming in general? What are its benefits? When can it be applied best, when not? Are there different forms of it? Can a whole Sprint-Iteration completely be developed in a Mob? How can you introduce “to Mob” to a team who knows nothing about it? How do we learn best from its outcomes? … and many more interesting questions to discuss.
My intention in this session with you is, to create a MindMap where we both can share ideas/experiences and grow up on it (maybe me a bit more than you as you seem to be already a pro on it)
I’ll create a MindMap in advance with some of my ideas around the topic, so that we can get started on them.
Hope that sounds interesting to you
Cheers
Simon
If that sounds interesting to me? Indeed it does a lot! Our session could only last that long, but I'd love to continue the conversations around it.

Now, originally my goal for the testing tour was to practice testing hands-on. I read and talked a lot, but felt I didn't practice or try out new approaches and tools enough. In this sense, this pairing session was a bit different, as we had a paired conversation around a certain topic. Still I was eager to give it a try, betting there's much to learn out of it as well.

Evolving a Pairing and Mobbing Mind Map

As promised, Simon already prepared a mind map. And it was huge! It contained most of the things already, so it was great to get our discussion started, elaborate on certain points and develop it further. As words cannot express what mind maps can, let's start at the end and show you our end result. I decided not to edit it after we stopped, so this is exactly as we left it. The original file which allows to follow the links can be found here: TestingTour_2018#17_Pairing&Mobbing.xmind.
I really enjoyed that Simon thought of including an "introduction" node for us to get going. After all, we didn't know each other and this made it easier to start and learn one or two interesting bits about each other. This way, I got to know that he just started in a new team with huge potential where he's the only one to drive things forward regarding testing and collaboration. Simon already pairs with his teammates and now got intrigued to try the mob approach as well.

We talked a lot about styles of pairing and what comes with them. We both enjoy and prefer strong-style pairing the most. When it comes to explaining this form, I normally shared this blog post by Llewellyn FalcoLlewellyn’s strong-style pairing. Great to see Simon had it already in his mind map. And he also had the following post by Maaret Pyhäjärvi right next to it: Being a navigator in Strong-style Pairing. I really enjoyed reading it afterwards, as well as her previous posts in this mini-series The pairing experience: foundations and Being a Driver in Strong-Style pairing. (Update: Maaret just compile an article from her notes on strong-style pairing: The Driver-Navigator in Strong-Style Pairing; my new favorite post to share.)

Simon shared that when it comes to understanding the roles of driver and navigator in strong-style pairing, the metaphor of the rally driver and navigator was enlightening to him. When driving a rally, the driver has no time to read the map or think about what else to consider, they are fully occupied with getting them there. It's up to the navigator to take care of directions and instructions and thinking ahead. This metaphor was flipping the switch for him.

Another interesting point Simon made was that "listening is an art". I so much agree! Especially when he shared his observation when meeting people. He's interested in people and the one asking questions about the others. People have a tendency, however, to tell you about their lives and then not ask in return to learn who you are. I made this observation myself so many times as well. However, I also fell into the trap of the other side so many times already, being guilty of not asking back myself. Best example was when I was speaking at a conference and someone approached me asking questions, I was really happy I could talk about things I love for once and not only listen to others, so that I often forgot to ask back. Another factor here is that exhaustion makes it worse as Simon added. When I'm tired, I fall back into my worse habits and less social behavior.

Another interesting discussion point was what to do when you see that people are falling back into a traditional style of pairing, having the navigator take over control of the keyboard again. We both experienced these kind of situations already which can be tricky to solve. I realized that I personally grew with experience, so when I am the driver, I won't allow my navigator to take over. It's really hard for me, however, to be on a mob and watch the driver freely handing over full control to the navigator. I normally intervene, referring to the learning aspect for both. Sometimes this is helping people find back on track, sometimes my voice is not heard. Now, the worst thing is if I'm myself the navigator (maybe also tired) and have to actively stop myself and refrain from taking over. At least it's fully in my hands to stop it then.

When focusing on mobbing, we quickly came to the question how to introduce it to a team and tackle the likely question regarding productivity. I referred to a great keynote by Woody Zuill at the Mob Programming Conference 2018: "Mob Programming and the Power of Flow". Unfortunately this talk cannot be found online, however you can find my notes about it in my blog post about the conference, and Woody's webinar Enhancing Team Effectiveness with Mob Programming seems to be sharing about the same content.

In a mob, it's important how we treat each other. Kindness, consideration and respect are the often-shared ground rules for a mob. Simon and I felt "kindness" is kind of straightforward, and "respect" understandable as well; "consideration", however, is not as easily graspable. I admitted I had to look this one up the most often before explaining it to a new mob. I explained it with being aware of the others and their context and considering that everyone's doing everything to the best of their knowledge. And instantly admitted I would love to look it up again right then to see if that's correct. Now that I have written this down in this blog post, I really went back to the Mob Programming Guidebook and looked it up. And found that once again I indeed mixed "consideration" up with "respect"!
"Consideration is really about listening. [...] The place it is going to show up the most is at the driver seat. Often the driver will start by not listening to the navigator. [...] Another way that this will manifest itself is that good ideas will be spoken by members of the mob and will be totally ignored. [...] As a facilitator, it is your job to call attention to those ideas and make sure that everyone gets heard. Over time the mob will learn the habits of listening to everyone and people will find their spots to contribute. [...] Another aspect of consideration is to remember to allow other people to shine. [...]
[Respect:] We always assume that the person who wrote the code before us did the best they could with the knowledge and circumstances they were in at the time they wrote it. [...] We want to create a space that is safe."
(Maaret Pyhäjärvi & Llewellyn Falco: "Mob Programming Guidebook" version 2018-03-24, chapter "Working in You First Mob", section "The Rules for Working with Each Other")
The next interesting topic was the size a mob should have and when it stops working due to the number of people involved. I learned that three persons already form a mob, however, if one leaves the mob for a break you are back in a pair. Therefore, a minimal size of four people is working out really nicely. When it comes to the maximal size, the general idea that I picked up was that the size of a mob is still right when everyone's either learning or contributing. If you have a normal-sized agile team it's perfect. I heard from two team mobs temporarily joining forces in a bigger mob, or from people trying a mob with a full meetup group. So far I still made good experience with a mob of ten people myself.

We were running out of time and still had many more topics on the mind map. So I asked Simon what would be the last most valuable topic he'd love to have input on before trying to mob with his team himself. Simon wanted to learn about the "don'ts" in a mob. Two points came to my mind instantly.
  1. Don't force anyone into the mob. If they are not willing to give it a real try, leave them out and only do it with the people who want to. Make it fun so they might want to join in next time, as I learned from Maaret. In my team's case, the two most skeptical persons who did not want to be on our mob either changed team or the company soon after, so I cannot tell from experience how it might have evolved with them. Still, we cannot force people, only convince them.
  2. Don't force anyone to stay in the mob. Besides from the very first mob sessions, we made very good experience with allowing people to take any break they need and temporarily retreat from the mob. These can be as simple as toilet breaks or getting some water, with them being back on the mob very quickly. These can be meetings that just happen to take place at the same time, like a one to one with our manager or an interview. These also can be times people need to fall back to solo working mode and tackle other tasks they have. With this rule we made it easy for everyone to opt in and out, and the result was we were even longer together in the mob. Just the freedom was needed. And the coffee breaks? Since then we nearly always do them together, staying synchronized, and having that extra bit of socializing that helps so much when working together.

Retrospective Time

Simon shared it was a wonderful experience for him, joining me on my testing tour. He was nervous in the beginning as we didn't know each other (just like me always!), but it turned out to be a cool session. He also got a lot of information and value out of the session, which I loved to hear. He didn't think we should have improved anything in our session, as a lot depends on the energy flowing between two persons and ours was great.

I really enjoyed our discussion and the additional food for thought when it comes to pairing and mobbing. The preparation work Simon had put in already in advance was simply awesome! So much more to dive deeper into, lots of resources new to me. It was really interesting to try strong-style pairing on such a meta level topic, evolving the mind map with our results together. Because this is what we did! We used a timer and switched roles, however, for this kind of a topic it was quite hard to do and we often lost discipline. Still, both of us could contribute and learn. Simon made a good point here: it's the natural flow that matters, we don't have to force people into a box. It was as if we would have done it before.

All in all, it was once again a pleasure to pair up with great people of our wonderful community. There's so much to learn from them, to give back, and to discover new insights together.

Monday, August 20, 2018

CAST 2018 - A Community Adventure

Two weeks ago, I had the great opportunity to be part of CAST 2018, taking place in Cocoa Beach, Florida. I had heard great things about last years' events, and indeed, it turned out to be yet another wonderful conference!

The theme was "Bridging Between Communities", a theme I really loved. It is great to exchange experience with other testers working in a similar context. It is also great to share knowledge with testers working in different ones. And it is great to learn from people who do not identify as tester as well! Maria Kedemo was program chair and created a wonderful offer. It was really hard to pick a session and I would have loved to go to each and every one of them. Thanks a lot for the diversity provided.

Organizers in general were great and really supportive. Together with their volunteers they did a great job! I felt very welcome, communication was easy, and facilitation and support during the conference was awesome. Especially as a speaker this part is nowadays really important for me. Though we had some short-term changes in the schedule or regarding rooms, everything went smooth and without major problems.

Getting to a conference as speaker is a great thing for me in any case. It's not only that I get the chance to share my experience and give back to the community from which I received so much myself, or that I receive the opportunity to level up my presentation and training skills, but also that I learn so much from these conferences myself. I learn as an attendee, I can reach out to fellow speakers way more easily, and I get approached myself by other participants myself. As I identify as introvert at heart, this helps me so much to connect with people and learn from them. Thank you for making it so much easier for me.

At CAST 2018, there were so many wonderful people with whom I enjoyed many insightful conversations.
  • Lisa Crispin. I consider myself really lucky that we had so many opportunities over the last year to meet and exchange thoughts. I enjoy all our conversations and am already really happy that we are going to meet again at three more conferences within the next half year!
  • Marianne Duijst. Thank you for listening, for providing constructive feedback, for facilitating the questions for my talk, for your most wonderful sketch notes, and last but not least for spending a full day with me after the conference doing awesome touristic stuff! I am so glad I got to know you.
  • Ashley Hunsberger. It was such a great coincidence that we had a first call just a few weeks before CAST! It was even more lovely meeting you in real life, and just picking up things from where we left them. Thanks for the evening spent talking about anything and everything.
  • Lena WibergTomas Rosenqvist. It was fabulous to meet you in person, and that even already on the plane to Orlando. Thank you for sharing your experience. You gave me so much food for thought!
  • Angie Jones. Finally I had the opportunity to join one of your tutorials! It was great. Even better was the opportunity to talk with you. Thanks for making it easy, as well as for your feedback! :-)
  • Amit Wertheimer. It was great meeting you again, I really enjoyed our deep conversations on so many topics! Already looking forward to the next chance.
  • Jan Eumann. There are still not too many people who already experienced mob programming, mob testing, or mob anything. I really enjoy sharing thoughts with those who did! Even greater considering the fact that we now submitted a proposal for a mob session at another conference together.
And there were so many more lovely people! Maria KedemoLouise PeroldAnne-Marie CharrettJenny Bramble. Richard Bradshaw. Alex de los Reyes. Bailey Hanna. Many more great persons with whom I loved exchanging knowledge during tutorial, workshops, talks, lunch, or a bus ride.
If you came that far in my post you might think this conference was all about people. Well, I think conferences are indeed about the people, just like software development is. Still, those people also shared great content. I learned a bunch again and took several ideas with me back to work. Here are my highlights of each conference day I attended.
  • Tutorial day. The tutorial "Advanced Automation for Agile: UI, Web Services, and BDD" by Angie Jones. She taught everyone how to create a well designed automation framework, shared her experience, demoed what she told, and made sure everyone shared the same page. At times I perceived the pace as slow, yet "slow allows for thoughtful thinking" to quote Maaret Pyhäjärvi. It felt good to learn that I know more than I thought I would. That I could easily follow and still had time to help others, and was able to do so.
  • Conference day 1. This day is tricky, as I had two favorite sessions. The workshop "An Exploration of Observing - Creating system awareness in our quest for quality" by Louise Perold was great to practice our observations skills hands-on and especially debrief what happened and what we perceived. And the talk "Risk Based Testing: Communicating Why You Can't Test EVERYTHING" by Jenny Bramble was so entertaining that I even forgot that I was next! It also made obvious how important communication, talking about risk to guide our testing, and team morale really is.
  • Conference day 2. Finally I could hear Marianne Duijst's talk "Wearing Hermione’s Hat: Narratology for Testers". Learned a lot about biases, perspectives, trust when it comes to information, as well as enabling others. It was simply awesome. If you get a chance to hear it, take it. It should have been a keynote for everybody to hear.
Well, and I also had two sessions myself. I gave my brand-new talk "Cross-team Pair Testing: Lessons of a Testing Traveler" for the first time at a conference, speaking about my testing tour. Although my timing was not working out well enough, it seems people did not notice and still felt it to be consistent. After the talk, there was a facilitated discussion which I really feared in the beginning - but it went well and people asked many great questions so we could dive a bit deeper on the topic. And the best thing: Alex de los Reyes came up to me after my talk and told me that he really related to it, shared my fears and wanted to pair with other testers for some time himself already. Now my talk was finally the trigger for him to actually do so! Amit Wertheimer instantly joined in, and both agreed to have a pair testing session. How awesome is that?! It seems more people came out of my talk inspired. That was my goal and I am really happy about this kind of feedback. What more could one want?
In addition to my talk, I gave my workshop "Mobservations - The Power of Observation in a Mob". I had less time to prepare myself for it as expected as schedule slots were swapped, so I felt less energized and the session less organized as it could have been. Still it went out okay, people got value out of it, and I also received constructive feedback how to improve it further. As Louise Perold shared with me, workshops are never perfect, they can always be improved. And they depend also on the people you have and your skills to adapt to them and the context.
In conclusion, the people were great. The conference was great. And then also the social activities around were great! For example, the sponsors enabled most of the people to visit Kennedy Space Center where we all had dinner together. What a location for that!
As a bonus: there were two rocket launches around the conference dates - who can say they offer that?!
Last but not least: I have the most awesome team ever.