Wednesday, January 25, 2017

Team Logos Anyone?

Last week one of my colleagues gave me feedback on my blog. He said he really likes my stories but that the blog could use some life, some color, some images. I could not agree more.

So why didn't I include any pictures yet? I'm wondering myself. When writing for an internal company blog some years ago, this was exactly one of the points I totally cared about in order to convey my messages and attract more readers. But when telling my own stories here, it somehow didn't feel right; or rather, I didn't feel the need to do it. Maybe simply because of the fact that I'm trying to blog for myself here.

But thinking about the feedback triggered me to share what we did lately: We finally introduced logos for our Java teams! In order to grow closer across locations and increase transparency, a new global team overview had been created. It clearly showed that several teams had logos like the Death Star, Asgard, a Zeppelin. And that we didn't. Too sad! So we started searching for logos as well.

Guess what? One of our teams chose a unicorn! Too funny. After sharing my stories from Agile Testing Days 2016 including pictures of their unicorns...
Agile Testing Days 2016 unicorn
... our office suddenly turned into unicorn land! And this team chose it as their logo. Love it! :D
charter logo
Now it was up to my own team. Quite a challenge to find a logo which is at least as awesome. I mean, how to catch up with a unicorn? But then two of my team mates were touched by genius. We're developing planning software, so they thought of A-Team's Hannibal and his often spoken line "I love it when a plan comes together". Well, our product is called "planr", so...
planr logo
Who knows when our logos might change again, but for now we're really enjoying our revived team spirit! Such a simple thing as choosing a logo helped breathe life into our team again (together with spreading cartoons of course). Do you have team logos? What's your experience with them?
cartoon wall 1 cartoon wall 2 cartoon wall 3

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!

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.