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? ;-))