Wednesday, July 27, 2022

A Time of Transition - Eight Months on a New Team

It's been eight months now that I'm at my new company, on my new team. Beginning of the year, I've shared my observations on the first months and my onboarding experience. Now that I've been here for over half a year, it's time to look back and reflect on what happened so far. Brace yourself, there's a lot to share.

In the following I'll be reflecting on my own team's context and transition. My team is usually my home base to operate from across teams. It's also where I deliberately put my focus on for the first part of my journey at this new company. We've already been through many challenges together, we've grown a lot, there's more change ahead, and I'm still having good reasons to stay at the company and move in better directions together.

Now, besides my team, there's a lot more to say about my first impressions and experiences at the company. On the one hand, there's the quality engineering guild with so many knowledgeable people I'm still honored to be colleagues with. We had great interactions so far, though not as many as I'd love to have yet. I mean, imagine the possibilities! On the other hand, there's the rest of the company with lots of more amazing experts of all areas. Like our infrastructure people, our medical doctors, our security experts, and many more. It's been a pleasure having our paths overlap already - again, not enough for my taste yet. And still, the focus on my own team was an intentional choice and I still feel it's where my attention is needed most. Which brings us to this post about the transition we went through together in the team: looking back to where we started, what happened, where we are right now, what helped on our way, and what the future might hold.


Where did we start?

It's always good to look back and see where we started out together. Without intentional sugarcoating, just as I've experienced it. In hindsight, some of my initial observations became stronger with additional evidence, other realizations only came over time. Please note that it's about people here. People who wanted to do a good job given the circumstances, people who have my respect. We'll see later how things changed and what impact this had, yet let me first paint the situation as I've observed it.

  • Solo working as default. I've experienced this as quite a contrast to my previous team. When joining this one, people could not really relate to me speaking about "pairing" or "ensembling". I realized they just never experienced effective synchronous collaboration. Everybody just did their thing, then considered it done and handed it over to someone else. I joined a team by name, yet did not encounter a team by spirit.
  • Limited communication within the team. I've seen people share a few sentences once per day during our daily. I saw only very few messages sent in the team channel or directly to me. I did see a few pull request comments from half the team. Whenever there were team calls, many people were completely quiet. That most people had their video turned off all the time did not make it easier. Yes, there are valid reasons why people don't turn on their camera, and I don't want to force anyone - yet it does make communication and building relationships harder for me.
  • Knowledge silos, gatekeeping, non-transparency. Oh my, this was a tough landing. I've seen people not share information with each other that definitely could and should be shared. I've seen the same with knowledge or any kind of learning. I've seen it with permission and access, be it for tooling or invites to meetings or channels or anything. At times, people were not only not involved, yet being actively kept out of conversations. Usually, there was only the one person who you depended on to get anywhere - yet you first had to find that person. You can imagine that people did not know the whole system they were working on. You can imagine the knowledge loss when people left the team. You can also imagine there was lots of misunderstanding and unrealistic expectations towards each other, as there was no shared understanding on a team level. You can also imagine that people did not like sharing their own work in progress before they considered it "done".
  • Expert role thinking. I've seen people treating each other very differently based on the role they identified with. I've seen them retreat to their own box, and shift tasks or responsibilities towards others once they did not fit perfectly in that box. I've seen "that's not my job" attitudes and other defensive patterns. This group felt at times like a conglomerate of sub-groups of individuals based on expertise or identities, like the "backend people" and the "frontend team".
  • Inaction, not daring to make decisions. I've encountered this over and over. I was coming from great environments where I learned that most of the time it is okay to go ahead without formal permission and rather ask forgiveness afterwards (while always considering impact upfront). Here, I encountered people who turned in circles over and over before daring to take action - if they took action at all. Let's rather have someone else make the decision or give us permission. Let's wait for someone else to make the first move. For everything, even very little things within the pure scope of the team. You can imagine that there was no experimentation going on or any tangible improvements to be seen.
  • Being pulled in various directions. There was no clear vision for the team or their product, at least none I learned about. Instead, I've seen the team being torn in various directions by various stakeholders who lacked understanding of the complexities of product development. Expectations were left unmanaged and I did not see any clear communication in place. Frustrations built up as people outside saw the team did not deliver things to the end, while the team was frustrated that before they could finish something they got pulled on to the next big thing.
  • Boundaries being crossed. Some people were super mindful with boundaries, and I celebrate them! Yet truth be told, I've seen the very opposite behavior with other people and this takes a toll. I've seen the team being asked on a late Friday evening to get results for early Monday morning. I've been myself in calls the whole day and being asked in each call to do something right away - yet when? Of course, the super urgent "whatever it was" was not being needed at all, or not being followed up. Expectations were unrealistic and definitely not healthy or sustainable. We lacked breathing space. I definitely did. I felt the need to push back heavily and make my boundaries overly explicit with some people, while trying not to fall back into my own personal pattern of being a people pleaser.
  • Blame shifting. This was maybe the most unfortunate, yet it explained lots of the defensive behaviors I've seen. Anyone made a mistake, any failure - and the blame game started. Be it across roles in the same team, or across teams - it's always the other one. No wonder why people came up with coping mechanisms, retreated to their own little safe places and did not dare do anything they might get blamed for.
  • Bad team reputation in the company. Another very sad thing I've heard from different people, even before I joined in. Their history (or rather their historical outside perception) wasn't shining a bright light on the team. It seems lots of communication issues across teams occurred. People expressed frustrations with the team introducing changes that broke things for other teams. People complained about all the perceived issues with the product. When joining the team, I did not find too much evidence to support this, yet once a team has a certain reputation it's going to take effort to switch this around.
Suffice it to say, I've encountered a group of individuals who tried their best working in this situation. They tried to help and support each other according to their knowledge and experience, given these conditions. Suffice it to say, I thought they deserve better - me included. So, let's shift this narrative and craft our own. But before that, let's add more details to the picture and also have a look at how testing and quality was considered in the team.
  • Throwing it over the wall. Automated tests were in the realm of the developers, yet anything else was "moved over the wall" to the dedicated quality engineer on the team. It was even considered a phase in the workflow. At this point changes were merged into mainline already, developers moved on to their next topics and feedback loops took really long. Little to no collaboration across roles could be observed. Later on, I found out lots of reasons, from not understanding what testing is about to developers not daring to test themselves, fearing they might miss important things.
  • Skipping backend testing. Changes on backend side often slipped through the cracks and were just moved to "Done". Well, you can imagine people were surprise about changed behavior. You can also imagine that avoidable bugs escaped to production.
  • Lack of foundational knowledge. Due to the knowledge silos and lack of sharing, people were not aware of things that I previously would have considered essential to the very task. They simply never had or took the opportunity to find out, and there was no incentive in it for them to do so either. I'm talking of knowing how to run your services locally, or calling the API of a deployed service. And these are good people - they just weren't aware of their options or sought to find out what's possible. Many even had been told it's not possible and it stopped there.
  • Testing only integrated states. As testing was coming in late, people only ever tested the integrated system. Sometimes this meant lots of changes combined already which in my experience makes it hard to detect problems, pin them down and relate them to their root causes. It's way easier to go in small steps and first see how the small change in a single piece behaves in isolation, before you put the pieces together and look how they behave together. 
  • Poor testability. Wherever I looked, things were hard. Harder than they needed to be. Time to find out how to make it easier, so it's also getting easier to spread the knowledge. Yet at the beginning, no one looked into making testing easier, they either thought it's not possible, or not worth it, or did not have capacity or the needed reward to invest in it (yes, similar to above). Instead, let's go the way of least resistance for now and either not test at all besides automation, or test the integrated state. Yet even there, we had poor visibility into what's actually going on.
  • Starting over finishing. As people were focused on their own piece of the work, and once it was done for them, they considered it done overall. Guess what? People continued starting new topics. All the time. Didn't hurt them, right? Yet when starting a trillion things and not following through to the end, you will end up with a huge queue and block yourself. Developers might have three topics to juggle with themselves in development, and maybe one or two to review - which is already a lot yet might still be okay for one person. From a dedicated tester's perspective though, this is a nightmare. Five developers each having their three topics going on means fifteen topics to switch context between for you. And lots of ping pong. Forget about throughput and flow, let alone fast feedback.
  • Poor observability and monitoring. Knowing or rather not knowing production was one of the first things I realized. If issues occurred, they were not easily and quickly spotted. Investigating issues was not straightforward yet complex. Responsibilities were unclear as well; who even responds to the people raising our awareness to problem reports?

I guess there's always more to share, yet this should give you the context where we started from to understand the transition the team made.


What happened?

So many things took place in the last eight months. Here are a few highlights of our journey together.

  • Team changes. First of all, the team I started in is not the same anymore as the team I'm on now. Five former people left, two contractors joined and left within this period, four new permanent people joined. It's been an overly huge team when I started out, now at ten people it's still at the very maximum when it comes to team size from my perspective. Communication pathways are already very complex.
  • Finding a dearly missed product manager. The team had multiple, frequently changing product people before and suffered from it. Now we got really lucky and found a wonderful product manager who is all up for transparency and knowledge sharing and always involves the team. Someone who sets clear priorities and gives the team focus. Someone who sets clear expectations with stakeholders and also shields the team from unhelpful organizational issues. Someone who makes quick informed decisions, instantly takes action and leads by that. I cannot overstate enough what difference this makes!
  • Rediscovering how to release. Knowledge got lost, and even such crucial knowledge as how to even release. Yes, that hurts. Given we have to consider compliance for very good reasons for our product, this was no little effort to figure out what's needed to get a new product version to the market. As the rediscovery phase took long and lots of changes queued up, it was a huge release. We all wanted to practice this more often and have smaller releases with less risk. With each following one we learned more about how we can make it easier, and we're still learning. Yet now we have transparency, the whole team is involved and enabled to do releases.
  • Team canvas session. This was initiated by our new product manager and was what the team needed at that time. A place to share what's important to us, where we want to grow into, what opportunities we see for our product, our personal values, and more. A foundation for the team to build on. As an outcome we now also have made our team values explicit. This way, we have a great reference for us to live by and also for people outside the team or joining the team to start with.
  • Huge epic. Beginning of the year, the team was made aware of an upcoming topic. When I heard of it, I instantly knew this will mean a gigantic effort, while observing lots of expectation mismatches (even down to "we'll do this in 2-3 weeks" - no way). In the end, it was a gigantic effort indeed! We're in the finishing touches now, yet this was huge. It was so huge, we had to literally drop everything else in order to make this happen. Kudos also here again to our product manager setting expectations very explicitly.
  • Extinguishing lots of fires. The time from March to June was a bit extreme. Lots of super urgent topics that all had to happen at the same time created lots of pressure. All while we also already worked on that huge epic. I think we only got through thanks to trying to tackle one thing at a time and our new product manager really stepping up. Can't emphasize this enough - she's seen the worst in her first month and is still with us! So, to see the positive here: this was the opportunity to set clear constraints and manage expectations, share the situation with other teams, get their understanding and support. I really felt this was a moment which could either break or make the team - and we ended up on the good side, the team really grew closer together.
  • My first time away from the team. I deliberately declined conferences and other endeavors within my first months, yet at some point they were coming. I knew up to this point, I needed to have the team enabled to take over testing themselves. They have the full context, anyone external would end up in the situation I was finding myself in when I started, it's not worth it for a temporary period - and also it would have reverted lots of the culture change we've been working on.

At the same time, we had lots of other constructions sites and room for improvement in the team. After the first month of observing, building relationships and growing my knowledge, here are the initiatives I ran within the team.

  • Onboarding and offboarding guidelines. Already in my first month it became clear that the team lacked shared knowledge, it was a rough start. As I had to gather the information bits and pieces anyway, I revised the existing onboarding page to a guide to help the next ones joining. Documentation itself was only half of the story, the other half was the mindset how to meet a new teammate, how to make them feel welcome and taken care of. Just last week a new person started in our team. Based on their feedback, it seems we're doing things a lot better already! Now, as much as there will always be new people coming, there will also be people leaving. That required a guideline as well to make sure we not only have a good last time together, yet also to handle permissions and set up the new team for their own future.
  • Making knowledge common. This ranged from sharing knowledge while collaborating, to sharing what I learned in the team channels, to writing "how to" documents. I quickly realized people really appreciated knowledge sharing! They also wanted to have fun together. Hence, we introduced a bi-weekly "knowledge & games" session where we took the first half to share whatever we learned, as informal as it could be to lower the barrier. The second half was reserved for games, whatever we were up for on that day. Already in the first sessions, I observed lots of aha-moments! During the high phase of the epic, we observed less knowledge sharing and more games, yet it was one the few things we did not stop. Now, we also see the sharing part being revived again, which makes me happy.
  • Issue handling policy and issue investigator of the week. One part of knowing production was to know how to deal with reported issues in production. The company had a guideline overall, yet it was not actionable enough for the team's context. I made good experiences in the past with having an explicit policy in place, so that's what I tried here as well. I made a proposal, I requested comments, we walked through everything together in a call, we all agreed to it. And we live it. Part of the policy is that we make quick decisions and not allow issues to hang around in our backlog, rotting away and just representing waste. Another part was quick response time to issues that we either identify ourselves or that are brought to our attention. Now we have a rotation in place, every teammate taking a weekly turn as "first responder" (or "issue investigator" as we call it) to evaluate any issues and then handle them according to our policy. At first, the team was not really comfortable with making calls like "we won't fix this, it's not providing enough value" and reflecting this decision in the ticket status by closing it. If it's not worth working on right away, however, then let's rather face the truth we won't tackle it at all unless our knowledge about the situation changes. If things are more important than initially thought, they will surface again. Ever since beginning of the year, you can see not only a clean issue backlog (some old issues had gathered dust there for three years), yet also quick decisions, important issues actually being fixed, quick responses to new incoming ones, and a lot less weight on the shoulders of the team. There's a lot more clarity now.
  • More cleanups, more transparency. As the issue backlog cleanup was so successful, we decided not to stop there. We also cleaned up the rest of our backlog, closing old epics that hang around, outdated tickets and more. Absolutely freeing and also providing more clarity. Great timing as well, just before our new product manager joined. We also cleaned up our wiki space - so many outdated documents! Also here, nothing got deleted, yet pages got moved in an "Archive" section and hence the rest of the wiki is now lean, up to date, accessible and manageable again.
  • Shaping the system to include everyone. For us it was crucial not only to pull single people into conversations actively, yet to have things accessible and visible from the start so people can make their own choices. For example, having all team related calls on the team calendar. Little thing to do, massive improvement in team culture! Or having one call link always available where everyone can join in and work together or alongside each other like in a physical team room. This way, I also overheard lots of conversations I wouldn't have access to myself otherwise. Or dissolving other systemic silos, like granting permissions to all needed tooling to all team members alike, independent from their role. Fostering a culture where people outside the team reach us through a common team channel so that we all see it and all can respond, instead of having individuals as single contact points and hence bottlenecks. Makes a huge difference in sharing load and increasing resilience, as well as in shared ownership and a feeling of team responsibility.
  • (Re)Discovering ways to collaborate for flow and fast feedback. When I started out, I realized the people on the team did not have any connection or understanding what I refer to when I speak about "pairing" or "ensembling". I understood they were working very asynchronously as well. Therefore, I tried to meet them where they are and at first collaborate very closely in an asynchronous manner. Working the board from "right to left", providing feedback on the items farthest in the process first and then working my way closer to what my developer teammates worked on right now. I added my findings as comments to the ticket as they couldn't oversee them this way. I used Slack heavily to ask questions or share insights. I tried to be fast and basically overtake them so we could work "side by side", being quick in any asynchronous manner. This worked nicely and people started to see what I meant with fast feedback as they experienced it! I also stopped talking about "pairing" and instead started to catch people in our daily calls, asking them "can you stay on for a moment? I'd like to show you something". Sharing screen, demonstrating where I had questions on or what I found, and then continue interacting with the system during the call. Demonstrating the benefit of looking at things together, making it easier to understand what's going on. At some point, an early adopter turned this around. He asked me instead if I could stay on the call. This developer wanted to share the current state with me and actively pulled my feedback on an early iteration. He had realized this shortens the feedback loop and he can move faster! He continued asking me for pairing sessions from then on. He even said maybe he should wait with merging. Maybe we won't need the "testing" column anymore in the future. Big win! Especially as he lived this in front of the others. I had my early ally already advocating for new ways. This grew to me pairing with each and everyone. Having them pair with each other as well. Having small groups work together as ensemble. People pulling in more people on demand. Sometimes just working side by side, yet more and more often together on the same thing.
  • Living continuous holistic testing. Not only speeding up feedback throughout delivery, yet also testing all kinds of pieces, from ideas to logic units, from mockups to automated tests, from documentation to architecture. Testing earlier and earlier, smaller and smaller. With trying to overtake people to meet them where they are or even before they picked up a new task, I naturally started testing smaller iterations and smaller pieces. I was used to that from my past teams, yet no one on the team experienced this yet. Some people on the team felt it's a waste of time or not the correct approach in their minds. I decided to just do it (as so many times) and let them experience the benefits. And they did! Nowadays, I finally can even join them when implementing a change or any other activity. In the first months, though, I was already content with joining efforts on testing only. I also made a point to brainstorm test ideas before people picked up new work planned for the sprint. Again, meeting them where they were by simply leaving comments in tickets and making people aware, asking for their thoughts, using them as conversation starters, and moving on from there.
  • Solving testability problems. By testing earlier, I came across lots of things that made it hard to test. Discovering solutions that were good enough, then building on them helped massively. For example, understanding how to run things locally as this right now provided most visibility under the hood. Or improving readme files and creating Postman collections for an easier starting point. Or using Wiremock to stub out external dependencies and explore more of our service's behavior. Or using other tools to gain more insights while testing. Also creating "how to" guides to document this for others as references. Yes, all that at the same time was a massive endeavor, and I really drew a lot from my past experience. Honestly, starting at a new company validated the experience I gained over the past six years heavily. Nowadays, I feel a lot less like an impostor. There's still a lot more we can do to increase testability, and I have lots of ideas - yet capacity is limited and I have to choose carefully what would have the most impact and not run too fast for the team to follow up with change.
  • Stop starting, start finishing. Luckily, I was not the only one repeating this mantra. Product and engineering managers joined me in this constant preaching. Preaching alone does not help, though! You have to lead by example, taking actions, making clear calls. Setting up the system to reward "finishing" behavior. Only when people experienced the pain themselves it got easier and they started to think first where they can help each other before they started something new. Well, some weeks were better than others, yet we're all human. Especially when pressure is on and we feel stressed, it's so easy to fall back to old habits. I see that with myself over and over again. Nowadays, the flow is a lot smoother and on most days we have a lot higher throughput than before. What helped here as well was that we had clear focus on our huge epic, clear priorities, and this approach was very clearly supported by our product manager. Focus really helped to get everyone not pressing ahead on their own yet to collaborate closely.
  • Enabling the team to test. Having each teammate now experience pairing sessions with me and practicing testing together with me (including documentation), they learned more and more about the whole system, what to look for, how to do it. Also here, I tried something that had helped me with past teams: I created a generic testing guideline. It always helped me personally not to forget about specific things that are important in the context, and I learned it helps others as well, especially if they are less practiced in testing. We don't have to re-invent the wheel! Also here, it proved to be a nice reference for people to think of when I would not be available. As it happened, I was off the time for increasing periods of time. At first, I was away only for two days. A few weeks later, for a whole week. Shortly after, for over two weeks. People really knew what's coming up and realized they have to step up, they can't just let things slide if they don't want to fall back massively. What happened? The first two days, the early adopter developer made a heroic effort of covering testing all by himself. He mimicked a lot of what he's observed with me, it was amazing to see! Yet it was a lot and all on him. The second time around, the team struggled and rather favored working on new changes over testing others. Tickets piled up waiting for feedback, and they experienced the pain and friction themselves. When I returned, it also took me the next two weeks to get back to a clean state together with them. Well, it was expected that people struggle, they've never done this before. And finally, my longest off time came - and they managed super well! I came back to an up-to-date state, could calmy start without pressure, things were taken care of by three of my developer teammates this time. Absolutely amazing outcome! I've seen teams successfully taking over before, yet never so fast so well. Super proud of them.
  • Doing releases as a team. When rediscovering how releases were done, I documented the single steps in a "how to" guideline. Then we started sharing this knowledge across the team. For our previous release it was the first time all teammates available on that day joined in with release testing together - massive improvement! As all of them now are also experiencing the friction in our current release process, they got inspired to find better ways, make it less tedious. Our current release has now been done without me being in a leading position, I'm just being consulted when needed and obviously I'm still there to support. This is a huge step again for the team!
  • Fostering cross-team collaboration. For the huge epic we're working on, it requires lots of teams. A great opportunity to establish and learn how to work well together across teams, including testing together! Absolutely nice to gain empathy, learn about the system as a whole, get to know the domain better, and especially also create relationships. Another topic: we showed up as a team during incidents that also required collaboration across teams. People suddenly saw our team in a different light, they saw us collaborating closely and constructively in a stressful situation. I bet it gained us reputation points or at least made people reconsider their viewpoint. We also had lot closer communication and collaboration with people from other specialties, like infrastructure services, customer experience, medical knowledge. Creating bridges and bonds here, always trying to be as transparent, constructive and helpful as possible. Learning which dependencies we have, who needs to be informed about what and be proactive about it. We've now also seen people actively reach out to us asking for how we work and pulling knowledge.
  • Knowing production. This is still a huge topic for us. It was one of my first ones to start with, and also one of the first to sadly be interrupted during the hot phase of our huge epic (I know, what a contradiction - just when we needed it most). I invested in learning more about our current infrastructure setup, our tooling to see what's going on, started to clean up and filter out noise to see the important parts we needed to act on. Before trying to create good practices in the whole team, I implemented a daily habit for myself to see what's actually going on on the only system that counts in the end - production. I discovered issues this way that we fixed which was a promising start. Then it came to a halt, just keeping the status quo without improving further. Only now we all can pick it up again.


Where are we now?

We made huge strides on our journey. Remember where we started out? Compare it to what we see now.
  • All kinds of collaboration modes. Synchronous pairing and ensembling, working side by side in the same virtual space, as well as asynchronous solo work. Wherever people are right now, whatever they deem best right now. And still evolving.
  • Heavily increased communication and making things explicit. This occurred thanks to synchronous work in general, yet can also be observed in team channels and in calls. Also across teams!
  • Inclusion and access by default. A topic we will continue learning about for a long time, yet we can already see how people changed their behavior, thinking of the team - which they also benefit from themselves. This was a huge game changer for us.
  • Higher confidence in our product, less observed issues. Fast and early feedback paid off! As did increased testability and enabling everyone to do foundational testing. Sharing knowledge across roles. Including diverse perspectives. All of that and more.
  • Increased systems thinking, higher focus on getting things done. People started to realize which impact actions can have on a system overall. Starting to see flows and queues, throughput and waiting times, and more. How we can help each other across roles and main areas of expertise, how we can share the load. At times feedback is again slow, yet our flow improved massively compared to when starting out.
  • Trying things out becomes safer and more normal. We're not having an experiment-driven culture yet, yet just feeling the freedom that we can make our own decisions and give something a try was liberating for the people on the team. We saw a lot more initiatives already and kept the good.
  • Becoming a team. We all grew a lot closer - I can now really say we are a team indeed! It's heavily more pleasant to work in this team, experience the spirit, to co-create something great. And this is by far not the end of it, it's an ongoing journey.
  • Being seen as a different team. Our reputation and outside perception already changed to the positive. We are continuously working on improving this, intentionally.
We're also coming into calmer waters now, finally. We all acknowledged that for the time being we needed to make tough calls in favor of achieving the challenges we faced - like this gigantic epic to tackle. Yes, there had been a few hiccups, yet overall, I'm super glad things went very smoothly! Many thanks and kudos also to our neighbor team here including the very amazing Patrick Prill. I loved the close and super supportive collaboration. They had a big part in this success and also a very positive impact on the team's journey.

I also want to acknowledge that I'm now working on the most diverse team I've ever been on in my whole career. Ten people from nine countries of origin, people of four races, with three women, and also other aspects I'm aware of like educational background, parenting, and others. Yes, I'm sure we're missing out on certain perspectives. At the same time, we have as many as I never had combined in one team so far. Invaluable, I'm learning so much.
All this has not been an easy ride, it's been a real challenge. It will stay a challenge, I'm sure of that. Yet now we're truly in this together and can all make our way to better directions. We're growing and changing; the future awaits us.

What helped make this transition?

People within and outside the company asked me how I contributed to the team's transition. Yes, I had my part in it with initiatives as described above, yet there's been a lot of people working together to achieve this. Thinking about what helped me on this journey, I realized I'll need to think about this further. I am considering making this the subject of my next talk proposal, as I feel there might be inspiration in there to try out and build on. I'm sure there are many ways how things could work. Whenever we don't see any way right now, sharing experiences like these could trigger a new spark, something different we could try. For now, let me share a few more things that helped me in the last months.

Remember my post "Dear Future Me: I Am Not Alone"? At peak times, I really had to remind myself about this. I did not intend to get into a similar situation again, yet here I was. My own advice from last year still proved valuable for me this year again.

What else helped? Patience, patience, patience. And lots of optimism and hope. Adopting new mindsets, changing behaviors and shaping systems take a long time. We're working with humans after all, and are human ourselves. We won't always have our best days, either. I'm in for the long game! So, whenever I see anything praiseworthy, I'll celebrate. Really, celebrate each step on the journey, every little thing. It's where I gain lots of energy from to go through the less successful periods. You might see me do this publicly a lot. You might think from the outside it's all nice and shiny. I can tell you it isn't. It requires the same effort. It requires the same patience. I do celebrate every win, and we fail a lot more than that and that's okay. There's no shortcut I know of. There's still so much more to do and we have it in our own hands to do it.

I drew a lot from what I've made good experiences with in the past. Like: approaching any situation with curiosity, showing you want to learn. Appreciating what's working, seeking the positive and turning up the good. Showing gratitude for help and explaining why it's impactful for me. Knowing people usually have good reasons why they behave in certain ways. Many people just never made good experiences or had opportunities or permission to try things out. So, let's give them just that, let them make their own experiences. Changing my own behavior - I cannot change them. Observing, gain ing transparency, creating awareness, luring people to experiment. Lots of "we" thinking, messages and also action. Leading by example. Being authentic and vulnerable, sharing as you go with all successes and failures. Not bothering with theory, yet getting down to tangible action. If it's not feasible, no one will pick it up anyway. Acting in ways to support people's work, not obstruct it or gatekeep. Using lots of pragmatism as well and not holding too closely to high ideals when we're trying to get foundations in place. Living very close to people and their needs. Speaking their language. Starting where we are and incrementally improving from there. Striving for better than we left it, yet never jumping to perfect - better is good enough for now. Explaining your reasoning behind actions or decisions, the why.

Not everyone is the same and that's great. I have early adopters as well as late adopters in the team - sometimes one person is both on different topics. Both types made huge transitions relatively to their own previous position. Someone who held back would now instantly go on calls with me. Someone who never did work together at the same time would now ask for people joining them to have more eyes on the same critical action. This might not be my own ideal for our future (which constantly changes anyway), and at the same time it is a huge step for them that I personally judge very positively. In short: don't expect to make everyone make the same jump at the same time. People need to go at their own pace and different things are differently challenging for them.

Work where work is visible for the people you'd like to lure into change (like ticket comments). Try not to convince them that certain things are valuable to do (test in isolation first, test the API only, read the code, test the tests, etc.). Instead, just do it and let the results and outcome convince them. Don't take it personally when it does not work out right away - remember, this takes a lot of time. Confidence helps - yet most often, we have to build our own confidence while we already need to take the team along, which is a challenge. Try to be clear about it yet not be put off. Yes, I also still need courage.

Just last week, I finally finished the amazing book "More Fearless Change" by Mary Lynn Manns and Linda Rising - and realized I'm using a lot of the various patterns to help change mentioned in the book. It resonated so much with me, it's incredible. Really recommended read if you are up for change.

What else? Let's get to know each other and build relationships, we're in this together. Let's create a safe space for us. Then we can focus on learning, try things out and see what happens so we all improve and can do a bit better each day. So yes, first and foremost, dare to try something. Inaction does not help. Someone else will not fix it, or not in a way you'd like to have it. Take action yourself. It doesn't have to be perfect, just a bit better than yesterday. It doesn't have to be huge, just a tiny step. You don't have to be in a formal leadership position, you have power to change things from your very career start. Observe, try something, reflect on what happened. Based on this learning, try something else. Continue.


What's next?

A lot happened in the last eight months. The team is not comparable anymore to the group of people I encountered when starting last December. We really started to craft our own narrative, and it's by far not the end. I'm looking forward to what the future holds for us and what we can do to help shape it to our team's as well as the organization's needs.

As we're now going back to a more sustainable pace, picking up things we had to drop in the last months, and also growing further as a team, a new exciting time is starting. There's a lot of topics to dive in to and further initiatives to drive from a team perspective. More problems to solve and friction to reduce. Lots of knowledge, skills and tools to learn to help us build a more valuable product. We can work on technical foundations now, grow into experimentation as a lived team culture, and make further connections with other teams. So much more to do. Lots of opportunity ahead, it's not getting boring any time soon!

In addition, there's a few organizational topics I'd like to dive into. Now that we are returning to a usual work pace, I'll have more time to reflect, to really stop and think about my next endeavors and experiments. I'm thinking of more knowledge sharing across teams in various setups. I'm thinking of more hands-on collaboration across teams, especially more pairing and ensemble sessions. I'm also thinking of acting on organizational observations I've made over time to achieve change on a bigger scale. I'll have to see what to try first to learn fast, where I'll have the most impact, and what also adds to my own growth. I cannot tell what's next besides it's going to be in the same organizational context. I'm curious myself for the future.

Thinking of my team again, change really does take time for humans. We've come a long way in quite a short time and I'm grateful.


Bonus: Collaboration Celebrations

You can see our team's transition reflected in my tweets over time. Some of them I already embedded above in context. Yet there's more, especially on increasing collaboration and growing closer as a team. Here's a tweet compilation to showcase the collaboration highlights of the last months. Remember, I celebrate every little thing and there's lots of white space in between. And still, there's so much worth in celebrating the good and the awesome people I have the honor to work with.

Thursday, June 16, 2022

Agile Testing Days USA 2022 - A Wealth of Inspiration

A week ago, Agile Testing Days USA 2022 came to an end. A conference that we waited two years for to take place. Now a whole week has passed, and still there's so much on my mind from this event, so many things to think about and lots of inspiration to take action on. I've been fortunate to attend many conferences thanks to speaking, and yet this was the first one since a long time that hit the nail with everything. A wonderful mix of community spirit, awesome session content, amazing people - I took a lot with me. Here's my report on this journey. Brace yourself, it's been a long week and there's a lot to share.


Saturday

Why waiting for the conference to start in order to start with conferring! Also, why not make use of a new location we're visiting and go for sightseeing? I just loved the opportunity to discover a bit of Chicago together with Alex Schladebeck, Lisa Crispin and Melissa Eadon. Mel even came all the way to see us without attending the conference, and I'm so grateful for our many conversations.

After seeing dinosaurs in the Field Museum, having a nice stroll through Chicago, enjoying deep dish pizza, walking a bit more and getting ourselves coffee and scones, we headed back to the hotel. More people had arrived like my dear colleague Vernon Richards or Huib Schoots, and we met the wonderful organizers. It was a relaxed evening all together in the quiet staff room, enjoying this private kickoff before the event starts.


Sunday

I had decided to join Rahul Verma's two-day tutorial "The Joy of Python for Testers" and did not regret it. We learned a lot about programming and design, as well as the foundations to get started in Python. I am impressed how Rahul crafted the tutorial on the fly to make sure it's adapted to the participants! Two days is not a lot of time to dive into a new programming language, and I'm grateful for all the content covered. The tutorial inspired new ideas and was definitely worth it. Also, I appreciated the conversations with Rahul during and afterwards. It's fascinating to learn from sessions on a meta level as well - not only from the presented content, yet also from the way people teach, which approaches they take to convey knowledge. There's a lot to take with us for facilitating our own sessions, not only at conferences yet also back at work for our teams. Last but not least, this tutorial also granted the chance to meet new people like Maria VilatuΓ±a Galarraga and Naomi Schumacher, for the latter this being their first conference experience ever.

The evening arrived, more people gathered and we enjoyed a lovely dinner together - very fortunate to meet people like Jenny Bramble and Janet Gregory again, and also see Erin Hess and Karen Todd for the first time in real life. Precious moments together with lots of informal knowledge and experience sharing. For anyone who's never done it before - go for dinner with other conference people, make use of social spaces. This is where we can learn so much not only for our professions but for life.


Monday

Rahul's tutorial continued, another day full of knowledge and learning. And then it was time to open the conference officially, to join the speakers' dinner and then afterwards the meet & greet together with everyone. More opportunity to see old friends again, like Ashley Hunsberger and Shivani Gaba, and meet people in real life for the first time, like Angela Riggs or Jenna Charlton. Ever grateful for our time together. 

Connecting with people is worth it in every aspect, you never know what comes around. For example, I learned that Paul Holland enjoys black tea! If you didn't know, I love black tea. This newly discovered commonality continuously brought us into conversation again and again - and the next days he even shared some of his personal tea with me, much appreciated Paul!

I really enjoyed all these conversations, and yet I knew this was only the beginning. The conference would start early in the morning, my own sessions were scheduled for the next days and hence I made the reasonable move of going to bed early.


Tuesday

Let the conference begin! A long insightful day lay ahead.

  • Early Morning Lean Coffee with Janet Gregory and Lisa Crispin. On all Agile Testing Days events, I will join at least the first lean coffee session - I made a habit out of this that I never regretted so far. You never know which people will come, which topics will be brought and what insights you can take with you - and there's a lot of opportunity in that. This time once again, we had great topics to discuss. My personal takeaways: 1) Trying to meet new people at a conference? Be intentional about it, set a target of getting to know x new people and learn their names. 2) Something is scary or hard? Create habits and practice. 3) People not taking action? Be clear and explicit with expectations, support with questions and stay patient.
  • Keynote "Career Choices For The Modern Day Tester" by Vernon Richards. I've seen the previous version of this keynote at AgileTD Open Air 2022, and can only say this time around it was even better! Lots of relevant messages that people need to hear. Vernon encourages us to take our career into our own hands - in the end, we're the ones most invested in it. And if we don't control our own destiny someone else will! So figure out why you want to change, what you expect, who you want to become and stop waiting - instead, seize opportunities. Consistency beats perfection.
  • "Growing an Experiment-driven Quality Culture" by me. Despite some initial technical setup surprises, it seems I managed to convey my main messages according to the feedback received. I'm happy with how it went; it even seems to have been one of the better versions of this talk.
  • "The Do’s and Dont’s of Building a Successful Agile Team" by Deena McKay. This talk provided great input on how to form and foster good agile teams - which requires a shared base and also patience, this takes time. I really liked how Deena included the audience on the topic, actively made space for them and responded to their experiences and questions. She made a point that while she was speaking about Scrum teams here, she has experience with other agile methodologies as well and the main points are just as applicable there as well.
  • Keynote "The Truth about Agile" by Melissa Boggs. What a great reminder what the agile movement was actually about. We should build our organizations in such a way that they can listen closely and move quickly. I loved the closer look at the agile manifesto and its principles that I'm sure many newer people haven't seen yet. Practices without principles are ineffective at best and damaging at worst. Since a long time, this was the first session covering agile in a very helpful way. A great thing to walk through with our own teams.
  • Topic Roulette #1 with Linda Rising. In this bonus session, Linda offered a few topics she could talk about and we as participants could decide what we wanted to learn about. In our case, we went for the brain and critical thinking. Main insights: There was never any benefit for thinking critically, and lots of benefit for behaving irrationally. We'd like to think we're making logical decisions, yet the underlying reasons are completely unknown to us. We should be more humble and open and try to understand people, if we would all do that it might be a better world. The point is not to change someone unless it's you. Have conversations, emphasize, listen. As a species we're doing best when we're together; emphasize what we have in common, not our differences. Now, Linda is just amazing and has a wealth of knowledge she can present on the fly in a very insightful manner. Just loved it and took a lot with me. Could listen to Linda all day!
  • "Security Tooling in Your DevOps Pipeline" by Nancy GarichΓ©. Loved the topic! Nancy provided a great overview on how we can scale security expertise and knowledge while not having many experts around. Gatekeeping doesn't work, yet one thing that does is adding security checks in our pipelines. There's lots of different types of things we can run, and we can also do so asynchronously. I was especially intrigued to hear about security as code and am eager to dive into this deeper.
  • Keynote "An Easy Way Out" by Linda Rising. Linda is just amazing, have I already said that? All the talks I've heard from her are worthwhile - and so is this one. Linda inspired us to try expressive writing as it is proven to reduce anxiety and lower stress hormones, and provided us an easy guideline along with it. I really like how she interweaves storytelling, scientific experiments and instant actions we can take - wonderful. Also, this topic is dearly needed by humans these stressful days.
The evening ended with the Flower Power Costume Party which provided more opportunity to meet up with people, like Larissa RosochanskyRafael Cintra, Morgan AhlstrΓΆm and also Kelsey Schoen - another first time conference joiner. Also great to see Mike Lyles again, who gifted me a signed copy of his new book "The Drive-Thru Is Not Always Faster", thanks Mike!

Wednesday

New conference day, new sessions. Today less talks and more workshops for me.
  • Keynote "Personal Branding & Storytelling" by Melissa Sassi. At first, I was not sure where this keynote is leading up to - and then Melissa told her origin story, and it changed everything and gave all this so much meaning. She basically turned her personal nightmare into her super power. What a deep message! Very inspiring indeed. It made me think about my own origin story that I tell in different ways to different people - good trigger to look into this again. Our origin stories can not only let others know who we are and where we come from, yet also what drives us, what we want to achieve and why it matters to us.
  • "Superpower to empathize with our users" by Udita Sharma. This was a great workshop that not only provided insightful ways how to discover usability issues or design for usability, yet also really engaged the participants hands-on. Udita encouraged us not to blame our users for design problems - they are just trying to solve their needs and will do so with any means necessary. How to catch design problems upfront? We learned about cognitive walkthroughs, a "formalized way of imagining people's thought and actions when they will be using an interface". We can include usability with just asking simple questions like "Is the action intuitive?" and "Is the feedback appropriate?" - and if not, why not? Loved all the examples that made the content very tangible, as well as the exercise that confronted us with our own biases. 
  • Keynote "How I lost my job by attending to Agile Testing Days" by Jan Jaap Cannegieter. A vulnerable story full of self-reflection reminding us on what's actually important. He shared he was happy before agile came - though probably not everyone around him was happy. When agile gained traction, it was hard for him to find his new role and position in a changed world - is he as a manager needed at all anymore? Until he figured out that it's not about agile or not - it's about finding happiness. I loved that he encouraged us not to stick to our job descriptions but to do what provides value to the organization.
  • "Ensemble Exploratory Testing" by me. I've given this workshop multiple times already, and while it's up to me to set the scene so participants can thrive, the outcome is always different depending on the people joining. This time around I had a wonderful group giving ensembling a first try and exploring an API together - it was a blast seeing them thrive and learn lots of things in short time in an effective way! Seems they had lots of fun, too. What else could I hope for?
  • Keynote panel "Creating a diverse and inclusive world in the digital age" by Deena McKay, Nancy GarichΓ©, Raj Subrameyer and Tolu Adegbite. We need to hear underrepresented people more and listen to their stories and experiences. That was the best part of this panel - hearing the voices of these women, whatever they were willing to share. Not only on stage for the panel, yet also later on in the human space. We definitely need more of this. A few essential takeaways for me: 1) Always call microaggressions out. 2) Be open about your salary, it can make a difference for someone else. 3) Actively look for sponsoring opportunities.
  • The Friends & Allies - Human Space. Yes, more of this. More people, more stories to be told and heard. I am ever grateful for everyone sharing their experiences in this space. I felt my place there was to listen, and then go and take action. I've been diversifying my sources for a while now, and feel it's time again to seek out new voices. I also need to talk more with other white people about what I've understood so far. And definitely, I am still working on calling things out as I see them, not letting them slide - it's a continuous learning journey.

Thursday

Last day of the conference, time flew by! This was another great one.
  • Keynote "The Experimentation Mindset" by Doc Norton. The topic is dear to my heart and the speaker did a great job demonstrating the benefits of experimenting. Great storytelling as well! The moment he realized successful people went off script? That triggered him to think, challenge assumptions and try new things. We need to make failure acceptable, think big and start small, as well as discover leading practices for our context - practices that are currently great until we discover better ones through experimentation. 
  • "Coaching Skills For Testers - A Primer." by Vernon Richards. Coaching is about asking questions to help people gain a new insight or perspective, not telling them what to do. It requires unconditional positive regard and active listening. Ask powerful questions to further explore the situation with them, help them define and manage it. It's hard not to steer in a certain direction with questions! Yet the best person to solve the problem is the coachee, they have the full context. I loved this space to practice and experience coaching! Vernon provided a great concise introduction with the most essential tools, and gave ample of time for hands-on exercises, supporting us throughout the way. Exactly what I hope for in a workshop. I learned not only about coaching, but also about myself and gained new insights. Super valuable!
  • Keynote "Towards a Future of Self-Testing Systems" by Tariq King. Great session on topics we don't speak about too often yet (still): testing on production as well as making use of AI in testing. Tariq made clear that testing in production is not insufficient pre-production testing, it adds to it - and the future of testing is definitely production which is the only reality there is. It will also include AI as software has become more dynamic - and success for adaptive systems cannot be measured offline pre-production. AI supports self-testing and also requires it at the same time. Lots of food for thought! Awesome presentation as well.
  • "Team Work Isn‘t Always A Dream: Building A Culture Of Accountability" by Dr. Rochelle Carr. What a great talk on accountability in teams - just loved it. Lots of actionable wisdom shared with lots of energy! Much food for thought to act on for our own teams and companies. One thing that really intrigued me is not to settle for mediocrity! We need to have a vision for our team, create a culture of trust and take action - as only action will make it work.
  • "Distributed Exploratory Testing - Embrace the Chaos" by Chrishan Perera. Great story on how not to settle for an unsatisfactory status quo and instead go ahead, take action and try something different. Just loved how Chrishan's colleagues see CHAOS as an acronym: "Chrishan has an odd suggestion"! When you see chaos, embrace it - something beautiful can come out of it.
  • "Building a developer-tester relationship" by Brandon Jason Valle Tamayo and Janet Gregory. When Janet and Lisa set out to have a new web app for their courses built, things didn't go exactly as they hoped for. In fact, the collaboration with the developers was lacking at best! In the end, they managed to turn this around to a beautiful outcome - together. Loved the storytelling and the vulnerability included in this talk. We all make mistakes; this was leading by example how to acknowledge our mistakes and do better. Investing in building good relationships really pays off!
  • Keynote "The Last Keynote on Software Testing" by Rahul Verma. Rahul had a ready-made talk for this conference. Then the event was postponed for two years, and now he's a different person. The old talk didn't feel right anymore. So, he decided not to do this talk that would be so convenient and comfortable to just give - and instead showed lots of courage and vulnerability coming with no prepared talk at all. This made it possible for him to share a way more impactful and authentic, raw talk right from the heart. He asked lots of hard questions without necessarily having the answers: Are we allowing speakers to be weak and human? Are we expecting people just to entertain us instead of sharing deep knowledge? Are we really passionate about what we do or is it another lie we tell ourselves? Why are we not valuing specialists anymore? How can we get out of this and grow our craft further? It really made people think and asked them to take action. Thoughtful and inspiring, a great last keynote indeed.
The final conference evening was full of great conversations again. Including jokes! (Thanks Chrishan for the "schattiges PlΓ€tzchen" that I can't get out of my head anymore... ^^) I really appreciated everyone that stayed around, including lots of people for whom this was their very first conference. Seems we did a few things right this time in the never-ending effort to make conferences a welcoming space for everyone and not end up in elite cliques.

Friday, Saturday, Sunday

After the conference is before the conference! At least when it comes to sightseeing. I just loved that lots of people still were around and open for discovering new places and having food together. A great combination of enjoyment as well as reflecting on what we learned at the conference.

Many thanks to Maryam Umar for a wonderful tea and pancakes breakfast and visiting the Art Institute of Chicago with me. Many thanks to Vernon Richards once more for long and deep conversations about all kinds of things in the evening. Many thanks to MichaΕ‚ KrzyΕΌanowski for extending his stay and join me on a visit to the Shedd aquarium, a long walk through Chicago's different quarters, as well as the Morton Arboretum. If you're keen to see photos, just ask to follow me on Instagram.

Conclusion

Overall? It was an amazing experience. So much to learn, share, and especially take with me. Really, this time I have a lot more to take home with me than with other conferences in the past. My follow-up actions range from ideas for new sessions, to insights about myself to change my own behavior, to ways of practicing my skills, to inspiration for a new personal challenge, to lots of things to try at work. It's a long list indeed!

Was everything perfect? No, it wasn't - the venue for once was troublesome this time and I cannot leave unmentioned that rooms were freezing cold, even for American standards. The warmth of the community, however, outweighs this by far. I'm ever so thankful for everyone who made this feasible and happen - special shout-out to the wonderful organizers here! You created a very unique event, once again.