Friday, January 6, 2017

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.

3 comments:

  1. A nice read. As promised I will share some of my experience as a scrum master coming from an Automation testing background. I got in to the role about 9 years ago when Agile and Scrum was still growing here in SA. The company I worked for back then were one of the early adopters of Agile here in South Africa and Cape town in particular. One of the main implementers/agile coaches here in South Africa so happened to work for the same company as me and he had identified me as someone who had the drive to be a good scrum master. He approached me with the idea and after about 3days of thinking about the idea I decided to accept.
    My team structure was very different to what you experienced in that my full team was co-located and based on the same floor. Some of the main points in my experience are as follows
    -Intitally had alot of push back from team members who did not buy into the Agile concept this made me dig deep down into people psychology at the work place and try to understand the reason for push back. Obviously not everyone could be convinced on change but I did make significant progress in getting most team members to buy in to the philosophy
    -Personally it was a major challenge for me too as the role change made me realise what made me tick. The downing of code and testing concepts in exchange for admin related tasks was not really something I enjoyed as I missed the technical aspects of my job.
    - there were definitely rambles around the floor around what scrum masters actually do and quite frankly this was expected as it was a new concept/role for people to get used to. However this didn't motivate me and this is where I yearned to head back to my technical role. I eventually decided the role was probably not suited to someone who had a 'technical itch' and realized it was time to go back into automation testing.
    Right on queue I received an external offer for a Senior Automation test engineer which I grabbed immediately.

    So before anyone decides to make the switch to scrum master from a testing/technical background I suggest you give it a real long hard thought and do some introspection into exactly what makes you tick.

    ReplyDelete
    Replies
    1. Thank you Toyer for sharing your own experience and your thoughtful advice! I agree that everybody should take stock of oneself when it comes to changing roles or taking over new jobs. It can be really worth trying something new and even taking a risk, especially if you don't know yet what makes you tick. But in case you decide to change, then do it wholeheartedly to not regret any decisions. If you then realize that the new role does not work out for you due to the role's nature - well, nothing is carved in stone. You can always change directions again, or even return from where you're coming from.

      Concerning my personal journey, I don't regret my decision to take over the Scrum Master role as I learned a lot, still did technical stuff as well and had a great team. The challenge to survive in a non-agile environment, however, was definitely not a fun experience and I knew I had to change directions as quickly as possible.

      Delete
  2. Definitely, this is 100% correct. I also do not regret taking the role as Scrum Master as it was definitely a learning experience and at the same time enhances my respect for Scrum Masters and what they do. Thanks for the great feedback.

    ReplyDelete