Thoughts about Testing in a Mob

Worked on a large, complex story as a mob, from start to finish. Awesome team experience. PROUD. Time to celebrate! #mobprogramming #mobbing

— Elisabeth Hocke (@lisihocke) 12. Mai 2017

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.

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.

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.

Facilitation

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.

• Book: "The Mob Programming Guidebook" by Maaret Pyhäjärvi and Llewellyn Falco. This was our major source of wisdom. You'll find invaluable advice here, especially for beginner facilitators to get started.
• Conference talk: At Agile Testings Days 2016 I attended the talk "Swarm – Beyond Pair, Beyond Scrum" by Danijel Arsenovski. You can find the teaser video as well as his slides online.
• Videos:
• "Mob Programming, A Whole Team Approach" by Woody Zuill
• "Learning programming by osmosis by Maaret Pyhäjärvi" by Maaret Pyhäjärvi
• "Microservices Manchester 2016: Mob Programming by Alison McGreavy"
• "A day of Mob Programming" and "A day of Mob Programming 2016", great time-lapse videos of teams mobbing throughout the year
• "10X" by Llewellyn Falco
• Blog posts:
• "Mob Programming – My First Impression" by Andrea Angella
• "The mob rules, ok?" by Steve Tooke
• "Mob Programming" by Dave McNulla
• "Ruining the life of the introvert" by Maaret Pyhäjärvi
• "Your choice, explorer!" by Maaret Pyhäjärvi
• "A chat about banks" by Maaret Pyhäjärvi
• "A Mob Testing Experience" by Maaret Pyhäjärvi
• "Amplified Learning with Mob Testing" by Maaret Pyhäjärvi
• Podcasts:
• "Mob Programming with Woody Zuill"
• "Maaret Pyhäjärvi explains how the whole team can work together"
• "We talk all things Mob Testing with Maaret Pyhäjärvi"
• "Episode 36 – Maaret Pyhäjärvi on Testing Software"
• Several tweets from a talk about mobbing given by Mark Pearl at SUGSA

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!

Mobbing

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? ;-))

Stop Starting, Start Finishing

In a previous post I told the story of how we reduced our bottlenecks when I was working on two teams last year, and how we achieved to deliver the highest priority items first to our users. How? Both teams agreed to "stop starting, start finishing". To not pull any new story before you could not contribute to in progress stories anymore.

This lean approach worked so well! Unfortunately only until I handed over my second team to another tester. As soon as I returned full-time to my original product, the whole team fell back into old habits, starting work on new tickets while other tickets of higher priority were still in progress. At one point we even had a totally underestimated story which turned out to be an epic of its own; we dragged it from sprint to sprint and heavily struggled to finish it. Not that the team members did not want to support, but support was only provided on demand. With "on demand" meaning that you had to actively ask for it.

Beginning of this year, we faced long feedback cycles again. Too long for our liking. New features waited for input from our Product Owner. Code waited to be reviewed. Topics to test piled up. The situation wasn't too bad, but we felt things could be much faster and we generally should avoid to have half-finished tickets lying around, not providing value to anybody. So what caused this situation again? Sometimes the long waiting times were due to the fact that many of us are also involved in company-wide topics of our FlixTech organization, for instance to support our new chapter structure or recruiting new team members. At other times people just grabbed new topics to work on; not having bad intentions, but just being eager to work on something new.

In our sprint retrospective two weeks ago, we brainstormed ways to shorten our feedback cycle again. And came up with the same well-known approach which had already worked so well for us last year: Stop starting, start finishing. Whenever you finish something and have free capacity, ask the whole team if you can support someone else with their current work. Only if you really cannot support anybody, pull a new ticket. And now actually adhere to it!

The past sprint proved once more that this whole-team approach is highly valuable. The sprint went so smoothly, tickets never waited long for feedback and could be delivered to our users as soon as possible. We completed all of our highest priority topics and even many more smaller items on top. Team collaboration felt great and everybody was really supportive. It just worked; even though I could not cover testing for a whole week due to a lot of other important topics like recruiting interviews and the two workshop days with our users (it almost felt like I've been on vacation). My programmer teammates took over testing thoroughly, asking me for advice whenever needed, but proving they already learned a lot about testing. Simply awesome. So proud.

Maybe it's too soon to be proud, as we only adhered to this approach (again) for one sprint. What makes me think that this time is different is the following: No one waited for someone else asking for support. Everybody actively asked if they could support anybody and readily provided that support until the related ticket had been finished. We all agreed that the sprint went really well and we want to stick with this approach. I'm full of hope.

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!