Monday, September 18, 2017

A Long Story Cut Short - The Importance of Pausing to Think

Today was the day. My team released a huge epic introducing major changes in our application. Normally, we release many changes during our daily release slot. However, this release was unusual in itself, and it taught us a bunch of important lessons.

We started working on the epic on July, 11. As we had discussed the topic several times before, the whole team felt that we had a shared understanding and were ready to go for it. During the first two weeks only one developer focused on the topic, and gained first insights on how complex it actually was. He raised the issues he was facing and called for support, especially as delivering this epic was our highest priority. We decided to have the whole team step in and share the work load. We still highly underestimated how far this would go - or rather, how far we would let this go.

The whole team, meaning five developers, our product owner, our agile coach, and me as tester delved into the topic. And together, we gave birth to a monster. With every little change the whole solution got more and more confusing. It was incredibly hard to figure out what was expected and what was unexpected behavior, and especially how we would ever be able to understand our implementation in the future again. And by "future" I mean half an hour later. Everybody was having a hard time. Nobody was happy with what we did. The amount of curses increased rapidly. We all felt we would soon go insane. One teammate even suffered from nightmares and sleepless nights. We are really not proud of this tragedy, but this should give you a pretty good idea of what was going on.

Desperately, we discussed again and again if there would not possibly be any other way to fulfill the business need but also enable ourselves to keep our application maintainable, extendable, and last but not least testable. However, our discussions turned in circles. So we pressed on with implementing the epic, eager to get to a minimum viable version for which our product owner would let our users access our test system to get their feedback.

The fun fact - or rather really sad truth: As soon as we were ready to start the user acceptance test, one developer took the time to create a completely new prototype, based on a totally different assumption. And after only half a day, on August 30, he was ready to share his new approach with the team, to have them challenge it and find flaws in his thinking. We were stunned by his simple approach. We raised some questions, but couldn't find any reason why not to go with it. By only doing one thing differently, everything else became a lot less complex. Comprehensible. Consistent. Doable. With way less effort and way less changes in our application. What he did? He threw a convention over board which everybody had considered as a fixed precondition. You know, as soon as you have to handle x, everybody strongly recommends to do y to avoid problems. We had never challenged this assumption we had in our heads, all of us had accepted it as a given. But in the middle of implementation, it turned out that this convention made everything really bad for us. Neglecting the convention instead was fitting way better in our context, from business perspective as well as technical point of view.

Shame on us that we had to go such a long and winding road of learning how not to do it. Nobody had put pressure on us but ourselves, not our product owner, not our agile coach, not our stakeholders. We ourselves were driven by the thought that we have to get this done and finished as soon as possible, making us pressing forward without taking time to actually think and experiment early. The team even "temporarily" discarded our rule to stop starting and start finishing, meaning that all developers continued to start working on new topics before former ones had been completed. Unsurprisingly, this created lots of bottlenecks and context switching, making the whole situation even worse. And as soon as one of us felt we have a bit of time to breathe again - he found the clean solution.

To cut a long story short: within a few minutes of discussion, we wholeheartedly threw away our first implementation on which we had worked for nearly two months by common consent, in favor of this new and easy approach which we in the end fully implemented within about one week. After going through all this, we couldn't but ask ourselves in retrospect how this could have happened and why by all means it took us so long to challenge our assumptions, learn, experiment, and see the solution. But in the end we did learn the following.

Conventions are recommendations but not carved in stone; they might not apply or be a good fit in your context. Think outside the box (that you might have created for yourselves) and experiment early with different approaches. Don't get so busy that you cannot pause, breathe, and think. And last but not least: Don't be afraid to kill your baby, especially if it turns out to be a monster.

Bonus read: By coincidence or not, when thinking about publishing this story I came across the post On Real Options and Speculative Investments by Liz Keogh which nicely reflects many facets of our story. Besides the fact that I really relate to the core messages, it's a highly recommended read.

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.