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.


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.


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.


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.


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!


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.
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
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.

Wednesday, February 22, 2017

Stop Starting, Start Finishing

In a previous post I told the story of how we reduced our bottlenecks when I was working on two teams last year, and how we achieved to deliver the highest priority items first to our users. How? Both teams agreed to "stop starting, start finishing". To not pull any new story before you could not contribute to in progress stories anymore.

This lean approach worked so well! Unfortunately only until I handed over my second team to another tester. As soon as I returned full-time to my original product, the whole team fell back into old habits, starting work on new tickets while other tickets of higher priority were still in progress. At one point we even had a totally underestimated story which turned out to be an epic of its own; we dragged it from sprint to sprint and heavily struggled to finish it. Not that the team members did not want to support, but support was only provided on demand. With "on demand" meaning that you had to actively ask for it.

Beginning of this year, we faced long feedback cycles again. Too long for our liking. New features waited for input from our Product Owner. Code waited to be reviewed. Topics to test piled up. The situation wasn't too bad, but we felt things could be much faster and we generally should avoid to have half-finished tickets lying around, not providing value to anybody. So what caused this situation again? Sometimes the long waiting times were due to the fact that many of us are also involved in company-wide topics of our FlixTech organization, for instance to support our new chapter structure or recruiting new team members. At other times people just grabbed new topics to work on; not having bad intentions, but just being eager to work on something new.

In our sprint retrospective two weeks ago, we brainstormed ways to shorten our feedback cycle again. And came up with the same well-known approach which had already worked so well for us last year: Stop starting, start finishing. Whenever you finish something and have free capacity, ask the whole team if you can support someone else with their current work. Only if you really cannot support anybody, pull a new ticket. And now actually adhere to it!

The past sprint proved once more that this whole-team approach is highly valuable. The sprint went so smoothly, tickets never waited long for feedback and could be delivered to our users as soon as possible. We completed all of our highest priority topics and even many more smaller items on top. Team collaboration felt great and everybody was really supportive. It just worked; even though I could not cover testing for a whole week due to a lot of other important topics like recruiting interviews and the two workshop days with our users (it almost felt like I've been on vacation). My programmer teammates took over testing thoroughly, asking me for advice whenever needed, but proving they already learned a lot about testing. Simply awesome. So proud.

Maybe it's too soon to be proud, as we only adhered to this approach (again) for one sprint. What makes me think that this time is different is the following: No one waited for someone else asking for support. Everybody actively asked if they could support anybody and readily provided that support until the related ticket had been finished. We all agreed that the sprint went really well and we want to stick with this approach. I'm full of hope.

Tuesday, February 14, 2017

Meeting Our Users for the First Time

My team is developing an internal custom product for our company. This means, we only have expert users and we know exactly who they are. Well, you should think that at least. Truth is: We don't know them well enough. And although we're all working for the same company, we have never met.

The same applies the other way round: The users of our product don't know who we are, who is actually implementing this new feature or causing that issue they just found. Well, our user base grew a lot. And our development team evolved a lot as well during the last two years, with new team members joining, and others moving to different products or even leaving the company. And now we only have one person in the team left who had met our users once; a longtime ago.

To start growing closer with our users again, we agreed on the following two initiatives:
  1. We want to have our power users and stakeholders again in our sprint reviews to get their instant feedback. Yes, we know it should always be that way - but truth be told, we had separate "team reviews" and "stakeholder reviews" during the last 1.5 years. Our product owner did a great job communicating user feedback to us, but something was missing. Having direct feedback right after each sprint is simply awesome for both sides.
  2. We agreed to have pairs of developers go to Berlin and visit our users for two days, round robin style. So every developer has a chance to meet them, and they have a chance to meet each developer on the team.
Last week Thursday and Friday it was time for our very first visit! One of my teammates and I took the first round. We were excited to get to know the persons behind "the users", their everyday challenges and how our product might (or might not) support them to solve those.

Although our visit was quite exhausting considering the trip and all the pieces of new information, it was worth every minute. Our product owner did an awesome job preparing our stay and striving for maximum outcome for both us and our users.
  • Big picture presentation. Our visit started off with two power users presenting what their job is about, what their work looks like throughout the year, the challenges they face, and which tools they currently use. It was a great roundhouse kick to show us the big picture, have first questions answered, and get us started in understanding what they actually need.
  • Sitting with the users. Throughout the two days we used our multiple opportunities to sit next to our users while they were actually trying to solve a task at hand; some with our product, some additionally using other products, some not being able to use our product due to certain constraints. This learning time was invaluable for both of us. We directly saw which problems they faced. We saw which of our product features they used to solve it. We saw which of those features they knew about, which of them not at all, where they stumbled, what they liked, what they cried for.
  • Power user meetup. Our product owner invites the power users every other week. This time we could join them and listen to the presentation of newly released features, to questions and answers regarding future implementations, the presentation of a user survey's results. Besides the big epics we're currently working on, the power users also have the chance to vote on their "user favorite" for our next sprint; a rather small but dear feature which would make their lives easier and which fits in between the stories for the big epics. This way they can not only help guide development by their feedback, but also directly influence prioritization in a small scope.
  • Story mapping workshop. To close our two days' visit, our product owner hosted a story mapping workshop with a few users and us. I read the book "User Story Mapping" by Jeff Patton some time ago but never had the chance to attend one of those workshops, so I was really looking forward to it. And it was great! As proposed in the book, we first completed the simple exercise to map what you did this morning after waking up until you left your apartment. It really conveyed the method pretty well! Then we tried to map a real-life user scenario. And my group stumbled. What was easy during the exercise where we shared the same language, proved as difficult when it came to implicit domain knowledge. When the users told the story using a lot of domain language terms, I had my troubles to translate their meaning to my own world of thought. So I asked a lot of those "dummy" questions until we finally were able to map the required actions in a way that I understood them as well. This revealed a lot of implicit knowledge on both sides and helped us to a better understanding of what is actually needed to solve the scenario.

What about our lessons learned?
  • The well planned schedule worked out really well; it was a lot of new information but not too much, enabling us to learn a lot.
  • Now we know many of our users face-to-face - and they know who's behind that product they use every day. I know from experience that this will make future collaboration so much easier.
  • We learned that we are actually working on the most important topics for those users - how great to hear! And that they loved the things we just released. Simply awesome!
  • The two days in the life of our users provided great insight in how we could develop our product further to support their challenges even better.
  • We shared a lot of implicit knowledge; not only the users with us, but also the other way round. For instance that our team does not consist of the 15 developers they thought of, and what technical debt is all about.
In the end, we shortened the feedback cycles with our users. Both my teammate and I are pretty curious what our other colleagues will tell when they return from their visit. And we're already looking forward to our next turn! :)

Thursday, February 9, 2017

It's Hacking Time!

Last week FlixBus hosted the first hackrday for the whole FlixTech organization. Although learning on the job and during working hours is appreciated and encouraged in our company, our teams used their so called "innovation time" quite differently. Some attending online courses, some reading blog posts, some learning new tools, some implementing a new feature they thought of. Many of them on their own. And many more just skipping the time in favor of getting things done. You know, the "real work".

So it was time to start an initiative to:
  1. Actively and transparently value learning.
  2. Give a dedicated environment and the explicit permission to invest time for learning.
  3. Collaborate across teams and locations to get everybody closer.
  4. Spark innovative new product ideas or try new development approaches.
  5. Have fun together and celebrate us as a company!
The idea: Every first Friday of the month is now officially hackrday! The motto of our first one: "Build something fun connected to FlixBus". Follow me on my journey of our very first hackrday - when none of us really knew what was going to happen.
hackrday preparation

In the Morning

Looking forward to our first hackrday for days, some of my team members came up with a great idea what to build and I was eager to join. But when I came to the office that Friday, I learned that exactly those team members were not able to join the hackrday due to different reasons. That hit me quite unexpectedly and my "cannot wait for it" emotions suddenly turned into bad mood. And I started thinking about not joining hackrday as well to show support for my colleagues; but knowing I would regret not to experience the very first hackrday. Instead I convinced myself to at least listen to the other ideas being pitched and see if I like one of those.

As I entered the event location, another team I accompanied last year invited me to sit with them. And instantly improved my mood by providing some sweets - they know me too well! ;)). That team wanted to do what I had been looking forward to do with my own team: have a team project to work on, as a team. They kindly had me on their hackrday team as well. So I stayed; and did not regret it.

The Hacking Phase

When you consider the time required for introduction, pitches and demo sessions, having only one day did not leave much time for actual "hacking". So we had to use the time as efficiently as possible to have a maximum of valuable outcome at the end of the day.
  • We got everybody on the team on board what the idea was about. We actually planned a minimum viable product which could serve as standalone solution or be integrated within some of our current products.
  • We brainstormed what would be minimally required to implement for that product.
  • After having a first common vision, we decided to split up and have sub-teams focus on different areas to develop that very first prototype.
  • Then...
Well, and then one of our agile coaches approached us, asking the very essential question:
"Why do you assume that there is a problem for the solution you want to build?"
Oh yeah. Well said. We were so keen on realizing our idea - we forgot about the basics. So we adapted the plan.
  • The team's product owner and me set out to validate our hypothesis that the problem we thought of actually exists and that our tool would be able to solve it. We identified a set of questions which we assumed our potential users would answer positively; if so, our hypothesis would be validated.
    1. Have you been in the situation that you had to do X?
    2. How did you solve it?
    3. How happy have you been with your solution?
    4. What would you wish for?
    5. Do you know of any tool which would make things easier?
    6. Would you give us your email so we could inform you about a new solution?
    7. Any further remarks?
  • We went through our office, asked several colleagues of several departments those questions - and quickly learned many of them had been in the defined situation but they did not have had a problem at all. They were really happy with their solutions!
Acknowledging defeat, we returned to the rest of the team and told the news. We knew that the number of persons we asked were not sufficiently representative. But it was clear enough that if we thought about a productive solution, we would definitely need to get real data from our actual target group to find out if they really didn't show any interest as well. Well, as this was hackrday and about learning and fun, we decided to continue with our idea anyways.
  • Next up we created some very simple UI sketches on paper, depicting a simple workflow through our envisaged product. Cut them apart. And again set out to get early usability feedback from our targeted users.
    1. We told them a scenario they should solve.
    2. We asked them to think out load.
    3. We gave them the paper landing page.
    4. And observing eagerly how they interacted with the paper product, trying not to give any hints, collecting their feedback.
  • After doing this with only two persons where one heavily stumbled and the other even broke out, we had so much invaluable feedback already that we decided to stop and and re-design our product.
  • So we draw more sketches, adapted things our users stumbled upon, added missing navigation which got them lost, and solved other unexpected issues.
  • And while redrawing, without showing our next versions to any other users, we suddenly started to ask further questions ourselves. Is that feature really needed? If I enter this here, I should see it there... Hm, how to get back? So we instantly minimized our paper product even further.
  • Back to another round of usability testing! And again, our users asked many valid questions and had a bunch of awesome feedback to improve our product.
  • Then the other tester on the team came up with a stroke of a genius: While we were still focusing on paper, we forgot about all those tools for prototype testing and mockups which are out there! She used Marvel's mobile app to take photos of our paper prototype and linked them together to make it come alive and show the workflow. As time flew by we unfortunately could not have another iteration with users giving them this digital prototype. Would have loved to see their faces!
During the whole day we checked in with the team at least every half an hour, sharing our latest insights about the next best minimal solution. The team took them as input to build a very first backend prototype plus some UI parts. Hacking time quickly came to an end and we hurried to prepare a short presentation of our results so far - flying high on an adrenaline rush!
hackrday demo title hackrday demo hypothesis hackrday demo paper prototype hackrday demo mockup hackrday demo implementation

Lessons Learned

When each team demonstrated their prototypes, we found that many of them thought not only about fun stuff but about delivering business value with their ideas. Sharing our team's story how we identified our hypothesis as invalid caused laughter, but also taught some invaluable lessons for product development.
  1. Always test your hypothesis first. (We should have know better; we heard a talk about hypothesis-driven development only some weeks ago...)
  2. Assume your assumptions are wrong!
  3. Cut your product down to the absolut minimum. And then minimize it even further.
  4. Prototype quickly, test quickly, get fast feedback.
But we learned even more from this first hackrday.
  1. Personally I learned to validate my expectations as well. It's not about me or my team; the day was about learning and collaboration across the whole FlixTech organization. Glad I realized that in time.
  2. A low-effort presentation with handwritten slides supported the key messages of our 5min timeboxed demonstration really well. And it was worth shortly practicing it before doing it on stage.
  3. Due to the given time constraints, we felt the pressure to deliver in short time. We learned that we actually don't have as much pressure in our everyday work, even though it might feel like it at times. Despite the short time frame of the hackrday, we kept experimenting and learned so much valuable lessons by doing so. There are simply no excuses to not integrate experiments in our everyday work.
  4. We split our team to focus on different activities; but in the end it would have been worth to try mobbing for all tasks at hand. To not run in the wrong direction and waste time, but to avoid feedback cycles overall.
Oh and we have a lot of new ideas we would love to try. We're already looking forward to our next hackrday!