Monday, August 14, 2017

Thoughts about Awesomeness

To be frank, I hesitated to write this post. I still wrote it because I think it is an important topic. I feel the need to document my current thoughts for my future self and to share them as a basis for discussion. The following reflects my non-expert, non-scientific impression of things. My personal thoughts of today will evolve as I learn more. This post got quite long, but please bear with me and read to the end.

At Agile Testing Days 2016 a Women in Agile Summit was hosted. To be honest, when I read about it, I was taken aback at first. Why would a women event be needed? Why excluding men and everyone who's not comfortable with this binary classification? I felt that making something gender-specific was not the right approach. I am not considering people for their gender first. We're all humans, right? We're having many different identities. In the end, we're all individuals. So I'd rather strive for equal chances than supporting women over others just because they're women; strive for diversity in all means, not only gender. It simply didn't feel right. It still doesn't feel right. But I might be thinking a bit too naive about the topic. Back then I finally decided: Well, I am a woman, I'm working in an agile environment, so I should attend this event and check out what it's all about.

At the summit, I joined a lean coffee session with several women coming from South Eastern Europe and Germany. We exchanged our experiences regarding gender issues at our work places. The German women saw things just about like me: well, there's no real problem anymore. If a few more women would join our teams, that would be great. To attract them, maybe we could advertise more that we're having an open and safe work environment. Right, and there's probably still a salary gap, but it appears to be closing more and more. Besides that, we didn't encounter discrimination due to our gender yet - well, at times some positive discrimination. But so far so good, we're getting there.

And then we heard the women coming from South Eastern Europe, telling us way different stories. Stories of women having to justify constantly why they are having a "man's job". Tales of women who learned that they had to show bossy behavior to get accepted by their male colleagues, and of others having to use their charms to survive in tech. Those women reported about struggles which never occurred to me. Naive me, to be sure. So, slowly but steady I realized that this topic is not at all out of date yet. For another view point I recommend reading Maaret's wonderful blog post about the summit. Personally, this event triggered me to be more aware of the topic.

The next thing that surprised me came early this year. I had submitted papers for Agile Testing Days 2017, so I followed their news about the submissions. When the call for papers statistics were published, I was really surprised.
29% of papers had been submitted by women speakers. One of my colleagues was positively surprised how high the percentage was. I, however, was rather disappointed; I would have expected that figure to be way higher. I mean, it was not about getting accepted at the conference, it was only about submitting. Why would less women submit? Does this only reflect that there really are way less women in tech overall? Or is there another reason?

Nowadays, again lots of discussions are going on regarding women in tech, minorities in tech, anyone in tech. Probably the most prominent example right now is the manifesto of a male engineer internally published at Google. I won't address the topic here, it has been discussed at length already.

Instead, I'd like to share another story with you. End of July, Ashley Hunsberger raised awareness of the following post.
It was quite commonly agreed that this kind of list rather served as marketing campaign than represented reality. On the one hand there were more women experts in test automation to be named and on the other hand same listed men seem to not match the profile at all. When people started to list further women, I found myself named as automation expert as well. Not my biggest strength, but people even started to follow me due to the mere fact I was added to the pool!
Shortly before that tweet, I had the honor to be invited to the Women in Testing Skype/Slack group, a group from and for women in the testing community (if you want to join, I can invite you, just send me a direct message via Twitter). As a reaction to above post, Anne-Marie Charrett came up with the idea to create our own list of awesomeness. The intention? Show the world that there are way more women in testing that could have been on a list. Way more that could get invited to speak at a tech conference. Way more to follow and get to know. And even way more who are not so publicly visible but worth being public.

Within very short time, we had a document with over 100 names on it. I could only contribute marginally myself; however, I was feeling so honored when realizing someone added me to the list as well. Even while creating this compilation of awesome testers, we felt how great it is to see who else is out there and which topics they're into so everybody could reach out to them more easily. We wanted to get this list out to the public. Agile Testing Days agreed to support and published the list on their blog.

The blog post leaked a few days before official publication date, and the reception was already overly positive and welcoming. I was even asked whether we also had a related Twitter list. Great idea! So we created it: https://twitter.com/lisihocke/lists/awesometesters Unfortunately not all women named have a Twitter account, but most of them do. The list is still growing as the Women in Testing working party is still adding to it. So look out for an updated version!
Side note: I would love to have gender, ethnic groups, educational backgrounds, or anything to be ignored and have a real diverse list of awesome testers compiled. The mere need of an all women list sticks in my craw. However, I found that sometimes support is needed to increase transparency and to point out issues. Also regarding my own biases. Just compiling this new Twitter list made me realize its difference to a personal Twitter list of awesome testers I created a while ago. Judging from the 70 testers I listed, I was aware of way more men (47) than women (23) in testing myself. I'll definitely have to add more women there as well. Well, every list is wrong in some way. Still, we can use them as a starting point and as a basis to trigger discussions.

In the end - there is no end to the topic yet. In my company, we have many awesome women. We also have many awesome men. We have colleagues from many different countries and cultures. I think (and hope) they had not been hired because of their gender or identity, but simply because they are awesome. Maybe we're still too similar when it comes to our education or work background in order to gain from actual diversity - worth finding out. Also, I'd like to further encourage hiring less for skills but rather for learning mindset and team spirit. Everyone deserves a chance to show that they are awesome in many different ways, and they deserve your support to grow their awesomeness.

Tuesday, July 25, 2017

How My Colleagues Made My Day(s)

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

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

Then a colleague approached me, asking me how things were going, how the preparations for my upcoming conference talks were coming along. I shared that I was in the middle of it and that I was getting a bit nervous already, and then she gave me this:
I was really blown away! This was so unbelievably nice of her. My new unicorn found its place at my desk and will now always remind me of her belief that everything will work out well. Hopefully it will also trick my own brain into believing this myself.

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

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

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

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

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

Thursday, July 6, 2017

About Crazy Days and Rope Bridges

On some days I fully focus on discovering the unknowns of our product, in close collaboration with my teammates striving to deliver value to our users.
And on some days I mainly work on company-wide topics like workshops, recruiting, or organizing meetups.
Some days are extraordinary, like going on a two-day offsite and building a rope bridge over a gorge. We had a team of talents coming from very different backgrounds who never worked together before. Still, we had fun, did a great job and learned a lot for our everyday work.

On some days I have so many tiny tasks and topics to follow-up on my desk that it's hard not to feel overwhelmed. Time just flies by.

On some days my team forms a spontaneous mob and I find myself learning a lot, but also contributing my perspective. On other days I work a lot in pairs in different constellations. Love those highly collaborative times.

On some days I hop from meeting to meeting having hardly time to follow-up on agreements, and finding myself wishing to not have accepted so many meetings in the beginning. But mostly they were important and valuable; and if not, we realized we have to make them so.

And on some days I extend the day to have dinner with my team or go to local meetups, to have a good time with awesome people and great conversations.

To be honest: I like the kind of days where I can fully focus on the task at hand the most, when I don't have to switch between too many contexts. But even though I plan for those days, I learned that plans are just plans and reality might be different. But that this is totally fine as long as I work on topics that provide value. Even better if I work on those that provide the highest value first.

Within the last three weeks I encountered all kind of days described above. Some have been crazier than others, but none of them were wasted. I have the freedom to decide myself on what to work on. So for me, it's about finding the right balance of how to use my time to achieve the best overall outcome, trying to do less in order to focus on what actually provides value.

Sometimes I excel at the right balance. Sometimes I fail miserably. As long as I learn something every day so I can improve myself and my surroundings, I'm fine. Every day is different, but never boring.

Sunday, June 18, 2017

Our First Take On BDD

Most probably you came across behavior-driven development already. But what is behind this term? What is at its core? How does it benefit a team?

Years ago I read a lot of blog posts about BDD and was intrigued to experience it myself. When starting in my current team, I began to spread my thoughts about trying BDD to see if this approach would help us. It took quite a while, but finally the team agreed to give it a try.

So here we are. We started experimenting with BDD and had our first Three Amigo sessions to kick our stories off and create shared understanding before starting implementation. We had our product owner on board, the developer who pulled the story, and me as a tester. We talked about the scenarios we see and discussed concrete examples. We raised questions and discovered unknowns. We decided what's in scope and what might follow later or never. We captured our thoughts as conveniently as possible, be it using Gherkin's Given-When-Then syntax for scenarios or any suitable graphical visualization. We decided on which scenarios to automate, on which level to automate them (mocked, through API, or through UI), and which scenarios to leave for manual exploration only.

Right after our first Three Amigo session, the developer told me how much she loved it. Now that we clarified everything we could think of at that point, she felt confident to be able to focus on implementation, without having lots of question marks on product side. She even said she wanted to do this on all stories from now on. As for myself, I could not agree more. I felt that the biggest part of testing had already been done. As most of my questions were already clarified, I could focus on looking for further unknown risks when testing the actual product increment.

Our experiments triggered me to read about BDD again. I found several awesome blog posts, all emphasizing how important having those initial conversations are to create shared understanding by discussing examples and therefore to drive development. All of them stated that automation is nice to have, but that this is not the main point of BDD. Of course, when you automate the discussed core scenarios, you also have an executable specification, improved your regression safety net, and added living documentation. Still, Augusto “Gus” Evangelisti concludes for himself:
"BDD is about conversations and collaboration to generate software that matters"
 Liz Keogh even goes beyond software:
"I can’t even say that BDD’s about “writing software that matters” any more, because I’ve been using scenarios to explore life for a while now."
"BDD is the art of using examples in conversation to illustrate behaviour."
"If you’re not having conversations, you’re not doing BDD."
"BDD isn’t about the tools. It’s about the conversations you have, exploring examples (or scenarios) of an application’s behaviour, to see if everyone has the right understanding."
"Some people really focus on the tools and testing. Others focus on specification. Really, though, it’s exploration that we start with; those thought-experiments that are cheap to change, and not nearly as dangerous as the real thing. [...] It’s pretty easy to explore what they want using examples, then use the results of that conversation as specifications, then as tests."
Having conversations is more important than capturing conversations is more important than automating conversations
Having those quotes in mind, can we call our team's first steps with BDD actually BDD? I guess yes, but I think we have to gain more experience before I can truly answer this question for myself. However, I already know that having those conversations upfront to increase shared understanding, explore stories and clarify questions helped us a lot to deliver actual value to our users. It was worth investing the time and it will be worth asking again: "Can you give me an example?"

Thursday, June 1, 2017

Select Your Team

May 16, 2017 was a day to remember at my company. All the people of our FlixTech organization came together for a huge event. All our products were pitched by their owners. And then every single one was free to chose their product, their team, their role, and their location - from now on.

Beginning of the year, I have come across the following reports of such team self-design events.
After reading about this approach of giving the people the freedom to choose their own future and actively encouraging them to do so, I was both curious and excited to experience it myself. In order to learn how we facilitated our event in a nutshell, check out Day 0 by my colleague Alex. What I want to focus on in this post is my personal view on how people responded to the event announcement and on the days after.

Freedom and trust...?

As soon as our company signalled that we would redesign our domains and products, but also have all our people redesign our teams around those products, people began to raise questions and express worries.
  • "What if the team I want to work on is already full?"
  • "What if it's decided my team is now located in a different city than I live in, but I don't want to relocate?"
  • "What if the budget of my team is reduced so at least one former member has to leave the team?"
  • "I was just hired for this team a month ago, what happens to me?" 
  • "What about people on vacation, on sick leave, or stuck in a traffic jam on that day?"
  • "What about my salary if I change my role?"
  • "Oh this whole self-selection thing is just fake, management will maintain control, they won't put that much trust in people."
You can imagine how this list went on. In the end, I'm really happy that our concerns vanished into thin air. Our board and management actually did put a lot of trust in our people, our CIO ahead of everyone. And the people did take it as an opportunity. After three iterations of trying to find the right team setups, every team member was happy with their choice, just as management and the board. We identified only two teams for which we needed to hire people having the missing skills. The other teams could also use support, but were already able to deliver value. Overall, everything worked out way better than we even hoped for. We were exhausted - but enthusiastic about our new teams, ready to celebrate and kick it off.

What now?

That wasn't it. After the event was before our so-called ignition period. Several products had been re-designed or even freshly added. Some teams were starting from scratch. Some teams split into two. Previously existing teams ended up with different members. Some people changed their role. It was obvious that we needed to consider a certain transformation period and invest in team liftoffs, as Diana Larsen puts it (check out her Agile Testing Days 2017 keynote to learn more).

Personally, I decided to stay with my former team, just like most of my teammates. However, we lost one of us to another team and did not get any new member. Still, we changed. So we decide to take this opportunity to form our team from scratch, to "re-ignite" it.

Right after the event, it was pretty hard not to fall back into old habits and just continue with "business as usual". We knew each other already, had all skills covered in the team, and could simply pick up the next backlog items to work on. On the third day after the event, we finally forced ourselves to pause for a moment.
  • To learn more about our team and uncover what's hidden, we created a team canvas together. This workshop format helped a lot to share our thoughts, our values, our goals, what moves us, who we are - to find our own new team identity. We decided on what we want to achieve together as well as new working agreements.
  • We moved to another room and took this chance to change our seating layout. We wanted to make it obvious that the team actually changed. To try something new. To get rid of table islands, foster team spirit and hopefully ease communication and even closer collaboration.
  • We heavily brainstormed to select a new team name, logo, slogan, theme song, and more. This way, we learned a lot about us on a personal level which brought us a step closer together. We were surprised how hard it was to find something from popular culture that we all shared and loved, as we're quite diverse in any aspect.
It's been only two weeks since the redesign event. However, I feel we now laid the groundwork for our new identity. I have the impression our team feels revived and shows fresh energy. And I hope we can keep it up to achieve our common goals and continuously improve as a team.

Monday, May 22, 2017

Agile Testing Essentials LiveLessons - A Review

Do you like video courses? Maybe you prefer them over reading books? In my case, I enjoy all kinds of media for learning, with a mixed approach working best for me. When I heard that Lisa Crispin and Janet Gregory are working on a video course about the essentials of agile testing, I knew I had to check it out. Their books Agile Testing and More Agile Testing accompanied me on my personal learning journey and provided great advice in many situations. So I was curious how Lisa and Janet would convey the essentials using videos and what I still might learn from them.

Content

The video course contains the following six lessons on agile testing.
  1. Lesson 1: Introduction to the Whole Team Approach
  2. Lesson 2: Test Planning in Agile Contexts
  3. Lesson 3: Shared Understanding through Early Testing
  4. Lesson 4: Automation in Agile
  5. Lesson 5: Agile Exploration
  6. Lesson 6: Ingredients for Success
All these essential parts of agile testing are addressed in a condensed form. Of course there is way more you might be able to talk about, but it would have exceeded the scope of conveying the core messages. For more information, Lisa and Janet refer to their books and encourage you to dig deeper yourself. As a starting point, they added a great list of recommended further readings to the course.

Format

The video length ranges from a a few minutes to about ten minutes, which feels just right to be able to pause and resume any time. To get a first impression yourself, you can watch the introduction video for free. However, please be aware that this is the first video course Lisa and Janet did so far. As with every new experience, you learn as you go. In my personal opinion, the introduction video is not representative of how the two present their content throughout the course. With every lesson they get more used to the format and present way more naturally. To be honest, I love that this shows that we're all humans and constantly trying to improve.

Structure

In each lesson, Lisa and Janet first present the key concepts and then ask the viewer to do a few small exercises. This way you can instantly apply the theory. They have you pause the video and think how you would answer certain questions in your context, or which examples and cases you might think of to explore a sample application. I loved how they got me actively thinking and involved at any point. I just couldn't help comparing the presented ideas with my own situation, and found myself making lots of notes what I would love to try next with my team. Furthermore, they share their personal experience about many topics by telling stories from the teams they worked on. I especially enjoyed this part, as it combines the theory with "the real world", showing how they gained and applied knowledge. They also share how experiments might fail from time to time, making clear that failing is an essential part of learning.

Target Audience

In this video course, beginner testers find condensed essential knowledge, providing great guidance on their way to grow. However, I would still recommend them to read Lisa's and Janet's awesome books. In my point of view, the video course is not a replacement for them, but it is a great starting point.

More advanced testers probably know about most concepts (and most probably have read both books already). Still, the course is a great reminder of the basics and might trigger one thought or another. Although its content had not been new to me, the course got me thinking on how to better convey these essentials to my own team and company.

Which leads me to my most important point: This course is not only useful for people identifying as testers, especially as those most probably would not read the agile testing books. I warmly recommend it to everyone working in agile environments, as agile testing is in its core a whole team topic and everybody should know about its essentials.

Saturday, May 13, 2017

Thoughts about Testing in a Mob

This was not the first mobbing experience for our team, but the first one to complete a whole story using this approach. One key factor that the team agreed with mobbing at all, was that our mob size changed dynamically. Whoever wanted to join the mob was welcome any time, and whoever preferred to work on other tasks could do so as well. This way, our mob consisted of three to seven persons. The downside of this approach was that we did not always have all the knowledge at hand but had to ask asynchronously for feedback. Still, we had enough knowledge available to stay productive and make progress.

Personally I decided to always stay in the mob. As a team player, there was no other option for me. As the person who triggered that we give this approach a try, I was curious how it will work out and did not want to miss this learning experience. And as the only person identifying as tester on the team, I felt staying in the mob was just perfect to trigger tests, provide feedback, raise questions, and seek answers as soon as possible. This way, I felt another downside of the dynamic mob size: As some teammates decided to work on their "own" stories, I missed to provide feedback on those as early as I could (though of course others could have stepped in). Luckily the mob selected a story we needed to complete to achieve our sprint goal, which justified that I spent all my efforts there first.

After we finished our story, I was feeling proud. This was really a joint team effort and we all had our hands on the story, ensuring quality from different perspectives. But one thing made me think: Shortly before we decided that our changes are ready to be merged, one colleague challenged this by raising the question who does testing of the story. At first this puzzled me, as we had included testing all the way from start to finish. So I answered that the mob tested the story thoroughly. But this teammate was not convinced that you could possibly come up with all necessary tests in the mob.

As he could not tell what else to test, and the current mob agreed that we covered everything from quality perspective, we merged the story nonetheless. But his comment left me wondering. Did we forget something? Should we have something done differently? Should we have not allowed for dynamic mob sizes as particularly this colleague did not join all sessions? Which reasons did he have to think that testing cannot be done in a mob? Is there a trust issue?

Naturally, I don't have all the answers but I will keep an eye on this issue. To gain more insights, I decided to join Maaret Pyhäjärvi's tutorial at Agile Testing Days 2017 about Mob Testing. Still, my biggest hope is that my team continues working on actual stories as a mob to gather more experience ourselves and learn by doing.