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.

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?

How I Fell into Testing

Let me tell you the story of how I became a tester. To be honest: That I could do something like that never occurred to me until I actually did it.

If you had asked me as a child what I want to be when I've grown up, I would have told you something like robber's daughter, or artist, or that I simply could not imagine how it would be like as a grown-up.

If you had asked me as a teenager what I'm planning to do for a living, I would have told you that I really don't know. That we did some tests at school to identify our strengths and potentially fitting jobs; but they weren't quite helpful. That maybe teaching art might be awesome.

If you had asked me as a university student why I selected sinology as my major subject and what I wanted to do with it afterwards, I would have told you that I chose it purely out of interest. The point was that I always knew that I wanted to go to university, but I simply could not imagine which profession I wanted to pursue later. Side jobs only showed me what I did not want to do. As I was aiming for a liberal arts oriented degree, I would be a lateral recruit in any case so I would have to learn on the job.

Then the time came to select the topic for my master thesis. And I suddenly had a "crazy" idea: Let's combine it with a topic I love! I was quite surprised that my professor accepted when I told him that I want to write about computer games in China. But great, that worked out!

When I finally received my master's degree and I started searching for a job I thought: Why not take that further? When I could write about computer games, then what if I tried to get a job in the games industry? If not now, when then? Lucky me, I was hired by a small startup developing AI middleware for computer game developers. What a fascinating topic to work on! And no, I didn't apply as a tester. I did not yet think of that. Instead, I started as game designer. I honestly don't know how I got this chance without having any experience in this area, except for my passion for computer games, but it was one of those turning points in life. And my first contact with software development.

So how did I finally fall into testing, then? Well, the former tester quit his job one year after I started - and my boss offered me his position, telling me in the same breath that I wasn't so good as game designer after all; but that testing would fit me perfectly. I was shocked. My bubble had suddenly burst. And then I decided to give it a try and become the tester on the team.

It was one of the best decisions I've ever made. I quickly learned my boss was right - I finally could apply my strengths and much better contribute to the team. And I enjoyed it so much that I realized: This is it.

Recently I stumbled upon the article "Testers: The Origin Story" which nicely fit to what I wanted to write about. It seems I was not the only one who didn't consider "software tester" for their list of potential professions. And that I wasn't the only one starting in the games industry, either!

So if you would ask me today: What is it that you want to do? I'd tell you that I already do it. I want to test to develop great products to delight our users. I want to tell and show people how awesome it is to work if you love what you do. How happy you can be. Follow your passion.