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.

Thursday, May 4, 2017

Mobbing - Take Two and Take Three

Two days ago, my team had quite a tough retrospective, openly addressing the issues we have in the team. Mobbing was named as one approach to improve knowledge sharing as well as challenging potential implementations. So we decided to mob again on the next day. In addition to the feedback on our first mobbing session, there was a strong wish to do things in a more informal way, more spontaneously, and with a more dynamic mob size.

Take Two

We decided not to book a separate meeting room but use our office, since we have our own big TV screen and quite some space upfront. We figured if this would work, we could mob way more spontaneously. We share our office with another team, so we wondered whether mobbing would disturb them more than other discussions we normally have in the team. We decided to "not ask for permission, rather for forgiveness" and just try it. And it worked out pretty well.
One of our longtime working students just started working full-time. Since he missed our first mobbing session, I provided a short introduction to the key concepts, emphasizing the rule that you're valuable in the mob if you are either contributing or learning.

This time we picked a large, complex story introducing new technology into our product. We considered it crucial to have the new knowledge shared with everybody as soon as possible.

According to the feedback from our first mobbing session, we decided on a longer and not so strict rotation. We set the timer to six minutes. When the alarm set off, we had the navigator finish what he wanted to do, and only then rotate. This rather event-triggered approach was really well received.

This time we had one team member working from home office, so he could only join remotely. As we don't have a technical solution to grant control, but only can share our screens, he could not become the driver. The mob had the impression that our remote team member felt left out, and he himself confirmed that the technical setup did not work well remotely.

After a two hour session, we finished with a short retrospective what we liked and what we longed for. Again the team loved the knowledge sharing aspects, the learning, the different approaches, the collaboration, the team building. Even though we had yet another developer laptop with yet another keyboard layout and no mouse available, it worked really well. People were a lot more willing to adapt to the unused layout. And the best thing was that when finishing mobbing for lunch time, we had a working increment! On the other hand, some doubts were raised whether the driver / navigator pattern really helped us or rather held us back. Productivity was again questioned. Also, we longed for more preparation and discussion upfront before actually starting with the implementation.
Still, the team agreed to continue mobbing on the story as we introduced new technology here and it was important that everybody on the team shared the knowledge. We agreed to try an even less formal approach for the next session, without strong navigator / driver roles and instead rather have everybody contribute on the fly. Last but not least, we also agreed to try a more dynamic mob size, with people being allowed to leave (like for personal meetings) or join anytime.

Take Three

Today, we gathered around our TV again. This time all co-located. Still, we had a team member in the mob who missed the last session, so we started by getting him on board what the story is about and how far we got. Then we continued with a short discussion on the open things to do, potential solutions, and agreed on the next step.

We had everyone on the mob, being allowed to contribute, even the one on the keyboard. We did not use a timer anymore, but still rotated the one at the keyboard about every fifteen minutes. We had a third developer laptop with yet another keyboard layout and even operating system - and again, it was not much of a problem anymore.

We also had the case that one developer left for a meeting and afterwards rejoined the mob. It didn't cause any issue. I had to leave for a conference call in the middle of the session myself.

After two hours, the team came to a point where they got blocked by another story currently in development, so they decided to stop. We didn't do a formal retrospective anymore, just asking around for opinions. We found that we really like this pretty informal approach, still with only one laptop, but with everyone contributing. We liked that the mob still rotated the one at the keyboard from time to time. We loved that everybody could speak up and contribute ideas. We loved even more that this session was received way more productive. All agreed they were happy with this format!

What Next?

The team wanted to give mobbing a try at least three times to find out how this approach might help us. Well, we've done three sessions by now, so our initial objective is accomplished. Originally, I wanted to keep the strict format for a longer period. However, I feared that the team would reject mobbing itself then, so now I'm really glad that we instantly adapted and tried a more informal way. I'm also glad this worked out with everybody still speaking up and being heard. As they liked this informal approach, I now see the chance that the team will not only include mobbing in their toolbox, but also make use of this tool, at least from time to time. I'm curious if a trigger will still be needed to break old habits and remind ourselves of this option. But I would love to see that happen.

Friday, April 28, 2017

A Thousand and One Things

The last weeks had been quite busy at work. When I think about all the things and topics I worked on, I'm getting dizzy at first, then excited, and finally thoughtful.

Although I love focus, I also love contributing to many topics. And I learned that I should just do what I like to do if I think it's worth spending my time on. Well, this could be considered good ("you're not just delivering what's asked of you but providing additional value") - or bad ("you're not focusing on your actual task"). During the last months, I received mixed feedback from several people about my involvement in many areas which got me thinking about this topic a lot. So I decided to reflect on what I actually did during the last three weeks since we had the first mobbing session in our team.

  • Lots of testing. My team made really good progress, collaboration mood was high, backlog items flew nicely through our workflow. Investing time upfront, before a first increment is implemented, paid off again. Brainstorming things to test, clarifying questions, trying to reach shared understanding together with product owner and developers, and also testing early increments, was again well worth the time. Though it might sound counter-intuitive ("you have to do the work twice then"), it speeds things up a lot for me. And it leaves a great feeling of being "on time" with providing feedback, instead of "always late" when tickets suddenly pile up.
  • I've been sitting with some of my developers, pairing on trying out different implementations, debugging, or fixing identified defects. I love doing so, but currently don't prioritize it high enough to do it more often.
  • As we have a new developer on the team, I had a few onboarding sessions with her to provide an overview on workflows, product history, company backgrounds, and much more to get her started.
  • My team is giving peer feedback a try, so I've provided written feedback for my teammates. Though I think I should provide feedback more often and rather face-to-face, I really like this formal instance. I feel it helps me discipline myself to provide regular feedback also on a personal level, not only on things we are working on. When it comes to providing feedback on personal level, I'm not confident enough that I'll find the right words in a face-to-face situation to help the other grow without offending him. So in the end I mostly either say nothing (which I feel is pretty bad, and also a missed chance for the other one) or I address things in team settings (like a retrospective, which is often not the right place for personal feedback). Getting the chance to take the time and carefully formulate the feedback before providing it, helped me a lot. The only problem: I don't know how the others interpreted my feedback and responded to it.
  • We've just officially introduced OKRs (objectives and key results) at my company. As I happen to be in a supporter role to help kick this change off, we regularly meet to reflect and decide on next steps.
  • We also happen to think about an official company tech blog. I highly support this endeavor, so I agreed to join the group of editors.
  • To further increase our perception as tech company, we are striving for hosting more meetups at FlixBus. I'm part of the organizing group, and we even had two meetups hosted a few days ago. That was a great first step, but further steps have to follow.
  • We have an internal agile testing community at FlixBus, open to anybody interested in testing. As community moderator, I prepared another internal meetup. This time, one colleague shared her insights from TestBash Brighton, and another one her lessons learned from implementing a new onboarding concept. Thanks to my fellow community members, I learned a lot!
  • As community moderator, I am frequently the first contact person in case someone needs input regarding any testing topic. One of our people managers asked me for a rough list of skills and topics I would see for an agile tester. Hard topic! Made me ask questions first, like why this is required and what exactly is needed.
  • Another colleague contacted me if I could support during an ongoing audit where the auditors wanted to gain more insight in how we do testing. So I provided a collection of materials.
  • A tester from the international testing community approached us and asked whether we might offer one of our products as system under test for the meetup he organizes. Great opportunity for both of us. I connected the right people so they can proceed on the topic.
  • We received several more applications on our job offer for software testers. For now I only reviewed materials and provided feedback, but probably I'll find myself sitting in interviews soon again.
  • I supported a tester colleague with registering for this year's Agile Testing Days including booking hotel and flights, and did so myself. We both will attend the full week and can't wait for it!
  • A fellow team plans to introduce automated tests through the UI. They asked me whether I might share how we deal with automated tests, on which levels we test, who writes them, which tools we use, etc. They wanted to learn how we do it and see what might fit to their context as well. We had a quite interesting conversation, I'm curious what they will decide on during the next weeks.
  • The tester of yet another team asked me whether I could give a testing workshop for his team and share how we handle testing in my team in general. He simply wanted his team to hear about testing from a different person and perspective. During the first part of the workshop, I shortly introduced the developers to exploratory testing, and then had them engaged in a hands-on testing session. I did this with three different groups already, and it's always been fun! I had a great time, but also the developers enjoyed approaching the product from a different perspective and finding many issues in short time. As second part of the workshop, I presented how we do testing in my team and our context: our whole-team approach to quality, testing throughout the workflow, what kind of tests we run and on which levels and systems. Especially our vacation replacement rules, having the whole team take over all testing, caught attention and we had a great conversation. Hope I could trigger some thoughts and ideas.
  • A colleague and I hosted an agile UX workshop for our teams - using LEGO! We had so much fun together. Well, we had LEGO, right? The workshop was inspired by one I attended at last year's Agile Testing Days, hosted by the wonderful Karen Greaves and Samantha Laing. Big thanks to them! If you have the chance to join one of their workshops, do so, it's worth it.

One more thing I learned during the last weeks: I've been selected as new voice to speak at TestBash Munich in October! I'm so happy about it and looking forward to take you on quite a personal journey with FlixBus.

All in all - I do understand why I received mixed feedback regarding my many activities. It's definitely great food for thought. So far, I've not decided in which way to adapt. But I wonder what they might think if I also told them about the many topics I don't involve myself, or the many more ideas I intentionally postpone?