A Triple Mob Achievement

If you've followed my blog so far, you know that I'm an ever-growing fan of the mob approach. Today I have three achievements to share, all related to mobbing.

#1 - Getting Invited to Mob Programming Conference 2018

Yes, exactly! Two days before New Year's Eve, Llewellyn Falco contacted me and asked me whether I would be interested and available to be a "moberator" at the Mob Programming Conference in April 12/13 in Boston. This opportunity absolutely intrigued me! Not only that I'm really convinced of this whole-team approach, this was also the first time someone invited me to a conference as a person, without even discussing potential sessions beforehand. I was (and still am) really feeling honored to get considered. So I checked the conference page and saw that the selected guest mentors were really experienced in facilitating mob sessions. In my case, however, it would be my first time doing so outside my company. This made me uncertain whether I would qualify; however, I told Llewellyn I'd love to learn by doing. And what did he do? He instantly referred me to the other organizers Nancy Van Schooenderwoert and Woody Zuill, who officially invited me. After having a first call with them, discussing potential sessions, I finally believed that this was really happening so I made it public myself.

I got invited to the #MobProgramming2018 conference! Absolutely honored and excited to share and learn more about #MobProgramming. Hope to see you there! :-) https://t.co/B7gxJkXE3L

— Elisabeth Hocke (@lisihocke) January 15, 2018

I'm so looking forward to this event and would love to see you there as well!

#2 - Feedback from My Team

Throughout the last months, my team had and still has frequent mobbing sessions. We currently work on a huge topic where this approach is invaluable for us. We have to make sure that everybody is aware of everything and shares the knowledge to avoid bottlenecks in the future. Last week my team had a retrospective. We were talking about things we want to do better in the new year and also brought up the desire to further improve our mobbing sessions. In the course of presenting ideas what we can try, the following discussion came up. I was so happy about the reaction of my developer colleagues that I had to share this with one of my Slack teams, the Women in Testing group, where we have a special #brag_and_appreciate channel to practice bragging in a positive way and to celebrate each other's achievements.

Furthermore, my teammates stated that mobbing might be expensive, but for learning it's the best way they've seen. I cannot agree more.

#3 - Mob Testing Workshop with My Community

Maaret Pyhäjärvi gave a wonderful mob testing tutorial at last year's Agile Testing Days. It really inspired me to try this with my company's testing community as well, in a shortened form focusing on exploratory testing only. Yesterday I finally had the chance to introduce our testers to the mobbing approach.

Hosted a #MobTesting workshop for our company's testing community today, based on the tutorial @maaretp gave last #AgileTD - had so much fun, learned a lot and grew closer together! #MobProgramming #Mobbing

— Elisabeth Hocke (@lisihocke) January 18, 2018

It was a lot of fun to facilitate this session and I learned a lot again. We had a tester joining from remote, and another one who had to skip the middle part of the workshop, only being able to attend the beginning and the end. Still, we managed to integrate both well without causing too much disruption.

Before yesterday, we testers already worked together on several topics, like recruiting, building a career path, hosting meetups, and so on. But this workshop was the very first time that our testers actually tested an application together. This made it really obvious how different our ways of approaching a task are. As an example, after getting past the initial practice round, we had to spend quite some time to find an intermediate working agreement just on how to document our findings.

You can imagine that I was all the more happy to receive the following feedback from some of the testers attending the workshop.

I'm absolutely looking forward to our next testing sessions together! We can learn so much from each other this way and help each other grow. And last but not least, whenever we face real-life testing challenges concerning our products, we now have a great approach at hand to get the best out of everyone.

If you'd like to learn more about how mobbing can benefit your testing efforts, make sure to check out Maaret's recently published Mob Testing: An Introduction & Experience Report.

How My Colleagues Made My Day(s)

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

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

Then a colleague approached me, asking me how things were going, how the preparations for my upcoming conference talks were coming along. I shared that I was in the middle of it and that I was getting a bit nervous already, and then she gave me this:

Just received this awesome unicorn from a most awesome colleague, as support and encouragement regarding my public speaking endeavors 💜🦄 pic.twitter.com/F9mFm94iyN

— Elisabeth Hocke (@lisihocke) 24. Juli 2017

I was really blown away! This was so unbelievably nice of her. My new unicorn found its place at my desk and will now always remind me of her belief that everything will work out well. Hopefully it will also trick my own brain into believing this myself.

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

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

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

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

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

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.

Taking a Detour

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 and A Maze of Brick Walls.

---

After ending my outsourcing experience I was thrilled to join the very first Scrum team of my company! I had three options back then:

1. Leave the company and look for a new job;
2. Stay with the company and be test manager for other short-term development projects, including a lot of traveling;
3. Stay with the company and join our first Scrum team working remotely for a long-term customer but doing much more administration, operations and support than development.

Everybody wondered if the third option would meet my desire to develop and test a product. But as I liked the people at my company and really wanted to change from external on-site projects to an internal team and especially return to the agile world, I nonetheless took it.

When starting on the team, I quickly realized that how they were working so far really was not quite related to Scrum. Or agile. I found myself to be the only one who had worked in a Scrum team before, which triggered me to take over the Scrum Master role. What smoothed our way was that my team lead trusted me from the start. He knew me from my time as a working student and it seemed I had left a good impression. When I made my first steps to teach Scrum and coach my team, he told me several times that he didn't quite understand why we should do things this or that way, but he kept putting trust in me and give it a try; and afterwards realized the benefits.

The following three years of transforming and growing our team taught me several lessons.

• People need time to change. In the beginning I wanted to go like a bull at a gate, but quickly realized that I would lose my team on the way. What worked for us was promoting change in tiny bits. During our first year we rather blindly followed the Scrum framework, setting the stage. The second year we didn't have to think about the basics anymore and could adapt some good practices, gain pace, share how we work with the rest of our company. Only in the third year the team was ready to break some habits, try lots of new retrospective formats, challenge how we work and find our own way of working.
• We faced several challenges as a distributed team with the major part of the team being located in Germany but having team mates in Romania and Brazil. We had to find ways to overcome communication barriers caused by distance, time zones, languages, cultural backgrounds, tools, technical issues. To get to know each other, build up trust and feel like a team.
• We learned a lot about team dynamics. As we slowly shifted to an agile mindset, some team members did not want to self-organize or take over more responsibility, so they left the team themselves. Also, chemistry within a team is crucial, but so are skills; in the end we only were three people left, but as we could nicely complement each other we could still deliver value for our customer. We had a hard time searching for new people fitting to the team, bringing useful skills and especially sharing our mindset.
• We worked for only one big customer and were able to grow a close relationship, not only on contract level but also connecting with the humans. The foundation for this was our authenticity and openness about what can be done and what not, our transparency when it came to progress updates and failure root cause analysis, and the quality results we delivered. Our customer heavily appreciated our collaboration and put a lot of trust in us.
• I personally learned a lot about system administration, operations, and third level tech support. Our customer's management showed high awareness that the application was always up and running, 24/7, throughout the year; so we shared standby duty. Here I really learned what it means to be woken in the middle of the night by some monitoring alerts in order to rush to the computer, log in to the client's system, stay calm and troubleshoot what happened. We learned to have our system as stable and reliable as possible to avoid such incidents; however, network or data center outages would still stir us up.
• Trust and support can create magic. My team always had the back of my team lead. We had many open and honest conversations on a level playing field and learned to appreciate a lead who listens, supports, gives and takes feedback, strives to develop you, trusts, cares.
• To spread the word about how we work and how others might improve and become happier as well, I started to share my knowledge, train, coach and support other teams in the organization. The teams loved it, but upper management was not happy about that at all. My desired "bottom-up revolution" did not work out, I realized you need to include all hierarchy levels, otherwise you might put people off. So I tried to get upper management on board as well but sadly it seemed we continued talking at cross purposes.
• As I was new to my Scrum Master role, I started to read and learn a lot about Scrum, agile, and teams; I could also correct some misconceptions I had. I made it a habit to learn something everyday and hone my craft. This proved invaluable as it gave me so many more options and ideas. If you'd ask me before, I would have never believed that I would voluntarily do so much for my profession in my free time as I do today. I'm still surprised how sometimes I cannot let go of reading just one more blog entry.

In the end I got tired of running into walls within my organization. Furthermore, I found that I had developed in several directions but somehow detoured from my testing path. So I did my usual check - and realized that I cannot see myself one year from now at my company.

Adhering to what I promised myself, I told my team about an awesome offer I received that I wanted to take. I did that on my own risk. My team was really sad but highly appreciated my honesty so they could immediately prepare for my highly potential leave and invest more effort in searching for my successor. But others unmistakably told me that they disliked my action, that I unnecessarily stirred up my team. Well, even if I would not have received this offer, my personal decision was made; I would have left anyways. After three years helping to build up this team and enjoying all ups and downs, it was quite hard to leave people behind. But my team mates told me that I could not let my loyalty infer with my personal growth and that at this point I had to think of myself. Wise words.

I never regretted having taking the offer. Plus, I didn't lose the people. We're still meeting each other in our private time, just like I do with my former "roller coaster" team. I love to keep in touch with people I shared so much with, to see where their ways led them and to learn from their experience. In the end, it's all about the people.