Tuesday, January 17, 2017

Back On Track, Picking Up Pace

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

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

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

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

What happened in 2016?
  • When I entered the team, they already shared responsibility for quality, with every developer writing automated tests and doing basic manual testing themselves. This was a great foundation for introducing testing from a tester perspective. They had some ideas about how it would look like. For instance I often heard "you can wait with testing, code review is not yet done", and "QA does testing after everybody else finished their jobs", like a gatekeeper for releases. However, they appreciated me sharing my experience. Like testing throughout the workflow, before any line of code is written by asking questions and continuing on production such as by reviewing logs; having many feedback cycles and shortening them; and so on. We iteratively defined how we want to collaborate and how our development workflow looks like. Tried things and kept what worked. The team quickly provided feedback that they see big value in having a person coming from a testing mindset contributing in many ways.
  • Our Java development department grew heavily over the last year, we now have three teams and searching for more people fitting in. We made good experience with careful recruiting. Investing quite some effort mostly paid out for us, but sometimes we feel we need to speed things up not to lose great candidates to competitors.
  • As the whole company grows steadily each month, we moved to a big new office. On the one hand we now have space again and the rooms are much nicer; but on the other hand we lost decent internet connection for half a year due to a mistake made when putting up the new building. You know, internet, this thing everybody in the company depends on? Tough time, we had to figure out how to deal with a mere mobile connection during this period.
  • When the time came that my first team was settled, I additionally started in a second team introducing testing there as well. I quickly realized that both roles were full-time jobs. I learned a lot during that time, but it was quite stressful. I often had the feeling to only run after tickets instead of being able to think ahead of them. We were really lucky to find a working student who, although she is able to program and therefore could work as developer, explicitly wants to test. She does an awesome job and is a perfect fit to our teams. We're even luckier now that she started full-time after finishing university. Back then I knew the second team was in safe hands so I returned full-time to my original team in good conscience.
  • My company went through a merger in 2015. The original organizations lived a very different culture and approach to development which often caused issues when suddenly collaborating. In order to become one unified company, we now started a global transition towards agile product development. Additionally, we set up our own flavor of a matrix organization with teams, chapters and communities, based on approaches of other companies like Spotify. As you might expect, this huge change currently causes a lot of turmoil, raises a lot of questions and has us face a lot of challenges. We all try our best to have our organization move into a direction we all support and grow a culture where we want to be part of. I'm curious how we will have evolved one year from now.
  • When starting, I was the second person identifying as tester at the company. So we started our own little community of practice as a two-man show. With the agile transition and getting closer across different locations, we grew into a larger community where not only testers but anybody interested is welcome to join and share knowledge, experience and challenges. I'm really excited about this opportunity of company-wide sharing and learning.
  • And last but not least, my company enabled me to attend Agile Testing Days 2016 for the full week - which was simply awesome! I did not experience this kind of support at other companies before and heavily appreciate the continuous investment in people development!
Throughout the year I learned several valuable lessons.
  • You can do decent "Scrum" even if you don't have a dedicated Scrum Master. When I learned that there was no one taking over this role, I was skeptical but thought "let's see how this is supposed to work". I discovered that every team member took over some part of the Scrum Master role which worked pretty well. Still, I'm not sure who would have stepped up to moderate and mediate in case of bigger conflict within the team; but probably our disciplinary leader would have done so.
  • I was used to have long sprint planning sessions with the first part discussing and analyzing the upcoming product backlog items to roughly forecast which of them we could tackle in the next sprint, and a second part of breaking those items down into detailed single tasks. Imagine my surprise when my first sprint planning ended after about 45 minutes! We simply don't do part two, but work on story level only. And discuss details just in time when we come to them.
  • We have a team of full-stack developers. Everybody doing everything, just pulling in the next item and working on it. This really increases our bus factor! And it's just great to go on vacation without having work piling up during your absence! Only it's hard to find good people willing to take over all kinds of tasks, learning many new things. And we still have some specialized people knowing more about testing, DevOps and UX; but we're working on improving knowledge sharing in those areas as well.
  • Our Product Owner is completely integrated not only within the team but also within the development workflow. When a first version of any backlog item is implemented, he already reviews it if it fits to his vision and expectations. The feedback cycle is kept as short as possible instead of waiting for a sprint review to accept or reject a feature. This procedure also increases transparency while working on an item. We really value this close collaboration with the Product Owner throughout the sprint.
  • Within the past year I finally understood that it's not about reporting and fixing every issue we found, but about communication, collaboration and needs. Fixing some defects simply has no or too less business value as users won't ever come across them, so we close them unfixed. We rather invest effort in things actually providing value instead of wasting our budget.
  • Our team is distributed as our Product Owner is located in another city. We learned that good conferencing tools and especially a decent internet connection is crucial for us. This had hit us especially during the period when we had to work on mobile internet connection only.
  • Our disciplinary leader reminds me of my former one, being really open and supportive, always trying to develop you further. When he asked me for a personal talk two weeks after I started on the team, my self-doubts showed up again and I thought "oh my god what's up, it's probably about my lack of test automation knowledge...". And was so positively surprised to receive feedback that my contribution is already appreciated, how greatly I fit into the team and that it feels like I've always been a part of it. Wow! This instantly neutralized my biggest fears so I was able to focus on my work and put even more energy into it. I knew if something would come up, I would get timely feedback so I would be able to adapt. Psychological safety for the win!
  • If you treat your working students well, they will stay. And so far, nearly all of ours did so. Some of them even quit their master studies to start working full-time with us. We integrate them completely in our team and collaborate on a level playing field. They do exactly the same as everybody else, sharing the same responsibility, learning a lot and bringing in fresh perspectives, receiving support whenever needed just like anybody else.
  • But the best lesson of last year was the following: The mere fact of working for two teams created bottlenecks as the developers continued pulling in new tickets and the things to test piled up. Our situation got worse and worse. Why is this a good thing? Well, when the teams felt the greatest pain, it made everyone realize that our way of working did not work out. We were not able to deliver value to our users anymore, we just created more useless inventory, increased waiting times etc. Everything took longer. Both teams admitted that we needed to adapt. So they agreed to try the simple approach of "stop starting, start finishing". We agreed that it was not allowed to pull in new tickets before you really were not able to contribute to items in progress anymore. Sometimes not even then, just to not increase the work load. But if there was anything to do, be it support with development, reviews from business, code or testing perspective, everybody swarmed to help out, no matter what their original "roles" were. And suddenly there were no bottlenecks anymore! Even after our new full-time tester took over my second team, they really learned their lesson and continue to swarm to finish highest priority items first before starting new ones. Teaching and supporting each other when testing or doing anything else they do not specialize in. I'm really proud of them, they showed what collaboration and a whole-team approach means.
What about our current challenges and the outlook for the new year?
  • While I had been running after tickets, I hardly found time to prepare test cases upfront of implementation and discuss them with developers and Product Owners. In the end this often caused delays as expectations differed and questions were raised quite late. We're just returning to shorten the feedback cycle again and having those discussions guiding development.
  • When testing for two teams, I was not able to invest much time for conceptional work, thinking about test strategies for our product or trying new tools and techniques. Now having more time again, I want to run more experiments, try new approaches and see which work for us. In addition I'd love to increase efforts of knowledge and experience sharing on team, company, local and global community levels.
  • Our team needs to get to know our users better, who are collocated with our Product Owner. We plan on-site visits to learn how they actually use our products and what their pitfalls, challenges and needs are. Actively include them in our sprint reviews. Same goes for our stakeholders. Currently communication is only channeled by our Product Owner which sometimes makes it hard to understand why priorities change or to come up with new ideas for our product.
  • On our agile journey, we have to find new communication channels within the company and grow a common culture, to finally feel as one big organization. Besides that, thanks to this transition we now finally got a dedicated Scrum Master for our team. Even when things are going well there's always room for improvement, so let's find out together!
  • Our team office needs to become more lively. We're now finally hanging up cartoons, getting a large screen TV and discussing how to breath life into our everyday environment! To make it feel less like a "getting work done" place and more like the creative fun area it is. And attract more of those awesome people. Speaking of which, we are still growing. To do so, we have to spread the word that we are a tech company with great offers, but especially with great people to build the world together!
Dear 2017, let's get started - I'm curious what will be the next lessons to learn!

No comments:

Post a Comment