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?

Thursday, April 13, 2017

Our Team's First Mobbing Session

Last week my team had our very first mobbing session together. I was quite excited! I have read and heard a lot about this whole-team approach, and I was curious to try it myself. I had a first glimpse of how it could look during a coding dojo I attended a few weeks ago, but I really wondered how it would be to try this with the people I work with every day. I guess I talked a lot about mobbing, presenting it as a potential solution for some of the problems we are facing. And suddenly, during a sprint retrospective, my team decided to give it a try! Here's the story how it turned out.

Facilitation

Since I was the one who triggered this experiment, I was also accountable for having it facilitated. However, I also wanted to join the mob myself. So I asked our agile coach if she was willing to help me and act as facilitator during the session. So glad she agreed!

As nobody on our team ever tried mobbing before, I wanted to have our first session facilitated as well as possible to get everybody on board. To prepare for it, I used the following valuable resources on mob programming and mob testing. You can skip over them for now, but in case you would like to facilitate a session yourself, I highly recommend following those links.
All resources recommended starting with a short session, so I scheduled 2.5 hours for it. As we don't have a dedicated team room, I also booked a meeting room well in advance, as otherwise it's hard to get one for a longer time slot at my company.

Our agile coach and I sat together to prepare the session. We shared any knowledge we already had about mobbing, defined the structure and prepared posters to serve as information radiators throughout the session.

I asked my team whether they would rather do the experiment in coding dojo style using a dedicated kata, or if they wanted to work on a real story from our backlog. The team decided unanimously to go for the latter. During sprint planning just before our workshop, we picked a middle-sized, quite straightforward story and reserved it for our mobbing session.

Room Setup

We knew how the meeting room we booked looked and what it offered. We identified a list of things we had to bring ourselves.
  • One developer laptop with an external keyboard and mouse; to simplify things, I just asked one of our senior developers to bring his (as it happened he brought an external Apple touchpad)
  • One projector; the meeting room was lacking one
  • The posters we prepared
  • Flip chart sheets and tape to put them on the wall (in the end we found the room actually did have a proper flip chart)
  • Sticky notes and pens
  • Timer
  • Beverages; everybody should bring what they need
  • A bowl of cookies :)
What not to bring? Any other laptops or mobile phones, to avoid distraction. Though this might change later on, we decided to be strict about this for the first session to have the full focus of every team member on one thing only.

Agenda & Introduction

Our Daily Scrum is scheduled for 9:30 am. We decided to do a morning session, starting right afterwards. However, we knew that it will take some time to bring everything to the meeting room and to set it up, so we could only start with everybody at around 10:00. Also, it was crucial to keep the session relatively short in order to end happily and go to lunch together.
We scheduled a short introduction to mobbing to start our first session from a common ground. This was especially important as nobody on the team had experienced mobbing before.

Following Simon Sinek's advice, we decided to start with "why".
  1. Remove productivity blockers. Many times when it comes to mobbing, the question is raised how having the whole team work on only one topic could be productive. However, Woody Zuill recommends focusing on impediments, preventing or destroying productivity. Like the following things that mobbing can overcome:
    • Multitasking
    • Interruptions
    • Being blocked
    • Technical debt
    • Code cruft
    • Waiting for information or reviews
    • Unnecessary meetings
    • Incomplete understanding, or not understanding the problem at all
    • Context switching
    • Merge conflicts
    • Lack of quality
    • Missing knowledge
  2. Extend our toolbox. To learn continuously, we should be open to new or different development approaches and know our options to chose from. We might not end up doing mobbing all the time, but it might be a great way to tackle huge, complex, unclear stories.
  3. Learning opportunities. Mobbing maximizes learning and sharing knowledge in the team, often including implicit knowledge. This way we can increase our bus factor even more. Besides that, you can always learn new things in a group, as everyone is used to different approaches, thinking styles, even keyboard shortcuts; so look out for the unexpected! Furthermore, teams who do mobbing say that it's like instant onboarding for new team members. As it happened, only two days ago a fresh new developer started in our team. Perfect timing to find out if mobbing as onboarding works for us.
  4. Get the best out of everyone. Last but not least, mobbing is actually not about getting the most out of the team and keeping everyone busy. We all have good days, but also bad days. When coding solo, the good and the bad both go into the code. But a mob will prevent the bad from being introduced into the code. Mobbing is about getting the highest possible quality out of the team.
To explain the basic idea of mobbing, we used Woody Zuills famous quote: "All the brilliant people working on the same thing, at the same time, in the same space, on the same computer." As recommended, we decided to do strong-style mobbing for our first session, following the driver / navigator pattern. So we also introduced the key concept of strong-style pairing, as defined by Llewellyn Falco: "For an idea to go from your head to the computer, it must go through someone else's hands."
In order to explain the roles used in strong-style mobbing, we had put small cheats sheets right beside the location of the role (except for the facilitator).
  • The driver. The one at the keyboard, acting as smart input device. There's no thinking at the keyboard, just do it!
  • The navigator. This is the main programmer. State the intention, maybe add the location you're referring to, maybe you even have to go down to the keystroke required next; whatever is the appropriate level of abstraction for the current driver.
  • The mob. The rest of the group. What do they do? Checking the navigator, contributing insights when appropriate, preparing for their own turn as navigator.
  • The facilitator. Observing the group from behind the room, jumping in whenever required to ensure principles, roles and rules to create a safe experience. In our case, she also was queen of the timer. This role is helpful when you get started; it should not be required anymore later on.
We defined the following common rules to make the session successful and valuable to everyone.
  1. We treat everyone with kindness, consideration and respect. Be kind. Listen to each other and consider all the options; everyone on the team should be heard. Let the others shine! And always assume that the person before you did the best they could with the knowledge at that time. The mob should be safe to experiment. It should be safe to learn. This experience can be scary at first, especially for those who normally don't code (like me) or are rather introverted (like me at most times).
  2. We say "yes, and...". This rule comes from improvisational theater and basically reminds us, instead of destroying what the one before us just implemented, continue with what we have and build upon it.
Providing examples on a whiteboard or flip chart can help as well. Or thinking in English, not in code. Going small steps, committing frequently. Do you see several solutions? Well, try both, the weirdest one, or the one from the most junior person in the room first. The mob format can work if you are either learning or contributing.
 To finally get us going, I concluded the introduction with a few more hints.
  • We offered a flip chart if anyone wanted to foster shared understanding visually.
  • We provided sticky notes and pens for whatever thought they wanted to note down, such as for their time as navigator or for the retrospective later on.
  • The rotation: The navigator becomes the driver, the driver joins the mob, the next one from the mob becomes the navigator. We decided to rotate every four minutes as recommended for beginners. Later on this could be less strict, we could try different times, or rotate more fluently, whatever the team feels is right.
  • Now let's have fun!

Mobbing

We had predefined our very first rotation in advance. As we had our Product Owner on the mob who never coded before, myself having only basic programming skills, and a fresh new programmer on the team, we intermingled with the others to make sure that we didn't end up in a driver/navigator constellation where we instantly get stuck. Furthermore, we defined two core developers starting as driver and navigator, which proved really helpful to kick everything off and get things started.

During the session, the hardest part was to keep the driver from thinking and rushing ahead without waiting for the navigator. In the beginning, the mob was quite unsure how to contribute, but soon learned to give advice when asked by the navigator, or even offer that voluntarily; but to always have the navigator decide which way to go instead of directly addressing the driver.

With the quick four minutes rotation, we managed to have everybody on the team become navigator and driver at least four times, so we could get used to those roles and learn how to pick up and proceed with the implementation. At first, the rotation in the mob from chair to chair was strange, but quickly became normal. Having the bowl of cookies in the middle of the table definitely helped! ;)

What instantly became clear: Even with a quite straightforward story, we struggled with being navigator. Several of us often required support from the mob; not only those who didn't identify as a programmer or were new to the team. And we struggled even more as driver, having different operating systems installed (OS X versus Linux), different keyboard layouts chosen (German versus English), different shortcuts defined, different scrolling directions set, and different input devices in place (external Apple touchpad versus Apple mouse versus default mouse). This turned out to be quite frustrating; at points, this made everyone look like it was their first day using a computer.

Retrospective & Closing

We decided to have a short "What I loved" and "What I long for" styled retrospective, with everybody writing down their thoughts on sticky notes and presenting them afterwards to the rest of the team.

What we loved:
  • Knowledge sharing. This feedback came from almost everybody on the team. We loved the sharing aspect in general; but especially learning more about a particular implementation, about how to solve common issues, and about different approaches to tackling a problem. Or simply how to start with a story regarding the thought processes involved. The most interesting finding here was that not everyone, I mean not every programmer on the team, shares the same knowledge of the existing source code.
  • Learning why we do specific things. It was really helpful when the navigator explained why they wanted to do something, or what's the background of doing it like this (such as "leaving this parameter out will make it the default").
  • Interaction and collaborative mood. It was a really inclusive atmosphere! Our new team member loved getting advice from the more experienced ones. One of us even mentioned it felt like team building.
  • Everyone can contribute. Our product owner said he was surprised that he could understand and contribute so much, although he never programmed before. He loved to see the code and its structure as well as to gain a better understanding of what the team does all day.
  • Driver/navigator and mob roles. The strong-style navigation and mobbing itself was regarded as an interesting approach.
  • Room setup. Our preparation proved valuable, the setup worked well for us!
  • Fun. The atmosphere was focused on learning and finding our way to get things done, but we still had a good time together. Especially when one navigator asked his driver to "please make three children"! :D Oh and don't forget the cookies; they always help! :)
What we long for:
  • A driver setup everybody can get used to. As we struggled a lot with different operating systems, keyboard layouts and shortcuts, we really longed for a commonly accepted setup; especially a normal keyboard and mouse. Well, define "normal"! ;-)
  • Finish a story as a mob. In our first session we could not complete the story we had chosen. Not even the implementation, let alone testing and all other activities included to get a story done. Which was a pity because we couldn't share knowledge about those parts of product development. So, we long for getting a story at least to the status that it's merged to the common code base.
  • Try mobbing for a more complex story. The team selected a medium-sized straightforward story. However, our product owner is eager to try mobbing for more complex features. Probably to see if this approach would really help us to tackle those.
  • Faster reload time of our web application. This is not directly related to mobbing, but it became pretty obvious that a simple page reload of our application costs a lot of time. As we decided on rotating every four minutes, we really felt the pain of having everybody waiting for the page to reload, shortening the time the navigator and driver had to proceed with the story a lot.
  • No thinking, won't you? People felt it was really hard to break their habit of thinking and working on their own when sitting in front of a laptop.
  • Less context switching. This point came up with regards to the frequent switch between the different roles; longing for a longer rotation duration. I totally agree with experimenting to find a rotation time suiting us. Still, this feedback took me by surprise at first, as personally my experience had been exactly the opposite. I'm used to switching contexts many times a day. Though I try to limit them wherever I can control it, many things can pull me out of my zone and flow. Therefore, mobbing was a total relief for me, enabling me to focus on one thing the whole time, staying in the same overall context.
  • Productivity. No surprise, there are still a lot of doubts whether this approach is really productive as opposed to working solo. But we don't have any proof of that yet.
As part of the closing we thanked everybody for giving mobbing a try and for their feedback. We agreed to put the started story back to "To Do" and the first developer with free capacity will pull it. Finally, we asked all team members to vote whether they would like to do a second session. The majority agreed, some were undecided. In the end, we kept our timebox and left the room in time for lunch - in a happy mood! :)

Personal Conclusion

In the end, I'm really glad my team agreed to another session. Can't wait for our next learnings! Besides that, I'm feeling a lot more prepared to facilitate mobbing sessions for other teams as well. Some had heard we wanted to try this approach and showed interest themselves; one agile coach would even like to join our next session to watch and learn. Well, for now we only know the lessons of our very first session. But if you want to give it a try in your team, feel free to copy whatever you like and adjust it to what you need. I would love to hear about your learnings as well!

(Oh, and by the way: did you find the bug in our posters? ;-))

Tuesday, April 4, 2017

Share Your Story, Too!

Ever thought about speaking at a conference? Well, let me tell you the story how I ended up with 10 submissions of 6 unique paper proposals for 3 conferences in 2017. If you would have told me this story one year, or even half a year ago, I would have thought "hey, nice story"; but I wouldn't have believed that it was about me.

So what triggered me to answer a call for papers at all? So far, I've only been to one conference in my life, which happens to be Agile Testing Days. I attended in 2015 for two days. I was eager to join the full-day tutorial of Lisa Crispin and Janet Gregory, not only because of the interesting topic, but because I was really excited to meet them in person. Especially Lisa, as we had contact via Twitter before. After the tutorial ended, I took my chance to have a few words with her face to face. And she told me: "Hey, why don't you submit a talk yourself, you certainly have a story to share!" Back then I probably blushed and laughed it off; I felt appreciated just by the idea, but was definitely not ready to take it any further.

In 2016, my company enabled me to attend the Agile Testing Days for the full week. I had learned to appreciate the huge community part of this conference, so last year I was ready to broaden my network and get to know more people along with their stories. One day during lunch, I happened to find myself at a table with three guys from all over the world, among them Toyer Mamoojee. We all had attended the conference's opening keynote by Abby Fichtner, Pushing the Edge on What's Possible. This talk set the stage for the whole conference, encouraging us to face our fears and be brave. So we happened to start talking about what scares us the most; and speaking at a conference was definitely something Toyer and I shared as a major fear. Suddenly he said: "Let's make a deal. If I submit a paper for next year's Agile Testing Days, you have to submit one, too; and if you do, I have to do it as well. Deal?" He took me entirely by surprise. For a short time I felt snap-frozen - but then remembered what we heard the last days. That we have to step out of our comfort zone to see the magic happening, and that we should do one thing every day that scares us - so I accepted the deal. I couldn't believe I had agreed so quickly, but Toyer did not let me get away with this anymore! ;) He even told everyone waiting for the next keynote that we both now have a deal and will return with a paper next year. No excuses.
https://toyerm.wordpress.com/2017/01/31/agile-testing-days-2016-a-testing-experience-of-note
The following day, I attended a lean coffee session together with Viktorija Manevska. I met her already in 2015, but last year she came to the conference as first time speaker. She was so kind to share this experience and tips with the rest of the group. Everything from writing a paper proposal, receiving feedback on it, going through the approval process, creating the actual presentation, and giving her very first conference talks. The topic was so fascinating for the whole table that we voted to continue with it for quite a long time! :) Viki also kindly offered her support in case anyone of us wanted to submit a paper themselves.

Now you know about my triggers to actually work on a paper proposal for Agile Testing Days 2017. But how come I submitted even more?

Back at the office, I started telling my colleagues about my personal challenge this year; to support the fact I really had to submit at least one paper. Furthermore, Toyer and I held each other accountable on our deal, so we started brainstorming potential topics to speak about. Topics we could do on our own, but also considering a topic we could do together. Kicking it off triggered another idea. I knew that TestBash will be coming to Munich this year, and that the related call for papers was still running until mid of February. So I thought: why not also trying to submit there as well, so I could get to know the whole process and gather first experience? As a side effect, this triggered me to work on my paper proposals even earlier. Three of my awesome colleagues volunteered to provide feedback: John Webber, Alex Kiefer and Viola Korte. I discussed my ideas with them and included their valuable feedback in my first proposal drafts. After several iterations, I had two topics I felt comfortable sharing my experience on, hoping that a potential audience would get value from it. Still, to start small, my first challenge was just about submitting a paper and getting feedback on it; not about getting it accepted (though I tried to aim for that of course). You can't imagine how happy I was when I met the submission deadline for TestBash Munich just in time! First personal achievement unlocked. The submission confirmation page told me that I wouldn't get any feedback in case I would not be accepted, as they keep the proposal for potential future conferences then. Well, I didn't get feedback yet; but hey, it was a great learning experience.
On the very same day, Viv Richards saw my tweet, contacted me and asked whether I would also consider to submit my papers for the conference he is organizing, SwanseaCon. I was stunned. I had never expected such a reaction! So I thought: "Why not?" And submitted. And after a few weeks, just one day before going on a longer vacation, I received the confirmation that one of the proposed talks had actually been accepted!!! Still can't believe it. Totally honored and thankful for that opportunity. I'll be talking about learning agile testing, and this speaking experience will definitely become part of my journey.
Meanwhile, work on the paper proposals for Agile Testing Days continued. Toyer and I identified a fascinating common topic we were eager to submit as a workshop. Remembering Viki's offer to support with paper submission, I contacted her and asked for feedback; and she returned the question whether we could also do a topic together. Sure, gladly! Within several calls we shaped an intriguing common topic to do a workshop on. So I found myself working on four topics at the same time. Then the official call for papers started, and I finally gathered my courage and contacted Lisa Crispin, asking her whether she would kindly review our paper drafts and provide feedback on them. Her most surprising answer came quickly. Sure, she'd love to provide feedback; but hey, the conference organizers offered her to do a workshop together with a new voice this year - whether I would like to do it with her? Wait, of course!!! We also found an exciting topic and I loved our close collaboration so far. I still can't believe I am actually getting the chance to do a session at this year's Agile Testing Days - and that together with Lisa! I consider myself really lucky.

Did you notice that was paper number 5? Last week, Jan Jaap Cannegieter contacted me and offered his help to review my current proposals and maybe do one together. I couldn't resist and agreed to join in on one of his workshops as co-speaker, so this is the bonus paper number 6! ;)
Having submitted all six papers is feeling just great. Having been accepted by two conferences as a total newbie speaker is such an awesome feeling I cannot described it properly. Well, I now have to do my best to live up to expectations. I try not to think about it too much, but instead keep moving forward to not fall into the hesitating self-doubting trap again. Full focus on learning.

With all those great feelings involved, the best part of this story, however, is the collaboration with those most awesome people. I can't emphasize that enough. We shared our stories and experiences. We worked closely together going through many feedback loops. We are proud and excited about the results and really hoping our proposals get accepted because we think they really would be worth it. Fingers crossed! This experience of writing paper proposals, not only on my own but especially together with my testing peers, was worth it a thousand times already. My great hope is that many more people get inspired to be brave, step up and share their stories, too. I bet all of you have awesome things to share with the rest of us!

So this is the story how I ended up with 10 submissions of 6 unique paper proposals for 3 conferences in 2017 so far, getting accepted by 2 already. I'm still speechless. Totally excited. And truly grateful for the inspiration, motivation, and support of all those great, great people mentioned above who are sharing this part of the journey with me. I hope that one day I can help a new voice to her first conference talk myself.

Thursday, March 9, 2017

Last Week's Lessons On Pairing, Mobbing and Collaboration

Last week I experienced three great examples of collaboration. Although quite different, all of those proved insightful and fun.

Performance Spike

Our application is currently performing poorly, to the point that we get complaints from our users. Although we had been aware of the situation slowly getting worse, there simply had been more value in working on other topics with higher priority. Now we have to pay the debt for this decision. To identify the major root causes, we agreed on doing a spike with the whole team, having everybody work on the performance topic for two days.

After an initial brainstorming of potential root causes, we split up to investigate the areas where we suspected the highest improvement potentials. Some people started working on their own, some in pairs. I happened to pair up with a programmer, profiling the application as well as implementing and testing quick wins. I really enjoyed this quite rare experience to pair up on doing hands-on stuff. Normally we only pair up on demand, when clarifying questions, discussing tests, or reproducing an issue. This time we could instantly share knowledge on how we approach problems, how we use tools, where we suspect which kind of issues. Sitting together and directly improving the product was great and just felt right. The other pair also heavily appreciated the joint effort as they could share knowledge and experience and help each other grow.

My personal lesson learned: Pair up more often in the team; the programmers among themselves, but also I as a tester together with a programmer.

Coding Dojo

As one of my colleagues put it: "You're all over the place, right?" Well, at least I try to get my hands on as much knowledge as I possibly could. Last week I finally took the chance to attend a coding dojo for the very first time. I always shied away from this kind of experience, considering my programming skills still being on beginner level. However, one of my resolutions is to get out of my comfort zone more often to give myself more learning opportunities. So I contacted the meetup organizers, asked if they would have a beginner and was welcomed to join.

At first I felt a bit strange among all those developers, but quickly learned I was not the only one without strong programming skills. We split up in groups of four people. The organizers explained the rules and approach. We were supposed to do strong-style pairing, taking turns every 5 minutes. The navigator should give the directions of what to do to the driver at the keyboard, with the other two people listening and preparing for their turn. We were instructed to write our tests first and to only switch when tests are green; so if the timebox was over and the implemented solution caused a test to fail, it had to be reverted.
setup practice session at http://cyber-dojo.org
My group had a rough start. None of us was used to this style of working and we really had to discipline ourselves to keep the driver from coding away without the rest of us following. As a navigator, we faced the challenge how to express our intentions well enough that the driver knew what to do. For example, not all of us were familiar with the chosen programming language and IDE. It also required us to structure our thoughts first to provide clear directions. Another thing was team dynamics. One of our group resisted to take over the keyboard at first, getting upset with the format as he had come to the dojo with quite different expectations in mind. We could convince him to give it a try and managed to find a way to collaborate. But this incident taught us how important it is to have buy-in from the whole group.

Everybody was really patient with each other. After the first struggles, we quickly found a kind of routine and were able to solve all given katas. It was a fun experience and we could share and learn a lot during the whole exercise. As we have been a group instead of just a pair, I realized that this actually had been my very first mobbing experience. I loved it and I'm eager to try this with my own product team.

FlixTech Hackrday

My company declared every first Friday of the month as hackrday. Everyone can bring up ideas, pitch them to have others join, implement them and then demonstrate the results at the end of the day.

Last hackrday I was a bit upset that some of my teammates did not join. This time I was even happier that one of those not only joined but pitched his own idea! He came across Gource, a tool enabling you to visualize the history of your git repository. A great thing to show everyone what we do all day! To take it further and learn about stuff we're normally not getting our hands on, we decided to use an Amazon Echo device to trigger the visualization by providing the parameters via voice input.

Beginning of the day, we started with only three people on the team. We first discussed the planned architecture and split the work into three independent areas to work on separately, with each one triggering the next one. We wanted to get a very minimal product done as soon as possible to be able to get early feedback. I volunteered to investigate how the voice input can be configured and how to define parametrized "utterances". Meanwhile a colleague from Berlin announced to join us, so I spontaneously paired up with him remotely. The next programmer managed to jump in as well and paired up with another one working on an AWS lambda function to take the voice input parameters and send the corresponding messages to Amazon SQS. As the voice input part was ready to go quite soon, the Berlin colleague and I teamed up with the other two to get both parts integrated. Two pairs together made four. Having finalized the integration, we joined our fifth colleague working on the crawler application polling on SQS and triggering the visualization according to the provided parameters. And suddenly we were all working on the same topic at the same time. Like an emerged informal mob. Testing, fixing found issues right away, testing again, and doing anything else together.

And guess what: We had so much fun learning on our way, testing our implementation, and building a first minimal solution to demonstrate the endless possibilities when talking to Alexa. Together.

Any Conclusions?

Product development is all about the people. Pair often to share knowledge and bake quality in. Give strong-style mobbing a try and find your ways and routines. And go with the flow if you find yourself pairing up with more and more others until you happen to work together as the whole team. Many good things emerge of close real-time collaboration.