Monday, September 18, 2017

A Long Story Cut Short - The Importance of Pausing to Think

Today was the day. My team released a huge epic introducing major changes in our application. Normally, we release many changes during our daily release slot. However, this release was unusual in itself, and it taught us a bunch of important lessons.

We started working on the epic on July, 11. As we had discussed the topic several times before, the whole team felt that we had a shared understanding and were ready to go for it. During the first two weeks only one developer focused on the topic, and gained first insights on how complex it actually was. He raised the issues he was facing and called for support, especially as delivering this epic was our highest priority. We decided to have the whole team step in and share the work load. We still highly underestimated how far this would go - or rather, how far we would let this go.

The whole team, meaning five developers, our product owner, our agile coach, and me as tester delved into the topic. And together, we gave birth to a monster. With every little change the whole solution got more and more confusing. It was incredibly hard to figure out what was expected and what was unexpected behavior, and especially how we would ever be able to understand our implementation in the future again. And by "future" I mean half an hour later. Everybody was having a hard time. Nobody was happy with what we did. The amount of curses increased rapidly. We all felt we would soon go insane. One teammate even suffered from nightmares and sleepless nights. We are really not proud of this tragedy, but this should give you a pretty good idea of what was going on.

Desperately, we discussed again and again if there would not possibly be any other way to fulfill the business need but also enable ourselves to keep our application maintainable, extendable, and last but not least testable. However, our discussions turned in circles. So we pressed on with implementing the epic, eager to get to a minimum viable version for which our product owner would let our users access our test system to get their feedback.

The fun fact - or rather really sad truth: As soon as we were ready to start the user acceptance test, one developer took the time to create a completely new prototype, based on a totally different assumption. And after only half a day, on August 30, he was ready to share his new approach with the team, to have them challenge it and find flaws in his thinking. We were stunned by his simple approach. We raised some questions, but couldn't find any reason why not to go with it. By only doing one thing differently, everything else became a lot less complex. Comprehensible. Consistent. Doable. With way less effort and way less changes in our application. What he did? He threw a convention over board which everybody had considered as a fixed precondition. You know, as soon as you have to handle x, everybody strongly recommends to do y to avoid problems. We had never challenged this assumption we had in our heads, all of us had accepted it as a given. But in the middle of implementation, it turned out that this convention made everything really bad for us. Neglecting the convention instead was fitting way better in our context, from business perspective as well as technical point of view.

Shame on us that we had to go such a long and winding road of learning how not to do it. Nobody had put pressure on us but ourselves, not our product owner, not our agile coach, not our stakeholders. We ourselves were driven by the thought that we have to get this done and finished as soon as possible, making us pressing forward without taking time to actually think and experiment early. The team even "temporarily" discarded our rule to stop starting and start finishing, meaning that all developers continued to start working on new topics before former ones had been completed. Unsurprisingly, this created lots of bottlenecks and context switching, making the whole situation even worse. And as soon as one of us felt we have a bit of time to breathe again - he found the clean solution.

To cut a long story short: within a few minutes of discussion, we wholeheartedly threw away our first implementation on which we had worked for nearly two months by common consent, in favor of this new and easy approach which we in the end fully implemented within about one week. After going through all this, we couldn't but ask ourselves in retrospect how this could have happened and why by all means it took us so long to challenge our assumptions, learn, experiment, and see the solution. But in the end we did learn the following.

Conventions are recommendations but not carved in stone; they might not apply or be a good fit in your context. Think outside the box (that you might have created for yourselves) and experiment early with different approaches. Don't get so busy that you cannot pause, breathe, and think. And last but not least: Don't be afraid to kill your baby, especially if it turns out to be a monster.

Bonus read: By coincidence or not, when thinking about publishing this story I came across the post On Real Options and Speculative Investments by Liz Keogh which nicely reflects many facets of our story. Besides the fact that I really relate to the core messages, it's a highly recommended read.

Monday, August 14, 2017

Thoughts about Awesomeness

To be frank, I hesitated to write this post. I still wrote it because I think it is an important topic. I feel the need to document my current thoughts for my future self and to share them as a basis for discussion. The following reflects my non-expert, non-scientific impression of things. My personal thoughts of today will evolve as I learn more. This post got quite long, but please bear with me and read to the end.

At Agile Testing Days 2016 a Women in Agile Summit was hosted. To be honest, when I read about it, I was taken aback at first. Why would a women event be needed? Why excluding men and everyone who's not comfortable with this binary classification? I felt that making something gender-specific was not the right approach. I am not considering people for their gender first. We're all humans, right? We're having many different identities. In the end, we're all individuals. So I'd rather strive for equal chances than supporting women over others just because they're women; strive for diversity in all means, not only gender. It simply didn't feel right. It still doesn't feel right. But I might be thinking a bit too naive about the topic. Back then I finally decided: Well, I am a woman, I'm working in an agile environment, so I should attend this event and check out what it's all about.

At the summit, I joined a lean coffee session with several women coming from South Eastern Europe and Germany. We exchanged our experiences regarding gender issues at our work places. The German women saw things just about like me: well, there's no real problem anymore. If a few more women would join our teams, that would be great. To attract them, maybe we could advertise more that we're having an open and safe work environment. Right, and there's probably still a salary gap, but it appears to be closing more and more. Besides that, we didn't encounter discrimination due to our gender yet - well, at times some positive discrimination. But so far so good, we're getting there.

And then we heard the women coming from South Eastern Europe, telling us way different stories. Stories of women having to justify constantly why they are having a "man's job". Tales of women who learned that they had to show bossy behavior to get accepted by their male colleagues, and of others having to use their charms to survive in tech. Those women reported about struggles which never occurred to me. Naive me, to be sure. So, slowly but steady I realized that this topic is not at all out of date yet. For another view point I recommend reading Maaret's wonderful blog post about the summit. Personally, this event triggered me to be more aware of the topic.

The next thing that surprised me came early this year. I had submitted papers for Agile Testing Days 2017, so I followed their news about the submissions. When the call for papers statistics were published, I was really surprised.
29% of papers had been submitted by women speakers. One of my colleagues was positively surprised how high the percentage was. I, however, was rather disappointed; I would have expected that figure to be way higher. I mean, it was not about getting accepted at the conference, it was only about submitting. Why would less women submit? Does this only reflect that there really are way less women in tech overall? Or is there another reason?

Nowadays, again lots of discussions are going on regarding women in tech, minorities in tech, anyone in tech. Probably the most prominent example right now is the manifesto of a male engineer internally published at Google. I won't address the topic here, it has been discussed at length already.

Instead, I'd like to share another story with you. End of July, Ashley Hunsberger raised awareness of the following post.
It was quite commonly agreed that this kind of list rather served as marketing campaign than represented reality. On the one hand there were more women experts in test automation to be named and on the other hand same listed men seem to not match the profile at all. When people started to list further women, I found myself named as automation expert as well. Not my biggest strength, but people even started to follow me due to the mere fact I was added to the pool!
Shortly before that tweet, I had the honor to be invited to the Women in Testing Skype/Slack group, a group from and for women in the testing community (if you want to join, I can invite you, just send me a direct message via Twitter). As a reaction to above post, Anne-Marie Charrett came up with the idea to create our own list of awesomeness. The intention? Show the world that there are way more women in testing that could have been on a list. Way more that could get invited to speak at a tech conference. Way more to follow and get to know. And even way more who are not so publicly visible but worth being public.

Within very short time, we had a document with over 100 names on it. I could only contribute marginally myself; however, I was feeling so honored when realizing someone added me to the list as well. Even while creating this compilation of awesome testers, we felt how great it is to see who else is out there and which topics they're into so everybody could reach out to them more easily. We wanted to get this list out to the public. Agile Testing Days agreed to support and published the list on their blog.

The blog post leaked a few days before official publication date, and the reception was already overly positive and welcoming. I was even asked whether we also had a related Twitter list. Great idea! So we created it: Unfortunately not all women named have a Twitter account, but most of them do. The list is still growing as the Women in Testing working party is still adding to it. So look out for an updated version!
Side note: I would love to have gender, ethnic groups, educational backgrounds, or anything to be ignored and have a real diverse list of awesome testers compiled. The mere need of an all women list sticks in my craw. However, I found that sometimes support is needed to increase transparency and to point out issues. Also regarding my own biases. Just compiling this new Twitter list made me realize its difference to a personal Twitter list of awesome testers I created a while ago. Judging from the 70 testers I listed, I was aware of way more men (47) than women (23) in testing myself. I'll definitely have to add more women there as well. Well, every list is wrong in some way. Still, we can use them as a starting point and as a basis to trigger discussions.

In the end - there is no end to the topic yet. In my company, we have many awesome women. We also have many awesome men. We have colleagues from many different countries and cultures. I think (and hope) they had not been hired because of their gender or identity, but simply because they are awesome. Maybe we're still too similar when it comes to our education or work background in order to gain from actual diversity - worth finding out. Also, I'd like to further encourage hiring less for skills but rather for learning mindset and team spirit. Everyone deserves a chance to show that they are awesome in many different ways, and they deserve your support to grow their awesomeness.

Tuesday, July 25, 2017

How My Colleagues Made My Day(s)

Yesterday I returned from a one-week vacation and my colleagues already made my days.

The first thing I noticed was how well and naturally my team took over testing during my absence. All stories had been thoroughly reviewed and released. The board looked awesome, only a few topics were in progress. The only thing left for me was to thank my team and tell them how much this support was appreciated and how they helped me return to work without stress.

Then a colleague approached me, asking me how things were going, how the preparations for my upcoming conference talks were coming along. I shared that I was in the middle of it and that I was getting a bit nervous already, and then she gave me this:
I was really blown away! This was so unbelievably nice of her. My new unicorn found its place at my desk and will now always remind me of her belief that everything will work out well. Hopefully it will also trick my own brain into believing this myself.

My next highlight was that a teammate called a spontaneous mob to work on an especially tricky story and get through bumpy terrain. Not sure if he knows it, but I love it when we sit together with the whole team to find a great solution! I found that I always learn so much personally. I'm so happy that the team really accepted the idea of mobbing as a valid and productive development approach and that they call mobs themselves in case they see the need for support of the full brain power of the team, or the value in sharing knowledge. I initially triggered mobbing as experiment; nowadays they do it naturally, even if I'm not around (like last week when I was on vacation). We had a hilarious time hunting down a bug - until we finally realized that the implementation was working as expected, only our verification procedure was incorrect.

And last but not least, I had a very special insight today. Our last sprint ended and the next started. During the retrospective we did a temperature reading, asking all team members to rate the last sprint from one to ten, with ten being the most awesome sprint ever. Afterwards, we shared our thoughts why we didn't rate it a ten and what we would need to do that. Personally, I loved our collaboration, so I rated it a seven. The missing three? Well, I shared with my team that I was disappointed with my own performance during the sprint, or rather the last two sprints (not counting vacation time). I love my team for their support when it comes to stepping in and helping with testing. But the last weeks I had the impression I had to "use" their support too often as there were so many open topics to follow up on my desk. Many topics regarding my product team, many topics regarding our company's agile testing community, and also topics for the overall tech organization itself. Topics that I see as part of my tester role, topics I could not easily hand over to volunteers, topics that were important and some urgent as well. And, I admit, also a few topics where nobody took the initiative; which triggered me to take care that they are taken care of. So, having to ask my team several times for support left a bad impression in my head and triggered thoughts of "I'm not fulfilling my job," "My team will start to ask why I'm even here," and other self-destructive stuff. Rationally, I realized that I accomplished many things in the last weeks, but still those thoughts were starting to creep up and I just wanted to let them know about this. I assumed that I felt like that because so many things are going on in my life right now. The preparation for my conference talks is creating a lot of work in my free time as well, especially as the first test runs are coming up so that now I'm really feeling the pressure to deliver.

In response to my thoughts, the first teammate shared that he knows these issues himself. He wants to focus fully on his job and give his best there, so his strategy is to only do that and say no to everything else. And if some things are not taken care of - well, they're not taken care of. He said that this works for him and he can't tell if it would work for me as well. I really appreciated his feedback and effort to help me. My problem here: I feel I only do things that I see part of my job. I know that as a tester it's not unusual to have many topics on your desk. Normally I can cope with them well, but it's simply a lot these days.

And then another teammate spoke up and made my day, if not my year. She said she doesn't see any problem with my performance and everything is working so well. That I make a huge contribution to the team and she couldn't see how it would run so well without me. That she can come to me any time and ask me for support with any topic, whether product related, or company related, or anything, and that she knows that this takes time as well but that I'm always so friendly and helpful. That everything's fine and I should just take it easy. THANK YOU! This was the support and encouragement I needed so dearly at that moment. So much that I decided to share this story with the world; not because I want to brag about it, but to share it with those people out there having similar thoughts at times, to encourage them to open up so they can find support as well, and to ask all those who happen to be on the other side to provide this support themselves.

To my colleagues: Every one of you made my day(s). Thank you all.

Thursday, July 6, 2017

About Crazy Days and Rope Bridges

On some days I fully focus on discovering the unknowns of our product, in close collaboration with my teammates striving to deliver value to our users.
And on some days I mainly work on company-wide topics like workshops, recruiting, or organizing meetups.
Some days are extraordinary, like going on a two-day offsite and building a rope bridge over a gorge. We had a team of talents coming from very different backgrounds who never worked together before. Still, we had fun, did a great job and learned a lot for our everyday work.

On some days I have so many tiny tasks and topics to follow-up on my desk that it's hard not to feel overwhelmed. Time just flies by.

On some days my team forms a spontaneous mob and I find myself learning a lot, but also contributing my perspective. On other days I work a lot in pairs in different constellations. Love those highly collaborative times.

On some days I hop from meeting to meeting having hardly time to follow-up on agreements, and finding myself wishing to not have accepted so many meetings in the beginning. But mostly they were important and valuable; and if not, we realized we have to make them so.

And on some days I extend the day to have dinner with my team or go to local meetups, to have a good time with awesome people and great conversations.

To be honest: I like the kind of days where I can fully focus on the task at hand the most, when I don't have to switch between too many contexts. But even though I plan for those days, I learned that plans are just plans and reality might be different. But that this is totally fine as long as I work on topics that provide value. Even better if I work on those that provide the highest value first.

Within the last three weeks I encountered all kind of days described above. Some have been crazier than others, but none of them were wasted. I have the freedom to decide myself on what to work on. So for me, it's about finding the right balance of how to use my time to achieve the best overall outcome, trying to do less in order to focus on what actually provides value.

Sometimes I excel at the right balance. Sometimes I fail miserably. As long as I learn something every day so I can improve myself and my surroundings, I'm fine. Every day is different, but never boring.

Sunday, June 18, 2017

Our First Take On BDD

Most probably you came across behavior-driven development already. But what is behind this term? What is at its core? How does it benefit a team?

Years ago I read a lot of blog posts about BDD and was intrigued to experience it myself. When starting in my current team, I began to spread my thoughts about trying BDD to see if this approach would help us. It took quite a while, but finally the team agreed to give it a try.

So here we are. We started experimenting with BDD and had our first Three Amigo sessions to kick our stories off and create shared understanding before starting implementation. We had our product owner on board, the developer who pulled the story, and me as a tester. We talked about the scenarios we see and discussed concrete examples. We raised questions and discovered unknowns. We decided what's in scope and what might follow later or never. We captured our thoughts as conveniently as possible, be it using Gherkin's Given-When-Then syntax for scenarios or any suitable graphical visualization. We decided on which scenarios to automate, on which level to automate them (mocked, through API, or through UI), and which scenarios to leave for manual exploration only.

Right after our first Three Amigo session, the developer told me how much she loved it. Now that we clarified everything we could think of at that point, she felt confident to be able to focus on implementation, without having lots of question marks on product side. She even said she wanted to do this on all stories from now on. As for myself, I could not agree more. I felt that the biggest part of testing had already been done. As most of my questions were already clarified, I could focus on looking for further unknown risks when testing the actual product increment.

Our experiments triggered me to read about BDD again. I found several awesome blog posts, all emphasizing how important having those initial conversations are to create shared understanding by discussing examples and therefore to drive development. All of them stated that automation is nice to have, but that this is not the main point of BDD. Of course, when you automate the discussed core scenarios, you also have an executable specification, improved your regression safety net, and added living documentation. Still, Augusto “Gus” Evangelisti concludes for himself:
"BDD is about conversations and collaboration to generate software that matters"
 Liz Keogh even goes beyond software:
"I can’t even say that BDD’s about “writing software that matters” any more, because I’ve been using scenarios to explore life for a while now."
"BDD is the art of using examples in conversation to illustrate behaviour."
"If you’re not having conversations, you’re not doing BDD."
"BDD isn’t about the tools. It’s about the conversations you have, exploring examples (or scenarios) of an application’s behaviour, to see if everyone has the right understanding."
"Some people really focus on the tools and testing. Others focus on specification. Really, though, it’s exploration that we start with; those thought-experiments that are cheap to change, and not nearly as dangerous as the real thing. [...] It’s pretty easy to explore what they want using examples, then use the results of that conversation as specifications, then as tests."
Having conversations is more important than capturing conversations is more important than automating conversations
Having those quotes in mind, can we call our team's first steps with BDD actually BDD? I guess yes, but I think we have to gain more experience before I can truly answer this question for myself. However, I already know that having those conversations upfront to increase shared understanding, explore stories and clarify questions helped us a lot to deliver actual value to our users. It was worth investing the time and it will be worth asking again: "Can you give me an example?"

Thursday, June 1, 2017

Select Your Team

May 16, 2017 was a day to remember at my company. All the people of our FlixTech organization came together for a huge event. All our products were pitched by their owners. And then every single one was free to chose their product, their team, their role, and their location - from now on.

Beginning of the year, I have come across the following reports of such team self-design events.
After reading about this approach of giving the people the freedom to choose their own future and actively encouraging them to do so, I was both curious and excited to experience it myself. In order to learn how we facilitated our event in a nutshell, check out Day 0 by my colleague Alex. What I want to focus on in this post is my personal view on how people responded to the event announcement and on the days after.

Freedom and trust...?

As soon as our company signalled that we would redesign our domains and products, but also have all our people redesign our teams around those products, people began to raise questions and express worries.
  • "What if the team I want to work on is already full?"
  • "What if it's decided my team is now located in a different city than I live in, but I don't want to relocate?"
  • "What if the budget of my team is reduced so at least one former member has to leave the team?"
  • "I was just hired for this team a month ago, what happens to me?" 
  • "What about people on vacation, on sick leave, or stuck in a traffic jam on that day?"
  • "What about my salary if I change my role?"
  • "Oh this whole self-selection thing is just fake, management will maintain control, they won't put that much trust in people."
You can imagine how this list went on. In the end, I'm really happy that our concerns vanished into thin air. Our board and management actually did put a lot of trust in our people, our CIO ahead of everyone. And the people did take it as an opportunity. After three iterations of trying to find the right team setups, every team member was happy with their choice, just as management and the board. We identified only two teams for which we needed to hire people having the missing skills. The other teams could also use support, but were already able to deliver value. Overall, everything worked out way better than we even hoped for. We were exhausted - but enthusiastic about our new teams, ready to celebrate and kick it off.

What now?

That wasn't it. After the event was before our so-called ignition period. Several products had been re-designed or even freshly added. Some teams were starting from scratch. Some teams split into two. Previously existing teams ended up with different members. Some people changed their role. It was obvious that we needed to consider a certain transformation period and invest in team liftoffs, as Diana Larsen puts it (check out her Agile Testing Days 2017 keynote to learn more).

Personally, I decided to stay with my former team, just like most of my teammates. However, we lost one of us to another team and did not get any new member. Still, we changed. So we decide to take this opportunity to form our team from scratch, to "re-ignite" it.

Right after the event, it was pretty hard not to fall back into old habits and just continue with "business as usual". We knew each other already, had all skills covered in the team, and could simply pick up the next backlog items to work on. On the third day after the event, we finally forced ourselves to pause for a moment.
  • To learn more about our team and uncover what's hidden, we created a team canvas together. This workshop format helped a lot to share our thoughts, our values, our goals, what moves us, who we are - to find our own new team identity. We decided on what we want to achieve together as well as new working agreements.
  • We moved to another room and took this chance to change our seating layout. We wanted to make it obvious that the team actually changed. To try something new. To get rid of table islands, foster team spirit and hopefully ease communication and even closer collaboration.
  • We heavily brainstormed to select a new team name, logo, slogan, theme song, and more. This way, we learned a lot about us on a personal level which brought us a step closer together. We were surprised how hard it was to find something from popular culture that we all shared and loved, as we're quite diverse in any aspect.
It's been only two weeks since the redesign event. However, I feel we now laid the groundwork for our new identity. I have the impression our team feels revived and shows fresh energy. And I hope we can keep it up to achieve our common goals and continuously improve as a team.

Monday, May 22, 2017

Agile Testing Essentials LiveLessons - A Review

Do you like video courses? Maybe you prefer them over reading books? In my case, I enjoy all kinds of media for learning, with a mixed approach working best for me. When I heard that Lisa Crispin and Janet Gregory are working on a video course about the essentials of agile testing, I knew I had to check it out. Their books Agile Testing and More Agile Testing accompanied me on my personal learning journey and provided great advice in many situations. So I was curious how Lisa and Janet would convey the essentials using videos and what I still might learn from them.


The video course contains the following six lessons on agile testing.
  1. Lesson 1: Introduction to the Whole Team Approach
  2. Lesson 2: Test Planning in Agile Contexts
  3. Lesson 3: Shared Understanding through Early Testing
  4. Lesson 4: Automation in Agile
  5. Lesson 5: Agile Exploration
  6. Lesson 6: Ingredients for Success
All these essential parts of agile testing are addressed in a condensed form. Of course there is way more you might be able to talk about, but it would have exceeded the scope of conveying the core messages. For more information, Lisa and Janet refer to their books and encourage you to dig deeper yourself. As a starting point, they added a great list of recommended further readings to the course.


The video length ranges from a a few minutes to about ten minutes, which feels just right to be able to pause and resume any time. To get a first impression yourself, you can watch the introduction video for free. However, please be aware that this is the first video course Lisa and Janet did so far. As with every new experience, you learn as you go. In my personal opinion, the introduction video is not representative of how the two present their content throughout the course. With every lesson they get more used to the format and present way more naturally. To be honest, I love that this shows that we're all humans and constantly trying to improve.


In each lesson, Lisa and Janet first present the key concepts and then ask the viewer to do a few small exercises. This way you can instantly apply the theory. They have you pause the video and think how you would answer certain questions in your context, or which examples and cases you might think of to explore a sample application. I loved how they got me actively thinking and involved at any point. I just couldn't help comparing the presented ideas with my own situation, and found myself making lots of notes what I would love to try next with my team. Furthermore, they share their personal experience about many topics by telling stories from the teams they worked on. I especially enjoyed this part, as it combines the theory with "the real world", showing how they gained and applied knowledge. They also share how experiments might fail from time to time, making clear that failing is an essential part of learning.

Target Audience

In this video course, beginner testers find condensed essential knowledge, providing great guidance on their way to grow. However, I would still recommend them to read Lisa's and Janet's awesome books. In my point of view, the video course is not a replacement for them, but it is a great starting point.

More advanced testers probably know about most concepts (and most probably have read both books already). Still, the course is a great reminder of the basics and might trigger one thought or another. Although its content had not been new to me, the course got me thinking on how to better convey these essentials to my own team and company.

Which leads me to my most important point: This course is not only useful for people identifying as testers, especially as those most probably would not read the agile testing books. I warmly recommend it to everyone working in agile environments, as agile testing is in its core a whole team topic and everybody should know about its essentials.

Saturday, May 13, 2017

Thoughts about Testing in a Mob

This was not the first mobbing experience for our team, but the first one to complete a whole story using this approach. One key factor that the team agreed with mobbing at all, was that our mob size changed dynamically. Whoever wanted to join the mob was welcome any time, and whoever preferred to work on other tasks could do so as well. This way, our mob consisted of three to seven persons. The downside of this approach was that we did not always have all the knowledge at hand but had to ask asynchronously for feedback. Still, we had enough knowledge available to stay productive and make progress.

Personally I decided to always stay in the mob. As a team player, there was no other option for me. As the person who triggered that we give this approach a try, I was curious how it will work out and did not want to miss this learning experience. And as the only person identifying as tester on the team, I felt staying in the mob was just perfect to trigger tests, provide feedback, raise questions, and seek answers as soon as possible. This way, I felt another downside of the dynamic mob size: As some teammates decided to work on their "own" stories, I missed to provide feedback on those as early as I could (though of course others could have stepped in). Luckily the mob selected a story we needed to complete to achieve our sprint goal, which justified that I spent all my efforts there first.

After we finished our story, I was feeling proud. This was really a joint team effort and we all had our hands on the story, ensuring quality from different perspectives. But one thing made me think: Shortly before we decided that our changes are ready to be merged, one colleague challenged this by raising the question who does testing of the story. At first this puzzled me, as we had included testing all the way from start to finish. So I answered that the mob tested the story thoroughly. But this teammate was not convinced that you could possibly come up with all necessary tests in the mob.

As he could not tell what else to test, and the current mob agreed that we covered everything from quality perspective, we merged the story nonetheless. But his comment left me wondering. Did we forget something? Should we have something done differently? Should we have not allowed for dynamic mob sizes as particularly this colleague did not join all sessions? Which reasons did he have to think that testing cannot be done in a mob? Is there a trust issue?

Naturally, I don't have all the answers but I will keep an eye on this issue. To gain more insights, I decided to join Maaret Pyhäjärvi's tutorial at Agile Testing Days 2017 about Mob Testing. Still, my biggest hope is that my team continues working on actual stories as a mob to gather more experience ourselves and learn by doing.

Thursday, May 4, 2017

Mobbing - Take Two and Take Three

Two days ago, my team had quite a tough retrospective, openly addressing the issues we have in the team. Mobbing was named as one approach to improve knowledge sharing as well as challenging potential implementations. So we decided to mob again on the next day. In addition to the feedback on our first mobbing session, there was a strong wish to do things in a more informal way, more spontaneously, and with a more dynamic mob size.

Take Two

We decided not to book a separate meeting room but use our office, since we have our own big TV screen and quite some space upfront. We figured if this would work, we could mob way more spontaneously. We share our office with another team, so we wondered whether mobbing would disturb them more than other discussions we normally have in the team. We decided to "not ask for permission, rather for forgiveness" and just try it. And it worked out pretty well.
One of our longtime working students just started working full-time. Since he missed our first mobbing session, I provided a short introduction to the key concepts, emphasizing the rule that you're valuable in the mob if you are either contributing or learning.

This time we picked a large, complex story introducing new technology into our product. We considered it crucial to have the new knowledge shared with everybody as soon as possible.

According to the feedback from our first mobbing session, we decided on a longer and not so strict rotation. We set the timer to six minutes. When the alarm set off, we had the navigator finish what he wanted to do, and only then rotate. This rather event-triggered approach was really well received.

This time we had one team member working from home office, so he could only join remotely. As we don't have a technical solution to grant control, but only can share our screens, he could not become the driver. The mob had the impression that our remote team member felt left out, and he himself confirmed that the technical setup did not work well remotely.

After a two hour session, we finished with a short retrospective what we liked and what we longed for. Again the team loved the knowledge sharing aspects, the learning, the different approaches, the collaboration, the team building. Even though we had yet another developer laptop with yet another keyboard layout and no mouse available, it worked really well. People were a lot more willing to adapt to the unused layout. And the best thing was that when finishing mobbing for lunch time, we had a working increment! On the other hand, some doubts were raised whether the driver / navigator pattern really helped us or rather held us back. Productivity was again questioned. Also, we longed for more preparation and discussion upfront before actually starting with the implementation.
Still, the team agreed to continue mobbing on the story as we introduced new technology here and it was important that everybody on the team shared the knowledge. We agreed to try an even less formal approach for the next session, without strong navigator / driver roles and instead rather have everybody contribute on the fly. Last but not least, we also agreed to try a more dynamic mob size, with people being allowed to leave (like for personal meetings) or join anytime.

Take Three

Today, we gathered around our TV again. This time all co-located. Still, we had a team member in the mob who missed the last session, so we started by getting him on board what the story is about and how far we got. Then we continued with a short discussion on the open things to do, potential solutions, and agreed on the next step.

We had everyone on the mob, being allowed to contribute, even the one on the keyboard. We did not use a timer anymore, but still rotated the one at the keyboard about every fifteen minutes. We had a third developer laptop with yet another keyboard layout and even operating system - and again, it was not much of a problem anymore.

We also had the case that one developer left for a meeting and afterwards rejoined the mob. It didn't cause any issue. I had to leave for a conference call in the middle of the session myself.

After two hours, the team came to a point where they got blocked by another story currently in development, so they decided to stop. We didn't do a formal retrospective anymore, just asking around for opinions. We found that we really like this pretty informal approach, still with only one laptop, but with everyone contributing. We liked that the mob still rotated the one at the keyboard from time to time. We loved that everybody could speak up and contribute ideas. We loved even more that this session was received way more productive. All agreed they were happy with this format!

What Next?

The team wanted to give mobbing a try at least three times to find out how this approach might help us. Well, we've done three sessions by now, so our initial objective is accomplished. Originally, I wanted to keep the strict format for a longer period. However, I feared that the team would reject mobbing itself then, so now I'm really glad that we instantly adapted and tried a more informal way. I'm also glad this worked out with everybody still speaking up and being heard. As they liked this informal approach, I now see the chance that the team will not only include mobbing in their toolbox, but also make use of this tool, at least from time to time. I'm curious if a trigger will still be needed to break old habits and remind ourselves of this option. But I would love to see that happen.

Friday, April 28, 2017

A Thousand and One Things

The last weeks had been quite busy at work. When I think about all the things and topics I worked on, I'm getting dizzy at first, then excited, and finally thoughtful.

Although I love focus, I also love contributing to many topics. And I learned that I should just do what I like to do if I think it's worth spending my time on. Well, this could be considered good ("you're not just delivering what's asked of you but providing additional value") - or bad ("you're not focusing on your actual task"). During the last months, I received mixed feedback from several people about my involvement in many areas which got me thinking about this topic a lot. So I decided to reflect on what I actually did during the last three weeks since we had the first mobbing session in our team.

  • Lots of testing. My team made really good progress, collaboration mood was high, backlog items flew nicely through our workflow. Investing time upfront, before a first increment is implemented, paid off again. Brainstorming things to test, clarifying questions, trying to reach shared understanding together with product owner and developers, and also testing early increments, was again well worth the time. Though it might sound counter-intuitive ("you have to do the work twice then"), it speeds things up a lot for me. And it leaves a great feeling of being "on time" with providing feedback, instead of "always late" when tickets suddenly pile up.
  • I've been sitting with some of my developers, pairing on trying out different implementations, debugging, or fixing identified defects. I love doing so, but currently don't prioritize it high enough to do it more often.
  • As we have a new developer on the team, I had a few onboarding sessions with her to provide an overview on workflows, product history, company backgrounds, and much more to get her started.
  • My team is giving peer feedback a try, so I've provided written feedback for my teammates. Though I think I should provide feedback more often and rather face-to-face, I really like this formal instance. I feel it helps me discipline myself to provide regular feedback also on a personal level, not only on things we are working on. When it comes to providing feedback on personal level, I'm not confident enough that I'll find the right words in a face-to-face situation to help the other grow without offending him. So in the end I mostly either say nothing (which I feel is pretty bad, and also a missed chance for the other one) or I address things in team settings (like a retrospective, which is often not the right place for personal feedback). Getting the chance to take the time and carefully formulate the feedback before providing it, helped me a lot. The only problem: I don't know how the others interpreted my feedback and responded to it.
  • We've just officially introduced OKRs (objectives and key results) at my company. As I happen to be in a supporter role to help kick this change off, we regularly meet to reflect and decide on next steps.
  • We also happen to think about an official company tech blog. I highly support this endeavor, so I agreed to join the group of editors.
  • To further increase our perception as tech company, we are striving for hosting more meetups at FlixBus. I'm part of the organizing group, and we even had two meetups hosted a few days ago. That was a great first step, but further steps have to follow.
  • We have an internal agile testing community at FlixBus, open to anybody interested in testing. As community moderator, I prepared another internal meetup. This time, one colleague shared her insights from TestBash Brighton, and another one her lessons learned from implementing a new onboarding concept. Thanks to my fellow community members, I learned a lot!
  • As community moderator, I am frequently the first contact person in case someone needs input regarding any testing topic. One of our people managers asked me for a rough list of skills and topics I would see for an agile tester. Hard topic! Made me ask questions first, like why this is required and what exactly is needed.
  • Another colleague contacted me if I could support during an ongoing audit where the auditors wanted to gain more insight in how we do testing. So I provided a collection of materials.
  • A tester from the international testing community approached us and asked whether we might offer one of our products as system under test for the meetup he organizes. Great opportunity for both of us. I connected the right people so they can proceed on the topic.
  • We received several more applications on our job offer for software testers. For now I only reviewed materials and provided feedback, but probably I'll find myself sitting in interviews soon again.
  • I supported a tester colleague with registering for this year's Agile Testing Days including booking hotel and flights, and did so myself. We both will attend the full week and can't wait for it!
  • A fellow team plans to introduce automated tests through the UI. They asked me whether I might share how we deal with automated tests, on which levels we test, who writes them, which tools we use, etc. They wanted to learn how we do it and see what might fit to their context as well. We had a quite interesting conversation, I'm curious what they will decide on during the next weeks.
  • The tester of yet another team asked me whether I could give a testing workshop for his team and share how we handle testing in my team in general. He simply wanted his team to hear about testing from a different person and perspective. During the first part of the workshop, I shortly introduced the developers to exploratory testing, and then had them engaged in a hands-on testing session. I did this with three different groups already, and it's always been fun! I had a great time, but also the developers enjoyed approaching the product from a different perspective and finding many issues in short time. As second part of the workshop, I presented how we do testing in my team and our context: our whole-team approach to quality, testing throughout the workflow, what kind of tests we run and on which levels and systems. Especially our vacation replacement rules, having the whole team take over all testing, caught attention and we had a great conversation. Hope I could trigger some thoughts and ideas.
  • A colleague and I hosted an agile UX workshop for our teams - using LEGO! We had so much fun together. Well, we had LEGO, right? The workshop was inspired by one I attended at last year's Agile Testing Days, hosted by the wonderful Karen Greaves and Samantha Laing. Big thanks to them! If you have the chance to join one of their workshops, do so, it's worth it.

One more thing I learned during the last weeks: I've been selected as new voice to speak at TestBash Munich in October! I'm so happy about it and looking forward to take you on quite a personal journey with FlixBus.

All in all - I do understand why I received mixed feedback regarding my many activities. It's definitely great food for thought. So far, I've not decided in which way to adapt. But I wonder what they might think if I also told them about the many topics I don't involve myself, or the many more ideas I intentionally postpone?

Thursday, April 13, 2017

Our Team's First Mobbing Session

Last week my team had our very first mobbing session together. I was quite excited! I have read and heard a lot about this whole-team approach, and I was curious to try it myself. I had a first glimpse of how it could look during a coding dojo I attended a few weeks ago, but I really wondered how it would be to try this with the people I work with every day. I guess I talked a lot about mobbing, presenting it as a potential solution for some of the problems we are facing. And suddenly, during a sprint retrospective, my team decided to give it a try! Here's the story how it turned out.


Since I was the one who triggered this experiment, I was also accountable for having it facilitated. However, I also wanted to join the mob myself. So I asked our agile coach if she was willing to help me and act as facilitator during the session. So glad she agreed!

As nobody on our team ever tried mobbing before, I wanted to have our first session facilitated as well as possible to get everybody on board. To prepare for it, I used the following valuable resources on mob programming and mob testing. You can skip over them for now, but in case you would like to facilitate a session yourself, I highly recommend following those links.
All resources recommended starting with a short session, so I scheduled 2.5 hours for it. As we don't have a dedicated team room, I also booked a meeting room well in advance, as otherwise it's hard to get one for a longer time slot at my company.

Our agile coach and I sat together to prepare the session. We shared any knowledge we already had about mobbing, defined the structure and prepared posters to serve as information radiators throughout the session.

I asked my team whether they would rather do the experiment in coding dojo style using a dedicated kata, or if they wanted to work on a real story from our backlog. The team decided unanimously to go for the latter. During sprint planning just before our workshop, we picked a middle-sized, quite straightforward story and reserved it for our mobbing session.

Room Setup

We knew how the meeting room we booked looked and what it offered. We identified a list of things we had to bring ourselves.
  • One developer laptop with an external keyboard and mouse; to simplify things, I just asked one of our senior developers to bring his (as it happened he brought an external Apple touchpad)
  • One projector; the meeting room was lacking one
  • The posters we prepared
  • Flip chart sheets and tape to put them on the wall (in the end we found the room actually did have a proper flip chart)
  • Sticky notes and pens
  • Timer
  • Beverages; everybody should bring what they need
  • A bowl of cookies :)
What not to bring? Any other laptops or mobile phones, to avoid distraction. Though this might change later on, we decided to be strict about this for the first session to have the full focus of every team member on one thing only.

Agenda & Introduction

Our Daily Scrum is scheduled for 9:30 am. We decided to do a morning session, starting right afterwards. However, we knew that it will take some time to bring everything to the meeting room and to set it up, so we could only start with everybody at around 10:00. Also, it was crucial to keep the session relatively short in order to end happily and go to lunch together.
We scheduled a short introduction to mobbing to start our first session from a common ground. This was especially important as nobody on the team had experienced mobbing before.

Following Simon Sinek's advice, we decided to start with "why".
  1. Remove productivity blockers. Many times when it comes to mobbing, the question is raised how having the whole team work on only one topic could be productive. However, Woody Zuill recommends focusing on impediments, preventing or destroying productivity. Like the following things that mobbing can overcome:
    • Multitasking
    • Interruptions
    • Being blocked
    • Technical debt
    • Code cruft
    • Waiting for information or reviews
    • Unnecessary meetings
    • Incomplete understanding, or not understanding the problem at all
    • Context switching
    • Merge conflicts
    • Lack of quality
    • Missing knowledge
  2. Extend our toolbox. To learn continuously, we should be open to new or different development approaches and know our options to chose from. We might not end up doing mobbing all the time, but it might be a great way to tackle huge, complex, unclear stories.
  3. Learning opportunities. Mobbing maximizes learning and sharing knowledge in the team, often including implicit knowledge. This way we can increase our bus factor even more. Besides that, you can always learn new things in a group, as everyone is used to different approaches, thinking styles, even keyboard shortcuts; so look out for the unexpected! Furthermore, teams who do mobbing say that it's like instant onboarding for new team members. As it happened, only two days ago a fresh new developer started in our team. Perfect timing to find out if mobbing as onboarding works for us.
  4. Get the best out of everyone. Last but not least, mobbing is actually not about getting the most out of the team and keeping everyone busy. We all have good days, but also bad days. When coding solo, the good and the bad both go into the code. But a mob will prevent the bad from being introduced into the code. Mobbing is about getting the highest possible quality out of the team.
To explain the basic idea of mobbing, we used Woody Zuills famous quote: "All the brilliant people working on the same thing, at the same time, in the same space, on the same computer." As recommended, we decided to do strong-style mobbing for our first session, following the driver / navigator pattern. So we also introduced the key concept of strong-style pairing, as defined by Llewellyn Falco: "For an idea to go from your head to the computer, it must go through someone else's hands."
In order to explain the roles used in strong-style mobbing, we had put small cheats sheets right beside the location of the role (except for the facilitator).
  • The driver. The one at the keyboard, acting as smart input device. There's no thinking at the keyboard, just do it!
  • The navigator. This is the main programmer. State the intention, maybe add the location you're referring to, maybe you even have to go down to the keystroke required next; whatever is the appropriate level of abstraction for the current driver.
  • The mob. The rest of the group. What do they do? Checking the navigator, contributing insights when appropriate, preparing for their own turn as navigator.
  • The facilitator. Observing the group from behind the room, jumping in whenever required to ensure principles, roles and rules to create a safe experience. In our case, she also was queen of the timer. This role is helpful when you get started; it should not be required anymore later on.
We defined the following common rules to make the session successful and valuable to everyone.
  1. We treat everyone with kindness, consideration and respect. Be kind. Listen to each other and consider all the options; everyone on the team should be heard. Let the others shine! And always assume that the person before you did the best they could with the knowledge at that time. The mob should be safe to experiment. It should be safe to learn. This experience can be scary at first, especially for those who normally don't code (like me) or are rather introverted (like me at most times).
  2. We say "yes, and...". This rule comes from improvisational theater and basically reminds us, instead of destroying what the one before us just implemented, continue with what we have and build upon it.
Providing examples on a whiteboard or flip chart can help as well. Or thinking in English, not in code. Going small steps, committing frequently. Do you see several solutions? Well, try both, the weirdest one, or the one from the most junior person in the room first. The mob format can work if you are either learning or contributing.
 To finally get us going, I concluded the introduction with a few more hints.
  • We offered a flip chart if anyone wanted to foster shared understanding visually.
  • We provided sticky notes and pens for whatever thought they wanted to note down, such as for their time as navigator or for the retrospective later on.
  • The rotation: The navigator becomes the driver, the driver joins the mob, the next one from the mob becomes the navigator. We decided to rotate every four minutes as recommended for beginners. Later on this could be less strict, we could try different times, or rotate more fluently, whatever the team feels is right.
  • Now let's have fun!


We had predefined our very first rotation in advance. As we had our Product Owner on the mob who never coded before, myself having only basic programming skills, and a fresh new programmer on the team, we intermingled with the others to make sure that we didn't end up in a driver/navigator constellation where we instantly get stuck. Furthermore, we defined two core developers starting as driver and navigator, which proved really helpful to kick everything off and get things started.

During the session, the hardest part was to keep the driver from thinking and rushing ahead without waiting for the navigator. In the beginning, the mob was quite unsure how to contribute, but soon learned to give advice when asked by the navigator, or even offer that voluntarily; but to always have the navigator decide which way to go instead of directly addressing the driver.

With the quick four minutes rotation, we managed to have everybody on the team become navigator and driver at least four times, so we could get used to those roles and learn how to pick up and proceed with the implementation. At first, the rotation in the mob from chair to chair was strange, but quickly became normal. Having the bowl of cookies in the middle of the table definitely helped! ;)

What instantly became clear: Even with a quite straightforward story, we struggled with being navigator. Several of us often required support from the mob; not only those who didn't identify as a programmer or were new to the team. And we struggled even more as driver, having different operating systems installed (OS X versus Linux), different keyboard layouts chosen (German versus English), different shortcuts defined, different scrolling directions set, and different input devices in place (external Apple touchpad versus Apple mouse versus default mouse). This turned out to be quite frustrating; at points, this made everyone look like it was their first day using a computer.

Retrospective & Closing

We decided to have a short "What I loved" and "What I long for" styled retrospective, with everybody writing down their thoughts on sticky notes and presenting them afterwards to the rest of the team.

What we loved:
  • Knowledge sharing. This feedback came from almost everybody on the team. We loved the sharing aspect in general; but especially learning more about a particular implementation, about how to solve common issues, and about different approaches to tackling a problem. Or simply how to start with a story regarding the thought processes involved. The most interesting finding here was that not everyone, I mean not every programmer on the team, shares the same knowledge of the existing source code.
  • Learning why we do specific things. It was really helpful when the navigator explained why they wanted to do something, or what's the background of doing it like this (such as "leaving this parameter out will make it the default").
  • Interaction and collaborative mood. It was a really inclusive atmosphere! Our new team member loved getting advice from the more experienced ones. One of us even mentioned it felt like team building.
  • Everyone can contribute. Our product owner said he was surprised that he could understand and contribute so much, although he never programmed before. He loved to see the code and its structure as well as to gain a better understanding of what the team does all day.
  • Driver/navigator and mob roles. The strong-style navigation and mobbing itself was regarded as an interesting approach.
  • Room setup. Our preparation proved valuable, the setup worked well for us!
  • Fun. The atmosphere was focused on learning and finding our way to get things done, but we still had a good time together. Especially when one navigator asked his driver to "please make three children"! :D Oh and don't forget the cookies; they always help! :)
What we long for:
  • A driver setup everybody can get used to. As we struggled a lot with different operating systems, keyboard layouts and shortcuts, we really longed for a commonly accepted setup; especially a normal keyboard and mouse. Well, define "normal"! ;-)
  • Finish a story as a mob. In our first session we could not complete the story we had chosen. Not even the implementation, let alone testing and all other activities included to get a story done. Which was a pity because we couldn't share knowledge about those parts of product development. So, we long for getting a story at least to the status that it's merged to the common code base.
  • Try mobbing for a more complex story. The team selected a medium-sized straightforward story. However, our product owner is eager to try mobbing for more complex features. Probably to see if this approach would really help us to tackle those.
  • Faster reload time of our web application. This is not directly related to mobbing, but it became pretty obvious that a simple page reload of our application costs a lot of time. As we decided on rotating every four minutes, we really felt the pain of having everybody waiting for the page to reload, shortening the time the navigator and driver had to proceed with the story a lot.
  • No thinking, won't you? People felt it was really hard to break their habit of thinking and working on their own when sitting in front of a laptop.
  • Less context switching. This point came up with regards to the frequent switch between the different roles; longing for a longer rotation duration. I totally agree with experimenting to find a rotation time suiting us. Still, this feedback took me by surprise at first, as personally my experience had been exactly the opposite. I'm used to switching contexts many times a day. Though I try to limit them wherever I can control it, many things can pull me out of my zone and flow. Therefore, mobbing was a total relief for me, enabling me to focus on one thing the whole time, staying in the same overall context.
  • Productivity. No surprise, there are still a lot of doubts whether this approach is really productive as opposed to working solo. But we don't have any proof of that yet.
As part of the closing we thanked everybody for giving mobbing a try and for their feedback. We agreed to put the started story back to "To Do" and the first developer with free capacity will pull it. Finally, we asked all team members to vote whether they would like to do a second session. The majority agreed, some were undecided. In the end, we kept our timebox and left the room in time for lunch - in a happy mood! :)

Personal Conclusion

In the end, I'm really glad my team agreed to another session. Can't wait for our next learnings! Besides that, I'm feeling a lot more prepared to facilitate mobbing sessions for other teams as well. Some had heard we wanted to try this approach and showed interest themselves; one agile coach would even like to join our next session to watch and learn. Well, for now we only know the lessons of our very first session. But if you want to give it a try in your team, feel free to copy whatever you like and adjust it to what you need. I would love to hear about your learnings as well!

(Oh, and by the way: did you find the bug in our posters? ;-))

Tuesday, April 4, 2017

Share Your Story, Too!

Ever thought about speaking at a conference? Well, let me tell you the story how I ended up with 10 submissions of 6 unique paper proposals for 3 conferences in 2017. If you would have told me this story one year, or even half a year ago, I would have thought "hey, nice story"; but I wouldn't have believed that it was about me.

So what triggered me to answer a call for papers at all? So far, I've only been to one conference in my life, which happens to be Agile Testing Days. I attended in 2015 for two days. I was eager to join the full-day tutorial of Lisa Crispin and Janet Gregory, not only because of the interesting topic, but because I was really excited to meet them in person. Especially Lisa, as we had contact via Twitter before. After the tutorial ended, I took my chance to have a few words with her face to face. And she told me: "Hey, why don't you submit a talk yourself, you certainly have a story to share!" Back then I probably blushed and laughed it off; I felt appreciated just by the idea, but was definitely not ready to take it any further.

In 2016, my company enabled me to attend the Agile Testing Days for the full week. I had learned to appreciate the huge community part of this conference, so last year I was ready to broaden my network and get to know more people along with their stories. One day during lunch, I happened to find myself at a table with three guys from all over the world, among them Toyer Mamoojee. We all had attended the conference's opening keynote by Abby Fichtner, Pushing the Edge on What's Possible. This talk set the stage for the whole conference, encouraging us to face our fears and be brave. So we happened to start talking about what scares us the most; and speaking at a conference was definitely something Toyer and I shared as a major fear. Suddenly he said: "Let's make a deal. If I submit a paper for next year's Agile Testing Days, you have to submit one, too; and if you do, I have to do it as well. Deal?" He took me entirely by surprise. For a short time I felt snap-frozen - but then remembered what we heard the last days. That we have to step out of our comfort zone to see the magic happening, and that we should do one thing every day that scares us - so I accepted the deal. I couldn't believe I had agreed so quickly, but Toyer did not let me get away with this anymore! ;) He even told everyone waiting for the next keynote that we both now have a deal and will return with a paper next year. No excuses.
The following day, I attended a lean coffee session together with Viktorija Manevska. I met her already in 2015, but last year she came to the conference as first time speaker. She was so kind to share this experience and tips with the rest of the group. Everything from writing a paper proposal, receiving feedback on it, going through the approval process, creating the actual presentation, and giving her very first conference talks. The topic was so fascinating for the whole table that we voted to continue with it for quite a long time! :) Viki also kindly offered her support in case anyone of us wanted to submit a paper themselves.

Now you know about my triggers to actually work on a paper proposal for Agile Testing Days 2017. But how come I submitted even more?

Back at the office, I started telling my colleagues about my personal challenge this year; to support the fact I really had to submit at least one paper. Furthermore, Toyer and I held each other accountable on our deal, so we started brainstorming potential topics to speak about. Topics we could do on our own, but also considering a topic we could do together. Kicking it off triggered another idea. I knew that TestBash will be coming to Munich this year, and that the related call for papers was still running until mid of February. So I thought: why not also trying to submit there as well, so I could get to know the whole process and gather first experience? As a side effect, this triggered me to work on my paper proposals even earlier. Three of my awesome colleagues volunteered to provide feedback: John Webber, Alex Kiefer and Viola Korte. I discussed my ideas with them and included their valuable feedback in my first proposal drafts. After several iterations, I had two topics I felt comfortable sharing my experience on, hoping that a potential audience would get value from it. Still, to start small, my first challenge was just about submitting a paper and getting feedback on it; not about getting it accepted (though I tried to aim for that of course). You can't imagine how happy I was when I met the submission deadline for TestBash Munich just in time! First personal achievement unlocked. The submission confirmation page told me that I wouldn't get any feedback in case I would not be accepted, as they keep the proposal for potential future conferences then. Well, I didn't get feedback yet; but hey, it was a great learning experience.
On the very same day, Viv Richards saw my tweet, contacted me and asked whether I would also consider to submit my papers for the conference he is organizing, SwanseaCon. I was stunned. I had never expected such a reaction! So I thought: "Why not?" And submitted. And after a few weeks, just one day before going on a longer vacation, I received the confirmation that one of the proposed talks had actually been accepted!!! Still can't believe it. Totally honored and thankful for that opportunity. I'll be talking about learning agile testing, and this speaking experience will definitely become part of my journey.
Meanwhile, work on the paper proposals for Agile Testing Days continued. Toyer and I identified a fascinating common topic we were eager to submit as a workshop. Remembering Viki's offer to support with paper submission, I contacted her and asked for feedback; and she returned the question whether we could also do a topic together. Sure, gladly! Within several calls we shaped an intriguing common topic to do a workshop on. So I found myself working on four topics at the same time. Then the official call for papers started, and I finally gathered my courage and contacted Lisa Crispin, asking her whether she would kindly review our paper drafts and provide feedback on them. Her most surprising answer came quickly. Sure, she'd love to provide feedback; but hey, the conference organizers offered her to do a workshop together with a new voice this year - whether I would like to do it with her? Wait, of course!!! We also found an exciting topic and I loved our close collaboration so far. I still can't believe I am actually getting the chance to do a session at this year's Agile Testing Days - and that together with Lisa! I consider myself really lucky.

Did you notice that was paper number 5? Last week, Jan Jaap Cannegieter contacted me and offered his help to review my current proposals and maybe do one together. I couldn't resist and agreed to join in on one of his workshops as co-speaker, so this is the bonus paper number 6! ;)
Having submitted all six papers is feeling just great. Having been accepted by two conferences as a total newbie speaker is such an awesome feeling I cannot described it properly. Well, I now have to do my best to live up to expectations. I try not to think about it too much, but instead keep moving forward to not fall into the hesitating self-doubting trap again. Full focus on learning.

With all those great feelings involved, the best part of this story, however, is the collaboration with those most awesome people. I can't emphasize that enough. We shared our stories and experiences. We worked closely together going through many feedback loops. We are proud and excited about the results and really hoping our proposals get accepted because we think they really would be worth it. Fingers crossed! This experience of writing paper proposals, not only on my own but especially together with my testing peers, was worth it a thousand times already. My great hope is that many more people get inspired to be brave, step up and share their stories, too. I bet all of you have awesome things to share with the rest of us!

So this is the story how I ended up with 10 submissions of 6 unique paper proposals for 3 conferences in 2017 so far, getting accepted by 2 already. I'm still speechless. Totally excited. And truly grateful for the inspiration, motivation, and support of all those great, great people mentioned above who are sharing this part of the journey with me. I hope that one day I can help a new voice to her first conference talk myself.