Testing Tour Stop #15: Pair Evolving a Test Strategy with Toyer

The testing tour continues. Today I had the honor to pair test with Toyer Mamoojee. Since end of 2016, when we agreed on our first pact to try ourselves as conference speakers, we are having a call once every two weeks. We talk about all things testing, exchange experience, trigger thoughts, provide feedback and support. Still, we haven't ever tested a product hands-on together. You can imagine how happy I was when Toyer took the chance and scheduled a pair testing session with me on my testing tour!

It's only a pleasure Lisi, and glad I could be part of you amazing Testing Tour. I learned many aspects today which I will use going forward regarding approach and things to keep in mind. I really enjoyed pairing with you on this 1. #accountabilityBuddy #TestingTour

— Toyer M (@tottiLFC) 17. Juli 2018

What topic to pair on?

That's one of the common first questions that come up after scheduling a session. In this case, Toyer said he would love to do something from scratch, gather test ideas together, align our thinking. We know each other and our viewpoints quite well, but we haven't yet practiced testing together. He wanted to see how we really go about testing certain things, ask questions and see each other's thought processes when actually testing.

Based on his input, I thought let's tackle an application we both don't know, explore it and come up with a very first test strategy based on the gathered knowledge. As I knew that Toyer discovered mind maps for his work some time ago and learned to love them for many purposes, I thought that this could be our way to document our very first strategy draft, keeping it lightweight, easily editable, visual.

Having a list of potential applications to tackle at hand, I reached out to Toyer and asked whether he wanted to learn more details about my idea before our session, or rather not. He answered "I'm tempted to say share more information.. but I would like to be surprised too, as I want to see how I can tackle something without preparing". So he chose the latter option to which I can really relate. Over the last years I am continuously learning to tackle things without over-thinking; and I'm not done with learning this yet.

Evolving a Strategy While Exploring

At the beginning of our session I presented my topic idea to come up with a test strategy for a new product, and Toyer agreed to go for it. Lucky me, otherwise we both would have had to cope with an unprepared situation! ;-) So I provided different options as our system under test of which Toyer chose Blender, an open source 3D creation tool. I had some rare encounters with this application back at my first company when we developed an AI middleware for game developers, but had hardly touched it ever since. Toyer thought it looked really promising as we normally don't get to test these kinds of applications.

Toyer shared that first of all, he would ask which kind of need this application wants to fulfill and do related research upfront. For the limited time box of our session, however, we decided to skip this and explore ahead. Toyer accepted my suggestion to draft our strategy in a mind map, so we created it and continuously grew it according to our findings. He also agreed to do strong-style pairing while exploring, so I started up my favorite mob timer, set the rotation to four minutes, and off we went. It quickly became clear that we knew each other well. Collaboration was easy and communication fluent. We could fully focus on exploring Blender from a high level point of view, trying to grasp its purpose and main capabilities, identifying limitations and potential risks. We were actually doing a recon session, just as Elisabeth Hendrickson describes in her awesome book Explore It! Reduce Risk and Increase Confidence with Exploratory Testing.

Throughout our session we gathered lots and lots of findings and discoveries, adding more and more important points to our test strategy.

• Learnability. The application is not intuitive at all. It's a real expert tool. Still, everybody is a first-time user once, and even if you know the domain the user experience this product offers is not that great.
• Functional scope. The more we explored, the more functionality we discovered. The whole tool seems really powerful, but again, is not easy to understand.
• Screen resolution. The GUI is cluttered with many UI elements, sidebars, popups and more. On our laptop screen that was already a challenge, and it will still be one on larger screens.
• Usability.
• Menus, popups and tooltips looked very similar which made it hard to distinguish the purpose of each.
• Feedback on actions was often missing or confusing.
• Some sidebars displayed content related to views we previously visited, not getting updated with information of the current view. This way, they sometimes obscured needed information.
• Consistency.
• Some actions worked in one area but not in the same way in another.
• Some sidebars were named x but the header label said y.
• Some delete actions asked for confirmation, others just instantly deleted the item.
• Portability. We tested Blender on macOS. The product is also offered for Windows and Linux. At several points we found strange unexpected behavior and made the assumption that it might have been due to porting issues for the macOS version. For some points, I could even confirm that assumption when writing this blog post and checking the Windows version of Blender.
• Maintainability and reusability. The GUI offered many sidebars, popups and views that shared similar layouts and menus. We noted to investigate whether they were duplicated or re-used components.
• Robustness. We encountered error messages on invalid input that was not caught or prevented.
• Automatability and testability. The application offers a Python API. We found Python commands offered in tooltips, the API reference in the help menu and an integrated Python console. The console behaved differently than we knew it form other terminals, but still it was very interesting that you could automate operations; which would also increase the product's testability.
• Discoverability and documentation. The help menu offered an operator cheat sheet; clicking on it triggered a temporary message to look at the OperatorList.txt which we could not find. Only later I learned that we had not come across the text editor where you could open named text file. What a hidden support feature. Also, we found the linked release notes page to be empty. We didn't dive deeper into the manual, but all available documentation would have to be tested as well, especially for an expert tool like this.

All in all, we made our way through many parts of the application. We made quite some assumptions. And we found we still haven't seen a lot yet. In the end, we didn't have a final test strategy, but a good starting point to be iterated over.

Time to Reflect

We covered a lot in the limited time. We gathered lots of insights, ideas, assumptions to verify. We tested a product in a domain we both don't know much about, being a desktop application instead of our usual web applications. We tried to gather information and keep a holistic view on things, not diving deep yet, focusing on uncovering the different aspects to test for such kind of a tool. All the way mapping out our world and the points to tackle in our test strategy. As we learned more, our strategy evolved. We didn't reach an end by far. If this would be our product to test, we would iterate over it while learning more.

The unknown domain had its own charm. We approached the product as a black box, not looking under the hood in the first place. We brought lots of testing knowledge, but quickly saw we lacked the domain knowledge. Toyer made an important point here: when hiring a tester for such kind of a product, it would be best to look for someone who was already exposed to these kind of tools or related areas of expertise. We could still provide lots of value and ask questions which might go unasked otherwise, but we would quickly pair up with a product person or business analyst to model the product from domain point of view. And also sit with developers to model the product's architecture.

Pairing up helped once again a lot. To see different things at the same time, by looking at different parts of the screen. To grow the mind map way faster than any of us would have done on their own. And to include different thoughts and viewpoints.

Enrich Your Experience

This was the fifteenth stop on my testing tour so far. In the beginning I had only planned ten sessions, one per month from beginning of this year until end of October. Although I already overachieved my initial goal, each further session enriched my personal experience and brought me in contact with different approaches to learn from; all that while practicing my skills hands-on. Right now, I am reflecting on my whole journey so far as I am crafting a talk about my experiences on this tour which I have the honor to give at CAST and SwanseaCon this year. And just while doing so, another tour stop was scheduled with me, further people indicated interest to pair up or listen to my lessons, and I'm having further test sessions with awesome people. I'm curious where else this will lead me. What a wonderful time.

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.

Some Insights of @AgileTD Call for Papers process and work! It was not easy! Thank you to the team and to the submitters. Grazie Mille Alex! pic.twitter.com/JZBiyQUWnZ

— José Díaz (@jdiaz_berlin) 4. Mai 2017

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.

Am I wrong when my first reaction is, "That's a whole bunch of dudes." 4 women out of 51? https://t.co/xEshQdPvkp

— Ashley Hunsberger (@aahunsberger) 20. Juli 2017

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!

Thank you for mentioning me! Wouldn't name test automation as my strength, but agree there are way more women out there who should be named

— Elisabeth Hocke (@lisihocke) 22. Juli 2017

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.

How 'bout them apples? ;-) https://t.co/Q9U9TCZ2VU

Conf Organizers - no excuses for lack of women speakers. REACH OUT to anyone here!

— Ashley Hunsberger (@aahunsberger) 14. August 2017

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: https://twitter.com/lisihocke/lists/awesometesters 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!

Wanna know who those women in testing are and what we do? Here you go for the first 125. There are way more. https://t.co/C6EcNnRfyT https://t.co/Jswjt2L9Nj

— Elisabeth Hocke (@lisihocke) 11. August 2017

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.

No matter what diversity in tech looks right now. It's our responsibility to prepare an env to foster and welcome more diversity tomorrow.

— Patrick Prill (@TestPappy) 14. August 2017

Great Place to Work

Remember my colleague asking me to include more images in my blog? Said colleague also asked me why I never mentioned my current company. Nothing would speak against it - we really enjoy working here!

So far, I shied away from publicly naming any companies I worked for (though of course you could look them up in my professional profiles). Maybe it's due to the fact that I rather follow humans than corporations. Or that I prefer to read stories about humans. Or that I quickly pull away when it feels like someone's trying to sell me something.

But he is right. We really enjoy working at our company, with so many awesome people, building great products for our users. And it's a shame we're currently having problems to find more of those awesome people fitting to our mindset and culture. To be honest we really could need some shameless advertising to attract more people and let everyone know we're a great tech company!

Finally, to make it public: I am an agile tester at FlixBus! Our vision is smart and green mobility for everyone to experience the world. Have you seen green buses lately on Europe's roads? If not yet, expect to see them soon! ;)

Before you say "Wait, buses...?" - although it might seem the most obvious, we are not a bus company. We do not own any buses, we have no bus drivers employed. The whole bus part of the business is done by our bus partners. However, we bring people and buses together! We are taking care of the logistics and technology part of of the business. And to do so, we're developing several products.

What do I love about my workplace?

• Freedom. Within our product teams, we are free to chose whatever we consider most appropriate for our product. We go for new technologies and development approaches, sparking innovation wherever we find it!
• Openness. This may be taken for granted sometimes, but for me it's crucial. And it's only possible by having trust! Speaking of which:
• Trust. One of my most favorite lines of our CIO Daniel Krauss is that you don't have to earn his trust; you have it from the beginning. And he really lives up to it.
• Responsibilities. Take over any tasks you want. Bring yourself in and contribute wherever you can provide value.
• Opportunities and focus on learning. You can change to other teams, positions, grow in any direction you would love to grow. You just need the urge to learn and develop yourself.
• Team collaboration. The whole-team spirit! We encourage full-stack developers, including spreading DevOps, UX and testing knowledge. Remember the bus factor?
• Deliver high value to our users. We focus on solving our user's problems and making them happy to work with our products. We strive to get their feedback fast and frequently to guide development. 
• Flat hierarchies. Our teams are truly self-organizing. Did I mention we don't have team leads anymore? We're focusing on lateral leadership. Step up and lead by example!
• Multi-cultural. Our people are coming from all over the world! My department of 28 persons alone lists 13 nationalities. Not to speak of the different cultures we all belong to or varying backgrounds we have. Bringing different perspectives together creates awesomeness!
• Fun. Hello table soccer, hello mini-basketball, hello whatever the next of us brings on! We code hard, but we play harder. ;-)
• Community. Share your story, spread knowledge, inspire other teams! But also get feedback and support when you're facing challenges.
• People. Well, in the end everything is about the people. We're enabling people to experience the world. We have awesome people to do so. And we need more of those to tackle the challenges ahead.

Speaking of challenges, we're facing some where we need help on:

• Agile transition. Some teams embrace agile at their core since the beginning, others are just starting on their agile journey. It's fascinating being part of this change and being able to contribute to the bigger vision and creating our very own company culture!
• Close collaboration across locations. We're located at many large European cities: Berlin, Munich, Paris, Milan, Zagreb, Amsterdam, and still spreading. But this also means we have to find innovative ways to stay close to each other.
• Scaling our products. We are working on several products, some bigger, some smaller; but all shall gain strength.
• Growth. We want to grow: our teams, our products, our business! But still keep the agile startup spirit alive. To do so, we need your support!

We are searching for all kind of people to strengthen our development teams.

• Join! Are you eager to join an awesome team & develop great products together? Then check out our career page and current job offers! I'll be happy to answer any questions in advance.
• Feedback? Do you have any feedback for us how we could improve our recruiting? Please leave a comment or send me a direct message on Twitter.
• Tell :) If you know anyone else in your network who's ready for a new challenge, please spread the word!

Back On Track, Picking Up Pace

When talking to other testers, I love to hear where they come from and where they are heading to on their testing journeys. Listening to those personal stories I search for similarities I can relate to, as well as contrasts I can learn from, getting to know the person better at the same time. In a couple of posts I want to share some milestones of my personal testing journey with you. See also the related previous posts about My Roller Coaster Years, A Maze of Brick Walls and Taking a Detour. This post got quite lengthy, but as it's the final one in the series I decided to not split it to show the whole picture.

---

After my non-agile experience and my years learning about teams and system administration, you can't imagine how awesome it was to finally return to agile testing and product development! This post summarizes my experience at my current company so far, as well as feels like a wrap-up of my professional 2016. But let's start the story where it began.

As mentioned in my previous post, my "roller coaster" team comes together once a year to exchange updates and have fun together. At our reunion end of 2014, one of my former leads announced that he just started at a new company where he was about to build a development team from scratch, trying to form an ideal team regarding mindset, skills and bonding. I admit I was a bit jealous at that time; in retrospect, that was already a first hint that I had to change my situation. About half a year later, he asked me if I was up for talking about some challenges his newly built team faced. If I could imagine improving their testing, driving test automation and maybe taking over some DevOps tasks as well. I was intrigued! And after several chats with him I decided to give it a try. Met the team. We aligned. And agreed to work together.

End of 2015 I finally started my new job. I was a bit anxious about how it would be, especially as I was supposed to automate tests which I honestly had never done before. So far I was just playing around with Selenium and WebDriver and knowing some bits and pieces of Java and JavaScript - but I was eager to learn. I had laid my cards on the table, but they hired me nonetheless. And kept me. We agreed that I took over manual exploratory testing as first step which fit to my expertise. Then one thing led to another so that I ended up contributing in lots of different ways; to our product, our team, how we work, how we collaborate across teams and within the whole organization. I'm still eager to learn more about test automation and programming, but that's another story.

What happened in 2016?

• When I entered the team, they already shared responsibility for quality, with every developer writing automated tests and doing basic manual testing themselves. This was a great foundation for introducing testing from a tester perspective. They had some ideas about how it would look like. For instance I often heard "you can wait with testing, code review is not yet done", and "QA does testing after everybody else finished their jobs", like a gatekeeper for releases. However, they appreciated me sharing my experience. Like testing throughout the workflow, before any line of code is written by asking questions and continuing on production such as by reviewing logs; having many feedback cycles and shortening them; and so on. We iteratively defined how we want to collaborate and how our development workflow looks like. Tried things and kept what worked. The team quickly provided feedback that they see big value in having a person coming from a testing mindset contributing in many ways.
• Our Java development department grew heavily over the last year, we now have three teams and searching for more people fitting in. We made good experience with careful recruiting. Investing quite some effort mostly paid out for us, but sometimes we feel we need to speed things up not to lose great candidates to competitors.
• As the whole company grows steadily each month, we moved to a big new office. On the one hand we now have space again and the rooms are much nicer; but on the other hand we lost decent internet connection for half a year due to a mistake made when putting up the new building. You know, internet, this thing everybody in the company depends on? Tough time, we had to figure out how to deal with a mere mobile connection during this period.
• When the time came that my first team was settled, I additionally started in a second team introducing testing there as well. I quickly realized that both roles were full-time jobs. I learned a lot during that time, but it was quite stressful. I often had the feeling to only run after tickets instead of being able to think ahead of them. We were really lucky to find a working student who, although she is able to program and therefore could work as developer, explicitly wants to test. She does an awesome job and is a perfect fit to our teams. We're even luckier now that she started full-time after finishing university. Back then I knew the second team was in safe hands so I returned full-time to my original team in good conscience.
• My company went through a merger in 2015. The original organizations lived a very different culture and approach to development which often caused issues when suddenly collaborating. In order to become one unified company, we now started a global transition towards agile product development. Additionally, we set up our own flavor of a matrix organization with teams, chapters and communities, based on approaches of other companies like Spotify. As you might expect, this huge change currently causes a lot of turmoil, raises a lot of questions and has us face a lot of challenges. We all try our best to have our organization move into a direction we all support and grow a culture where we want to be part of. I'm curious how we will have evolved one year from now.
• When starting, I was the second person identifying as tester at the company. So we started our own little community of practice as a two-man show. With the agile transition and getting closer across different locations, we grew into a larger community where not only testers but anybody interested is welcome to join and share knowledge, experience and challenges. I'm really excited about this opportunity of company-wide sharing and learning.
• And last but not least, my company enabled me to attend Agile Testing Days 2016 for the full week - which was simply awesome! I did not experience this kind of support at other companies before and heavily appreciate the continuous investment in people development!

Throughout the year I learned several valuable lessons.

• You can do decent "Scrum" even if you don't have a dedicated Scrum Master. When I learned that there was no one taking over this role, I was skeptical but thought "let's see how this is supposed to work". I discovered that every team member took over some part of the Scrum Master role which worked pretty well. Still, I'm not sure who would have stepped up to moderate and mediate in case of bigger conflict within the team; but probably our disciplinary leader would have done so.
• I was used to have long sprint planning sessions with the first part discussing and analyzing the upcoming product backlog items to roughly forecast which of them we could tackle in the next sprint, and a second part of breaking those items down into detailed single tasks. Imagine my surprise when my first sprint planning ended after about 45 minutes! We simply don't do part two, but work on story level only. And discuss details just in time when we come to them.
• We have a team of full-stack developers. Everybody doing everything, just pulling in the next item and working on it. This really increases our bus factor! And it's just great to go on vacation without having work piling up during your absence! Only it's hard to find good people willing to take over all kinds of tasks, learning many new things. And we still have some specialized people knowing more about testing, DevOps and UX; but we're working on improving knowledge sharing in those areas as well.
• Our Product Owner is completely integrated not only within the team but also within the development workflow. When a first version of any backlog item is implemented, he already reviews it if it fits to his vision and expectations. The feedback cycle is kept as short as possible instead of waiting for a sprint review to accept or reject a feature. This procedure also increases transparency while working on an item. We really value this close collaboration with the Product Owner throughout the sprint.
• Within the past year I finally understood that it's not about reporting and fixing every issue we found, but about communication, collaboration and needs. Fixing some defects simply has no or too less business value as users won't ever come across them, so we close them unfixed. We rather invest effort in things actually providing value instead of wasting our budget.
• Our team is distributed as our Product Owner is located in another city. We learned that good conferencing tools and especially a decent internet connection is crucial for us. This had hit us especially during the period when we had to work on mobile internet connection only.
• Our disciplinary leader reminds me of my former one, being really open and supportive, always trying to develop you further. When he asked me for a personal talk two weeks after I started on the team, my self-doubts showed up again and I thought "oh my god what's up, it's probably about my lack of test automation knowledge...". And was so positively surprised to receive feedback that my contribution is already appreciated, how greatly I fit into the team and that it feels like I've always been a part of it. Wow! This instantly neutralized my biggest fears so I was able to focus on my work and put even more energy into it. I knew if something would come up, I would get timely feedback so I would be able to adapt. Psychological safety for the win!
• If you treat your working students well, they will stay. And so far, nearly all of ours did so. Some of them even quit their master studies to start working full-time with us. We integrate them completely in our team and collaborate on a level playing field. They do exactly the same as everybody else, sharing the same responsibility, learning a lot and bringing in fresh perspectives, receiving support whenever needed just like anybody else.
• But the best lesson of last year was the following: The mere fact of working for two teams created bottlenecks as the developers continued pulling in new tickets and the things to test piled up. Our situation got worse and worse. Why is this a good thing? Well, when the teams felt the greatest pain, it made everyone realize that our way of working did not work out. We were not able to deliver value to our users anymore, we just created more useless inventory, increased waiting times etc. Everything took longer. Both teams admitted that we needed to adapt. So they agreed to try the simple approach of "stop starting, start finishing". We agreed that it was not allowed to pull in new tickets before you really were not able to contribute to items in progress anymore. Sometimes not even then, just to not increase the work load. But if there was anything to do, be it support with development, reviews from business, code or testing perspective, everybody swarmed to help out, no matter what their original "roles" were. And suddenly there were no bottlenecks anymore! Even after our new full-time tester took over my second team, they really learned their lesson and continue to swarm to finish highest priority items first before starting new ones. Teaching and supporting each other when testing or doing anything else they do not specialize in. I'm really proud of them, they showed what collaboration and a whole-team approach means.

What about our current challenges and the outlook for the new year?

• While I had been running after tickets, I hardly found time to prepare test cases upfront of implementation and discuss them with developers and Product Owners. In the end this often caused delays as expectations differed and questions were raised quite late. We're just returning to shorten the feedback cycle again and having those discussions guiding development.
• When testing for two teams, I was not able to invest much time for conceptional work, thinking about test strategies for our product or trying new tools and techniques. Now having more time again, I want to run more experiments, try new approaches and see which work for us. In addition I'd love to increase efforts of knowledge and experience sharing on team, company, local and global community levels.
• Our team needs to get to know our users better, who are collocated with our Product Owner. We plan on-site visits to learn how they actually use our products and what their pitfalls, challenges and needs are. Actively include them in our sprint reviews. Same goes for our stakeholders. Currently communication is only channeled by our Product Owner which sometimes makes it hard to understand why priorities change or to come up with new ideas for our product.
• On our agile journey, we have to find new communication channels within the company and grow a common culture, to finally feel as one big organization. Besides that, thanks to this transition we now finally got a dedicated Scrum Master for our team. Even when things are going well there's always room for improvement, so let's find out together!
• Our team office needs to become more lively. We're now finally hanging up cartoons, getting a large screen TV and discussing how to breath life into our everyday environment! To make it feel less like a "getting work done" place and more like the creative fun area it is. And attract more of those awesome people. Speaking of which, we are still growing. To do so, we have to spread the word that we are a tech company with great offers, but especially with great people to build the world together!

Dear 2017, let's get started - I'm curious what will be the next lessons to learn!