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.


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.


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.


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