Navigating in the wrong level of abstraction

It was a big agile conference in the US, and I participated a session on with a demo of mob programming. Demo meant the facilitator of the session called for volunteers, and of the 5 people that ended up in front, I was one.

The group of 5 was two women and three men. It wasn't my first time mobbing, it wasn't my first time mobbing on the particular exercise and I was looking forward to seeing how the dynamics with this team of random people would turn out.

The exercise we were doing followed a routine of example to English, English to test code, test code to implementation.

I remember that session as awful but I have not talked about how awful it was because I was told back then that I just did not understand it right. So today, I wanted to write about the idea of mild gaslighting when someone is seeking acknowledgement for their feelings you think they should not have felt.

The other woman in the group went before me as both navigator and then driver, and made it very clear to everyone it was her first time programming. Mob programming is great in the sense that this is possible, and in addition to remembering her emphasis on not knowing a thing, I remember the joy she felt and expressed on having contributed on creating something. As a total newbie, the group navigated her on the lowest possible level of abstraction. We'd tell her letter by letter what to write, not using conceptual language at all.

So when the next two in the rotation after her were men, the difference of how people navigated her and how they navigated the men was very obvious.

My discomfort came from being bundled together with the other woman. As far as I can see, I did none of the "help me, I know nothing" mannerisms. I sat with the crowd, navigated with the crowd, knew what I was doing. And yet the moment I sat on the driver seat, I was navigated on keystrokes, no concepts. I felt humiliated and paralyzed into a role I hated. The mob navigated me on keystrokes, and I was unable to correct them. I was holding myself together not to ruin things for everyone else.

As soon as the session was over, I expressed my emotions to the facilitator who told me it was all my fault. I would have needed to assert myself by saying "just tell me what the thing is you want me do", I was supposed to not feel like I was just treated as not a programmer but a woman trying programming with a mob, bundled together based on my gender with the other "representative". I missed out on the joy she was feeling, so we were clearly individuals regardless of the bundling.

My lesson of this is that to not offend people in ways they remember years later, you may want to always err on the side of navigating on an abstraction level that is too high rather than too low. Tell the intent and if you see no movement, then tell location and details. If you jump directly to the details, there's a chance you're explaining things your driver won't need, introducing inefficiency as well as making the other feel like they've been weighed on their looks and found not worthy.

It would have felt a lot better if the facilitator would have at least acknowledged my feelings. But as usual, it was a problem with me: me feelings were wrong, as a result of my (lack of) actions.

I rarely volunteered in mobs after this unless they would run a long time, unless I was the only woman or unless the other woman was even more of a programmer in her manners than I was.

Pairing and Mobbing are not the only ways to collaborate

A friend I enjoy connecting with on testing themes sent me a message today. They expressed they had enjoyed my pair testing article on medium, and had an idea they wanted to contribute on type of testing I had not addressed.

This was a form of collaboration where two people (a pair, you may say) worked on two computers, side-by-side on the same task. The two might be intertwined in the activity so that one looks one end, the other another end. And it is very much collaborative. They suggested this would be a model of pairing with two drivers, both with their hands on the keyboard - a separate one though.

In my article, I introduced the traditional style pair testing, where often the navigator would be making notes, deciphering what was going on with the driver who had control. Nothing says the second person couldn't be taking those notes on a computer, but what typically happens is that the notes, in comparison to strong-style pair testing, are of a private nature and don't always reflect what was going on in a manner that is shared between the pair.

Similarly, here with two computers and testing side by side, we can figure out many ways to still work in a very collaborative manner.

I find myself often testing in ways where there is two or more testers in the same space, at the same time, sharing a task while we still are not mobbing or pairing. It's more about sharing energy, and enthusiasm, giving hints of things others can pick up and run with, and continuously coming back together to understand where we are.

I tested that way today with a developer, over a teams chat. We would be calling out our progress and observations, pondering on things that did not work out quite as we thought. The chat version works when people are active in sharing. I absolutely adore this dev for the way he is transforming the team now from his position of seniority, and driving collaboration without pairing forward.

In the past, some of my most fun days have been when we work side by side with other people, testers and developers, growing ideas and solving problems. While formal pairing and mobbing are great and give a structure, the other ways of working together also beat the "alone in a corner" any day. Some tests require many computers, like the test at Finnish Parliament where they had to bring in 200 people serving with the Finnish military forces to control 200 devices, for one test to be completed.

No matter what, we should be learning and contributing. Work is so much fun, and it makes no sense to dumb or numb it down. 

Attribution for Work Performed in a Mob

In 2017, I delivered a keynote at StarWest, talking about Making Teams Awesome. One of the main themes I talked about back then was a theme I had put a lot of effort into thinking: attribution. There's many things I have problems with around this:

• Women's contributions get disproportionately dismissed - not just ideas, but also the work they do - and attributed in memories to other people. 
• Group work is different from individual work, and my needs of attribution can get in the way. 
• Ideas are not worth more than execution, especially in software development
• Attribution should not be a blocker for communication of ideas, a new form of apology language required disproportionately from women. 

In June, I used a phrase "invitation to explore" in a conference talk as one of *my points*. In speaking, I mentioned a colleague I respect as someone who uses that phrase. Meanwhile, he took offense on me using those words without writing his name down. My conclusion: fuck the language police, I will never again even mention him with this phrase. The words are free and I live that idea on a daily basis.

Caring for Credit

We all care for credit, I would claim. All of us. And some of us, like myself, care deeply for the credit of others too. Yet, credit is a messy and complicated theme.

We all know the name Albert Einstein. The fellow who pretty much created the foundation for modern physics. The guy whose picture posted on a slide everyone recognizes, even though the pictures are from very early days of photography. The man has been dead for a while, and yet we know him. Probably for generations to come.

But we don't know who is Mileva Marić Einstein. We can deduce a lot from the last name, and recognize that there is a relationship there. She was a physicist who, due to her gender, had trouble getting the education in physics but went through it anyway, and contributed significantly to Albert Einstein's groundbreaking science. History forgot her, partially for the rules of society that required removing her name from scientific articles she worked on intended for publication.

Then again, we know Marie Curie. Another brilliant scientist of that time. Someone who had a partner who refused to let her credit stay out of the limelight. So credit is something to pay attention to. It defines history. It matters.

It matters to people so much that for a long time, we had to wonder why there are no baby dinosaurs? They were misidentified as other species for reasons of credit. 5/12 dinosaur species identified were not new discoveries, but juvenile versions of ones found earlier.

Credit in a mob

With personal history of protecting my credit heavily as a necessary self-preservation mechanism, this was a difficult one for me when I started working with mobs. I would see my contribution, and see it be forgotten in a retro less than an hour later! With the feeling of safety, I could bring out my own contributions in the retros, have them discussed and get back to recognized. I could write about them in my blog while everyone else dismissed them. But in many relevant ways, I had to learn that

The Best Ideas Win When You Care about the Work over the Credit. 

I needed to let go. But so did everyone else.

When a group of people works together, it becomes difficult to identify what was the contribution of each of the members. Like with baking a cake, you cannot identify if it is the flour, the sugar, the eggs or the vanilla sugar that makes the recipe just right and perfect. People inspire one another, build on one another and create together things they would not create alone.

Also, mobs had visitors. It was a living organism where people would come and go. It wasn't as simple as that. There would be credit for being there when it all started. There would be credit of visiting, short- or long-term. How do we credit things that are done collaboratively?

Visiting isn't infecting other people's contributions as "they are now all someone else's". We need to care and be fair.

The Mob Programming Guidebook

In 2016, I acquired a book name from LeanPub: Mob Programming Guidebook. I set up a GitHub project to write it. The first rough version of it was scheduled to be available for a conference session I was invited to do.

For all of this, I paired with Llewellyn Falco. We wrote in strong-style. We argued over words, and ideas. Our collaboration worked while it worked, and then the book was in hibernation for a while, because we couldn't work together. We couldn't work together to a point where it became evident we would never again work together.

With a book 30% written we needed to go our separate ways. In the split, both of us get to keep the results of the collaboration but neither of us can block the other from taking it forward. Claiming equal authorship for work we are not doing equally makes no sense. So I added 25 % more text to match my vision to a still unfinished book, initiated all the work I had been postponing on making it a full book it was intended to be and moved Llewellyn away from second author to a contributor to reflect his role to the book. The book is still not done. There's significant work ahead of me, including refactoring a lot of the paired text to vision I aspire for.

Books can have many authors even if one wrote most of the text. But that would mean that I would believe that the book wouldn't exist without their support and contributions, and looking into how I feel I honestly cannot say that. The book wouldn't exist without meeting Woody Zuill. The book wouldn't exist without me. But the book would exist without Llewellyn Falco, and does exist without him.

His role to the Mob Programming Guidebook is only a little more than his role to all Mob Programming books. Mob Programming grew out of his ideas around strong-style pairing. He has the choice of writing the full book that describes his ideas but I suspect he will not.

I want to acknowledge that for the 30% book, we inspired one another to create what is there. The foundation is co-created. But the book I work on forward, alone, is not the foundation. It is more. It's founded on all the experiences of leading and participating mob programming sessions, and my discussions with people who care for that activity just as much as I do.

The book is more than the text - because he has the text too should he choose to fork it as suggested. It's the site. It's the promotion.  And it is the text that is still to be written by its authors. The text that I am writing on top of the text I had been writing. I acknowledge the collaboration, but refuse to minimize my role to the past text, leaving a project I started in an unfinished state.

So when Llewellyn calls for help with a tweet

My co-author @maaretp has removed me from our book.https://t.co/AX4aC6pYPw
Has anyone gone through this before? Suggested actions? Would appreciate help

— Llewellyn Falco (@LlewellynFalco) September 13, 2018

he is missing a big chunk of the picture. He is missing the fact that he is asking to be an equal author of a book that isn't yet written because he was once part of collaboration of writing some parts of early versions. He is asking his visit would infect the rest of the contributions. And that is not how attribution in a mob should work.

When someone sympathetic to Llewellyn then responds:

I frequently recommend this book. Sometimes developers bring up concerns around attribution for work performed in the mob.

Through unilateral action, you have made this discussion more difficult.

Please explore other options.

— Mike Coon (@mikeonitstuff) September 13, 2018

I disagree. I did not make this discussion more difficult. I made it clearer. Visitors don't get to claim rights to future work. Attribution of realistic contribution is necessary. Forking the text we wrote together is acceptable. Asking others in the mob to start over a fresh because you visited isn't fair.

My sense of justice says I do the right thing.

The book has 1008 readers, out of which 281 have paid for it and 1 has claimed their money back (book was not finished). We have received $1,240.24 in royalties. Since Aug 18th, I have received all royalties because that was when the book forked. The money does not come from writing the book but from promoting the book. From this "huge" financial gain, 80 % has gone to Llewellyn before to first pay back an investment we chose to make on printing early versions of the book.

I have explored my options. I chose not to remove him completely. I mention him, as it is fair. But he is not a second author of the book. I sympathize to his need to be, but he isn't.

Attribution for work performed in a mob is hard, because we want to be remembered and appreciated. I appreciate Llewellyn's contributions while sticking to the fact that my contributions are far greater and handing also my future contributions to him just because he wants to be an author is not a fair thing to ask.

Authorship is not born when you start a project. Ideas without implementation are not where attribution should be born. Authorship is born when you work on a project and finish it. If you want to say that you created X, be more than a visitor in that mob. Make space to stick around to completion. And even when you don't, they'll appreciate your visit. Because the end result is better through that visiting collaboration.

Looking forward to other visitors in finishing the book.

Mob Testing is Different to a Bug Bash

When I introduce Mob Testing (all of us testing together on one computer), I find myself in a place where people who are not doing mob testing say they are. Often in asking questions, what they are doing is some form of working together in a crowd. 

A group testing together on a number of computers is usually called a bug bash. What characterizes a bug bash though is that not everyone in the group is working on the same thing except on the very high level of "we are all doing testing of a feature". The actual intent is not shared, the scenario is not shared.

Another form of crowd that people feel like identifying to be the same as mobbing is anything with a group and a single computer.

There's the version where one works and the others watch without really contributing other things than pressure. 

There's the version where one works and others more like make a point of not being in any way necessary - the "great, I get paid to not do anything" version of it. 

And there's the version where 200 people drive and one navigates, which out of these cases is closest to a mob but not one. This picture is an actual image of final testing of the Finnish Parliament in-session system. The testing took place so that the leader in the lectern outside the picture would call out a step of what everyone was doing, and each of the places had someone to do that on command. For this to be mobbing, there would need to be more minds on the hardest problem of what to test, over the extension of keyboard.

So when you think whether your group activity is mob testing / programming or not, here's my rules of thumb:

• Are you all working on a shared intent, so that when you rotate and switch roles, anyone in the group is in the same context so that the same work can continue? (yes and -rule)
• If you have multiple devices you need multiple hands on (multi-driving), is the overall group hands off the devices still in control of the work that happens on those devices? For an idea to the computer, it must go through someone else's hands. 
• Is everyone in the group either learning or contributing through active participation? 

The connection mobbing creates tends to be tighter than with other group activities. 

Power dynamics in pairs and mobs

Four years ago, I wasn't pairing or mobbing. Frankly, I found both of those intimidating. Instead of expressing that I was scared, I talked about needing alone time, being introverted and not being able to think when others are too close.

I came back to think about all this today for a great thread of power dynamics in pair programming and TDD from Sarah Mei.

More on why agile/XP so often fails heterogenous teams (started here: https://t.co/DajwJ71IwP) pic.twitter.com/rgnIXK0M66

— Sarah Mei (@sarahmei) April 30, 2018

If you ever get a chance of watching a mixed gender group of teenagers, you see some of the gender-based power dynamics at their worst. Teaching programming to teenagers in a mixed group results in the girls giggling, downplaying their abilities and focusing on letting the boys shine. It's easy to think of this as characteristic of the girls up to the point you teach the same girls in a separated gender group. The girls are still bubbly, but now concentrating and doing their best. And their best is often much better than the best in mixed gender groups in general.

The problem isn't men's fault, it's structural. Years of belief systems on how men and women interact. And for women in IT, it often takes years (or a lifetime) to overcome the structures that keep them listening rather than contributing. That keeps them apologizing. That causes them to feel they are not good enough.

We see the same dynamic in conferences. We have loads of speakers who are identified as men. We have all male lineups. And when we talk about including women, we hear that we cannot lower the bar. Yet for conferences doing good work on inclusion and blind review, the shortlists end up being very equal or women dominated. There may be less of women, but quality they produce seem to not lower the bar, quite the opposite. But to get considered, you have to listen to some people's hostility in assuming that you're not up to the bar.

Four years ago, I started first mob programming and then pair programming (and testing). I still think of mobbing as the gateway to pairing in situations where the power dynamics are hard or next to impossible like in my team. Imagine having to pair with a man who tells you "women only write comments in code". The pain of having to sit with that person, alone, is enough for many women to walk out. Their attitude shows in the mob too, but a group of people can help moderate, correct or even punish in ways that an individual on the lower end of the dynamic cannot.

I also remember well the first time I paired with a friend. This is a story we've told many times in our shared talks, yet it was a story that I would have never shared unless we ended up working on a share talk. I came back to think of this time for one of the Sarah Mei's subtweets:

Pairing has nothing to say about how to structure an interaction to avoid taking unfair advantage of power dynamics. One of its basic assumptions is that everyone feels empowered to contribute.

When this is true, pairing is amazing. When it's not, it's a nightmare.

— Sarah Mei (@sarahmei) April 30, 2018

We had agreed to pair on exploratory testing a new functionality added to the software I was working on.  So we sat down together, I guided him first to get to the functionality just to see it was there. The functionality included a new dialog, and as it popped open, my first words were "I wonder what size it is...". It wasn't intended a question, but very much taken as one. What I meant is that we have an agreement on the resolution where things still must be usable on the screen without scrolling. We were clearly on a higher resolution, and still the dialog was big and clunky. But before I got in another word, the friend picked up on the cue and started showing me tools that enable me to measure the dialog size in centimeters, pixels you name it.

I didn't even understand right there and then that I was uncomfortable. That I felt overridden. That none of the stuff I was trying to show - my work in exploratory testing - got done. Moreover, I'm sure I acted like one of those teenagers, just telling myself that my contributions weren't expected for real. I tried enjoying the results we ended up with, not miss the results that were hijacked from me by a power dynamic.

After this experience unfolded in prepping the talk, we have had great pairing sessions and learned to explore in a pair and mob a lot better. He actively worked against the power dynamic, paying attention to listening instead of talking over me, thinking their way is always correct.

Thanks to Sarah Mei's tweets, I remembered again how far I've come. And how far there is still to go now that my whole team is expressing openness to pairing - finally after 1.5 years.

1 reply28 retweets107 likes

Grow your Wizard before you need them

Making teams awesome is something I care deeply for, so it is  no wonder that discussions I have with people are often on problems around that. Yesterday again I suggested pairing/mobbing at work to receive cold stares and unspoken words I heard in the last place I worked: "You are here to ruin the life of an introvert developer". I won't force this on people,  but they can't force me not to think about it or care about it.

As I talked about the reactions, and was pointed out a story he has been talking about many times before. And with "just the right slot" in my calendar, I go and write about it. Someone else will probably make an awesome video when they get to it.

Some of us have some sort of history with computer games. Mine is that I was an absolute MUD (multi-user dungeon) addict back in the days, and I still irregularly start up Nethack just for nostalgic reasons. In many of these fantasy game types, we fight in teams. And we have characters of different types. If you play something that is strong in the beginning, you survive early on more easily. The wizards on low levels are particularly weak, and in team settings we often come to places where we need to actively, as a team, grow our wizard. Because when wizard grows to its high level potential leveling up with others support, that's an awesome character to have in your team.

A lot of times we forget the same rule goes around growing people in our teams. The tester who does not program and does not learn to program because you don't pair and mob could be your wizard. At least the results of being invited to "inner circle" fixing problems by identifying them as they are being made feels magical.

Just like in the role plays, you need to bring the wizard fully into the battle, and let them gain the XP, you need to bring all your team members into the work, and find better ways for them to gain experience and learn.

Pairing and mobbing isn't for you. It is for your team.

Playing with rotation time in a mob

A common thing to happen in a retrospective after Mob Testing is that someone points out that they feel they need more time as designated navigator / driver, "I need more time to finish my thought". Today, it happened again.

I facilitated the group on a 3-minute timer. I emphasized the idea that this is not about taking turns on each one of us executing our individual test ideas, but it's about the group working on a shared task, meaning same ideas, bringing the best of each of us into the work we're doing.

On two retrospectives with a 3-minute timer, the feedback was the same: make the time longer. So I did what I always do in these cases: I made the time shorter, and we moved to 2-minute rotation.

The dynamic changed. People finally accepted it wasn't about finishing their individual task, but to finish the group's shared task.

A lot of times when people feel they need more time, they are saying they have their own individual idea that they don't share with others. Longer time allows this. Shorter time forces the illusion of that being useful out of the group. 

A Search for Clear Assignments

I spent a wonderful day Mob Testing with a bright group of people in Portugal today. They left me thinking deeply on two things:

1. Importance of working in one's native language - the dynamic of seeing them work in English vs. local language was immense. 
2. Need for clear plans

I wanted to talk a bit about the latter.

I've been an exploratory tester for a long time. I've worked with projects with very detailed specifications, with the end result of having a system that worked as specified 100% but filled 0% of the real use cases the system was intended for. I've worked with projects that don't bother with specifications at all - all is based on discussions around whiteboards. And I've worked with projects where all specifications are executable, with the experience that to make it possible we often like to minimize the problem we're solving to something we can execute around. 

The first exercise we do on my mob testing course involves an application that has very little documentation. And the little documentation it has, most people don't realize to go search for. The three sessions we did gave an interesting comparison.

First session was freeform exploration, and the group was (as usual) all over the place. They would click a bit here, move to somewhere completely different, check a few things there and make pretty much no notes other than bugs I strongly guide them to write down. The group reported as experience that they were "missing a plan".

Second session was constrained exploration by focusing on a particular area of functionality. The group was more focused, had hard time naming functionalities they saw and finishing testing of things they saw. Again the group reported as experience that they were "missing a plan" even if the box kept them more cohesive in the work they shared. 

The third session was tailored specifically for this group, and I had not done that before. I allowed the group 30 minutes to generate a plan. They selected a feature with a web page claim after discussing what the unit of planning should be (use cases? user interface elements? claims on the web page?). Before spending any additional time hands on with the application on top of the two sessions earlier that had barely scratched the surface of the feature, they cleared up their plan. 

The interesting outcome was that

• They found less bugs
• They were happier working against a recreated (low quality) checklist
• They missed more bugs they saw while testing and dismissed them as irrelevant. 
• I saw some of the symptoms they saw as symptoms of something really significantly broken in the application, and having seen them test, I now know how I could isolate it. I suspect there are only a few people in that group who would know what needs more focus on. 

I take this as a (trained) wish for clear assignments, clear answers and generally a world where we would have our tasks clear. I find myself thinking it is not the testing that I know, and that it is the testing a lot of my automator colleagues know. And that in getting out of that need of someone else placing us the "plan" and being active about making and changing our own plans as we learn is the core to good results. 

We all come from different experiences. My experiences suggest that my active role as a software learner is crucial. Having documentation and plans is good, but having the mindset of expanding those for relevant feedback is better. 

Mob Programming on a Robot Framework Test

A year ago as I joined my current place of work, I eagerly volunteered to share on Mob Programming in a session. As I shared, I told people across team lines that I would love to do more of this thing here. It took nearly a year for my call to action to sink in.

A few weeks back, a team lead from a completely different business line and product than I work on pinged me on our messaging system. They had heard that I did this thing called Mob Programming, and someone in the team was convinced enough that they should try it, so what then should be the practical steps? They knew they wanted to mob on test automation, and expressed that a challenge they were facing was that there was one who pretty much did all the stuff for that, and sharing the work in team was not as straightforward as one might wish for.  Talking with three members of the team including the team lead and whoever had drawn me in, we agreed on a time box of two hours. For setup, one would bring in the test setup (which was a little more than a computer as we were testing a Router Box) and ideas of some tests we could be adding.

It took a little convincing (not hard though) to get the original three people to trust me with the idea of not having first a session of teaching and introducing the test automation setup, and that we would just dive in. And even if we agreed on that in advance, the temptation of explaining bits that were not in the immediate focus of what the task drove us towards was too much to resist. 

The invitation for the team of 7 included “test automation workshop”, without a mention of mechanism we would be using on this. And as we got to work on adding test, I asked to figure out who knew the least and made them sit in front of the keyboard first, just saying the rule of “no thinking on the keyboard”. I also told them we’d be rotating on 3 minutes, so they would all get their chance on the keyboard and off, except for the one automation expert. Their rule was to refrain from navigating unless others did not know (count to three before you speak). 

Looking at the group work for 1,5 hours was a delight. I kept track of rotation, and stepped into facilitating only if the discussing got out of hand and selecting between options was too hard. I noticed myself unable to stop some of the lecture-like discussions where someone felt the need of explaining, but the balance of doing and talking was still good. People were engaged. And it was clear to an external person that the team had strong skills and knowledge that was not shared, and in the mob format insights and proposals of what was “definition of done” for the test case got everyone’s contributions.

I learned a bit more on Robot Framework (and I’m still not a fan of introducing a Robot language on top of Python when working with one still would seem a route of less pain). I learned of use of Emacs (that I had somewhat forgotten) and could still live without. I learned on different emphasis people had on naming and documentation on tests. I learned on their ideas of grouping tests into suites and tagging them. I learned of thinking in terms of separating tests when the Do is different, not when Verify needs a few checks for completeness. I learned to Google Robot Framework Library references. And I learned that this team, just like many other teams at the company, is amazing. 
Asking around in retro, here’s what I got from the team: This was engaging, entertaining. We expected to cover more. The result of what we did was different than the first idea of what the test would be, and the different means better in this case. 

My main takeaway was to do this with my team on our automation. If I booked a session, they would show up. 

Is Mob Programming just Strong-style Randori?

Back in the days before Mob Programming was a thing, there was a way of deliberate practice referred to as Randori. The idea there was pretty much similar to what the mechanics of mobbing are. There would be a pair out of a group working at a time on a problem, and then you'd rotate.

My first Randori experience was a long time before I ever heard someone was working in this "mob programming" style, and on a shallow level, the difference I saw from my first introductions to mob programming was the use of strong style navigation. So the question emerged: is mob programming really just a strong-style Randori?

I'm blogging since being reminded:

Pool is not just a bigger bath tub.

Surely, pool is a container with water in it. So is a bath tub. But the things you can do with a pool are significantly different from the things you can do with a bath tub.

Examples popped out: there's such a thing as a pool guard, but it would make no sense to have a tub guard. Pool parties are a thing, but you might argue that a tub party is a very different thing. The physical exercise aspects of pools are non-existent in tubs, you wouldn't really say you swim in a tub.

While it is a fun word game to make one think, it is a good way of illustrating why mob programming is not just a Strong-style randori. What mob programming as Woody Zuill and his team introduced it brings in is hundreds of hours of learning while continuously collaborating, and with that communication some of the problems we see no ways of making go away just vanishing.

Doing things over long time to grow together make it different. Mob Programming is different.

And the same applies to many of the things where we like to say that this "has been around for ever". Test after and test first are essentially different. The things we can do with continuous delivery are essentially different to just continuous integration.

From avoiding tech debt to having tech assets

The question I always get when talking about mob programming is how could that be a better / more effective way of working than solo work. The query often continues with do you have research results on the effectiveness? 

As someone with a continuous empirical emphasis on my work as a tester, and someone with background in research work at university, I'm well aware that the evidence I care to provide is anecdotal. I have other things to do than research nowadays, and having done that I realize the complexities of it. And while anecdotes are research results, I can work with anecdotes.

One of the themes I like collecting and providing anecdotes on around mobbing is that to me it makes little sense to compare an individual task, but a chain of value delivery. Many times with mobbing, we end up with significantly less duplication of code, as someone in the group acts as the memory to tell that they are using something of that sort somewhere else.

Here's an anecdote I just today added to my collection: "QA person, where were you 9 hours ago when your knowledge would have saved us from all this work?". A team of programmers was mobbing, and wondering how to work on a particular technology. For everyone in the group, it seemed like there was some significant implementation work for somewhat of a scaffolding type of work, and the team set out to do that work. Later, another person became available to join the mob and with the knowledge available to them, eradicated all the work until that point, just having  the information available: an appropriate library for the scaffolding would already be available, and was used on the tests.

I've seen my own team talk around an implementation, starting with one strong idea, and ending up with the best of what the group had to offer. I've watched my team express surprise when days of work get eradicated with knowing the work has already been done elsewhere. I've watched them come to realization that whatever they would have implemented solo, would have been re-implemented to better match the ideas of architectural principles or the best use of common components.

I've also had chances of seeing a mob go through about ten solutions to a detailed technical problem just to find one with least tradeoffs between maintainability, performance and side-effect functionality.

A lot of times the best result - paying back in the long term - does not emerge ever from solo work. And that just makes the comparison of what did it take as effort to generate some value in mob vs. solo all the more difficult. It's not the task, it's not the delivery flow, but it's the delivery+maintenance flow that we need to be comparing.

A Mob Testing Experience

During my 6 months at the new job, I've managed to do Mob Testing a few times. Basically the idea is that whenever I sink into a new feature that needs exploring, I invite others to join me for the exploration for a limited time. I've been fascinated with the the perspectives and observations of the other testers I've had join me, but these always leave me wanting after the Mob Testing experiences I had at my earlier place of work. There not only testers joined (well,  there were no testers other than myself) but we did the tasks together with the whole team, having programmers join in.

There's a big difference on if you're mob testing amongst testers (or quality engineers as we call them) or if you're including your teams developers and ever product owners. And the big difference comes from having people who need to receive the feedback testing is providing sharing the work.

With 6 months approaching, I'm starting to see that my no-so-subtle hints on a regular basis are not taking adapting mob testing / programming further. But it became funny at a point I taught developers from another organization who started off with the practice, and only through their positive reports someone relevant enough to push people to try it took initiative. There's an infamous old saying of no one ever being a prophet on their own land, and that kept creeping up to my thoughts - I became part of furniture, "always been here" surprisingly quickly. And I don't push people to do things they don't opt in to.

But finally last week's Wednesday, while my own personal team did not opt in, the team next door did and invited me to join their experience. With two application developers, two test developers and two all-around test specialists, we took the time to mob for about 5 hours during the day.

The task we were working on was a performance testing task, and the application developers were not in their strong area. We worked on extending an existing piece of code to a specific purpose, and the idea of the task was available to start our session. There were a few particularly interesting dynamics.

When in disagreement, do the less likely one first

About half an hour into our mobbing, we had a disagreement on how we would approach the extending of the code. We just did not disagree what would  be the right thing to do as the next step. The two of us who were familiar with what the goal of what we were doing had one perspective. And another suggested doing things differently, in a way that in the moment felt it made little sense to us.

I realized that were were quickly going into discussion mode, convincing the other of what the right thing was - at a time we really knew the least. The other suggestion might not sound like the best idea, so we played a common rule to beginning mobs: "Do the less likely first, do both". Without continuing the discussion, we just adjusted the next step to be one that the other, in minority, felt strongly enough to voice.

And it turned out to be a good thing to do in a group. As it was done, the work unfolded in a way that did not leave us missing the other option.

Keep rotating

Between hours 2-3, two of the six mob participants needed to step out into another meeting. I was one of these two. For first two hours, we had rotated on a four minute timer and pushed the rule of having a designated navigator. As I came back from the meeting, the rotation had fallen off as the mob had found relevant bugs in performance and had two other people join in as lurkers on the side of the table, monitoring breaking services in more detail. The lurkers did not join the mob, but also the work got split so that the common thread started to hide.

Bringing back rotation brought back the group thread. Yet it was clear that the power dynamic had shifted. The more quiet ones were more quiet and we could use some work on dominating personalities.

But one things I loved to observe on the more quiet ones. They aced listening and it showed up as timely contributions when no one else knew where to head right now.

Oh Style

The group ended up on one computer with one IDE in the morning and another computer with another IDE in the afternoon. Keyboard shortcuts would fly around, and made different IDEs obvious.

On the order of doing things, there was more disagreement than we could experience and go through in one day. Strong opinions of "my way is the best way" would be best resolved doing similar tasks in different ways, and then having a retrospective discussion of the shared experiences.

And observing the group clean up code to be ready to check in was enchanting. It was enlightening to look at group who have "common rules" to not have common rules after all. Mobbing would really help out figuring the code styles over the discussions around pull requests.

Your choice, explorer!

I had five amazing, insightful volunteers for my demo exploratory testing mob at Testbash Philadelphia. Their open reactions made the experience for me even more worthwhile. In particular I remember when one exclaimed: "Interesting! Oo, I don't like that.", when another said that "I wouldn't write anything down before I know more about the application" and a third confessed that the experience was both fun and exhausting but the chosen style of exploring wouldn't be their chosen style of exploring. Fourth mentioned being unsure of rules and how strictly should those be followed, and the fifth was missing a specification to begin with. The volunteers individual approaches got many participants to approach me later, wondering about the options. What would be the right way to go about exploring the application?

I find that one of the powers of testing in a mob is how it reveals our personal differences and preferences. My volunteers were all from different organizations and locations, with different built-in personal styles. Being different is a strength, helping bring in different perspectives. But to work, on a longer term in particular, in a mob, they would need to build common mechanisms.

They could experiment with different approaches. Let's agree not to write *anything* down for an hour. Let's agree to write only bugs down. Let's agree to only focus on listing functionalities. Let's not touch the application but go look for online documentation of what to expect. All valid approaches.

Working together would create a mix of recipes the group uses to bring in things each feels is relevant, giving chances for the ways of others. They could agree to spend an hour in being mainly navigated within the intent of one, perhaps starting from the one least strongly formed. Instead of choosing one, try all styles. Let the unlikely show its power first.

Within the half an hour of demo, we did not go too deep into letting intent emerge from the group, but I gave the box to play in. We saw it was hard to stay in the box, that problems all around the application made it even harder.

So what would be the right way to start? My one rule is variance. Do it different every time if that is possible to maximize your chances of serendipity. What goes first determines what can come second, and the varied order of things helps you think in different dimensions. It's not just one way, but whatever you do first already changes the state of your knowledge.

Your choice, explorer. Just realize the choice exists. 

Ruining the life of the introvert

I listened to an insightful talk by Elizabeth Zagroba on Succeeding as an Introvert yesterday, and throughout the talk I kept reflecting my own thoughts. I thought about how awful the idea of Mob Testing I introduced first thing in the morning must be for someone who identifies strongly as an introvert. I thought about how I've been regularly labeled as extrovert, yet how I recognized most of the introverted aspects she was describing in her talks as things I do - like thinking critically once more after the meeting is done. I thought about how with those definitions, almost everyone in Finland would be an introvert. And I laughed at my cultural discomfort earlier that morning when the Americans decided to talk to me in the elevator.

I remembered back to my old job, citing one of the developers who wasn't particularly happy with me bringing agile ways of working into the place: "You are here to ruin the life of introvert developers". I hoped I wasn't then, and I still hope so.

Mobbing may seem like a nightmare for the introverted. Sitting in a room with people the whole day, and forcing the task to happen on one computer through speaking up about what should happen on that computer. It sounds like it's hard to disengage, as there's a continuous rotation of each mob member being on the keyboard. I had no time to address this in my talk, so I thought about writing on it.

When reading an article about how Google builds great teams, I had written down a quote:

Good teams are not teams where introverts are left by themselves but ones where they feel safe and can open up. 

We all, introverts and extroverts alike, want our contributions to matter. A great team is one where everyone pitches in, in ways they find comfortable. Leaving introverts entirely alone would't work, and having the special traits of introverts available is an asset.

A lot of times, introverts struggle to be heard even more than extroverts. In a functioning mob where "kindness, consideration and respect" is in action, introverts might have a better chance of getting their insights incorporated. In a delivery process that welcomes ideas and feedback at any time, the time to reflect to come to an idea is a non-issue. In a mob, anyone can use a second computer while working on the shared task for research activities. A lot of times, this enables an individual to contribute just the right thing at the right time, to keep the overall task flowing. In a mob, anyone can step out at any time, going for a walk to take quiet time, and just rejoin when ready. The work continues meanwhile, and after.  "Ask what you need" was Elizabeth's message yesterday, and that resonated with me.

Mobs are not just for extroverts. I have utmost respect for Aaron Griffith, with a test automation background and an integral part of the original Hunter mob and a self-proclaimed introvert. His article on Mob Programming for the Introverted is a great reference to someone's experience who isn't just thinking about introversion, but living a life of one - in a 40 hours a week mob.

Mob Testing after New Work

I'm absolutely delighted to have tester colleagues again. Well, we call us quality engineers, but the name does not change it - there's some pretty amazing testers out there to share with. The group of testers makes me remember times I was not dependent on Twitter to find people to learn with as I was while being the only tester amongst all the developers. And makes me feel torn in my priorities, at least a little.

Since I joined, we've restarted our regular meetings we call QE Forum. And created us a chat to discuss and share. A lot of positive energy around. Just last week we did a lean coffee at work, and I learned a lot from my tester colleagues both is in the topics they're into and the stuff we discussed deeper than titles.

The collaboration with my new-found colleagues has made it clear we're divided in our interests in general, while I seem to be interested in both camps. Usually it's either test automation or deep exploratory testing. And the divide also shows in my efforts to introduce learning together through mob testing.

We've done two mob testing sessions so far.

• Mob Exploratory Testing on a functionality I was working on at the company
• TDD in Python to improve our programming skills in the language we use to automate

The TDD session gave two surprising (to me) reactions. First was a non-programmer colleague who chooses to join programming sessions when I organize them in mob format. This experience brings back memories of how mobbing changed me: from reluctance to curiosity, and through learning to liking. Another was a programming tester colleague, who is now interested into moving from system level automation to helping developers with their unit tests. 

The Mob Exploratory Testing session was just fun and laughter amongst us finding problems I had not yet paid attention to in the feature I brought for us to test together. It introduced tools that no one else had told me about before that the others thought would be evident, but how could they be for someone who just joined the company. I introduced approaches to testing the feature that went way beyond the user interface, and we made interesting observations about limitations of the implementation too. 

So getting my tester colleagues to practice mobs seems doable and fun. The learning from group sessions makes us stronger in our individual work. But the big step is still work in progress: getting to do mob programming with my new developers. That may take some time, as I'm not ready to push people too much even if I believe in it being helpful. 

Not the same task

I share experiences and thoughts I've had on mob programming and mob testing from my starting points and perspectives. I don't get to (yet) work with teams fluent in promiscuous pairing, I still struggle with getting people to pair with me across specialties (tester - developer -pairing) and a lot of the problems I'm facing are related to inability to make releases, or efficiently collaborate so that a lot of time would not be wasted on either waiting or doing the wrong things.

I wanted to address a specific issue in the idea of doing a measured experiment on mob programming vs. pair programming vs. solo programming: the experience that it's not the same task and end result we're doing and getting into. 

The Ladder Effect

I was mob programming with my team, and we all perceived we were working on something relatively simple: we needed to take out old Telerik UI components and replace them with new family of Telerik UI components. It was a task that most of my team's developers had individually done on other areas and we were mobbing just because we wanted to practice working together - learning together.

One of the developers was navigating and telling what to do, when another stepped in to suggest a better way. As the two had different ideas, we got a third idea and a fourth idea, and had a quick discussion on their benefits. The fourth idea would have never come about without hearing the first three proposals. This is what I think of as the ladder effect: you need the input of others to come up with the idea one of you has that the one having it thinks it is obvious and it turns out it isn't. 

If each of the developers individually or in pair would complete the exact same task (which of course we don't, we're not researching but working to create value to production), the task is not the same. The resulting code is not the same. 

Not the same may mean it's irrelevant. We always have bugs in production, and some of them are just not so relevant. It also may mean it is relevant. That there's work not done, to be done later either as fixes or as slower progress on the next features due to what was missing from the code. 

To get the four ideas in, we would have needed an implementation, people caring to review in enough detail, at least once change of the whole approach to the change with a complete rewrite. So we shouldn't compare solo vs. mob with the idea that the end result in production is the same. 

A Stupid Little Thing

In a solo work setting recently, I was looking at code to realize that the encouraged practice is to include a copyright header in each of the code files. A lot of the files we had recently been modifying had a reference to year 2012. In many ways, this problem is below cosmetic, as it is never visible in any way to the end users, as we don't publish the code. But housekeeping-wise, there's still a working agreement we'd update this to reflect current year on edit. 

In individual work, whoever is bothered with these can go and fix them. But hardly anyone is bothered enough to do anything. 

In a mob, when this comes up, the group realizes quickly how stupid and repetitive task updating these is. Where each individually would either just fix ones in their scope or dismiss the problem completely, the mob hearing a second mention tends to recognize a theme they don't want to hear about. And recognizing a repetitive thing that wastes effort of the whole group, it gets automated. 

A Big Difference

One of the projects I recently completed with my team was a 6-month long refactoring/rewrite of something build over four years. Little did any of us know back when the problem started developing... But looking in hindsight, I can describe the problem. There was a solo developer would always get features done and into production, not the fastest of them all. He believed that code should be a tree in which you introduce a new branch when you get a relevant new requirement. By the time we realized what the beliefs were, he had seven full copies of the code conditioned to different versions of the code from start of the program. 

Someone did review it, but the reviews were in vain. In face of a seemingly impossible task, people step down and focus on what they were supposed to do. While others in the team are conflict-averse, I have a tendency of taking up things others don't. Thus the rewrite, as a pair. 

If we were mobbing, that result would have never happened. The developer creating the code with a significantly different belief system in what makes code maintainable could have learned sooner. Instead, he was doing code as he had done for the last 25 years. 

Whenever I paired with the developer even for half an hour, I was exhausted for a week. I'm sure others had the same feeling. Working with him in a mob, we could share the load of dealing with the differences. 

If it was up to me, that developer wouldn't be a developer. But it is not up to me. So I do what is the second best choice, help him learn. Mobbing was powerful in both building up the team to face the challenge, support in dealing with the challenge and eventually find the courage to fix the issue we had let build all too long. 

Starting to pay back is more relevant than cost

All of the last stories I share are really about the task or the cost of the task to get it actually completed to the same level. But a lot of times, I find, the cost does not matter - time matters. If we have something in production in a week even if it took five people mobbing, over one person working for it for three weeks,  we'd rather get to a point where the investment starts to pay back faster. 

We win customer gigs for speed - things that would never be our business' points of success otherwise. We have time to earn more money with the sooner availability. The little extra cost on development can become irrelevant quickly with scale in ability to sell the software. 

There was a feature we said would take 6 weeks for us based on our previous experience on similar features. We mobbed on it for an afternoon with 7 people, 4 hours each. A pair of us continued and the feature was done two working days later. So 6*40 = 240 hours and 7*4 + 2*2*7,5 = 58 hours. 

I'm sure the first estimate included significant wait times and interruptions that would happen a lot more over longer period of time. But the realized effort left a lot of time for reading books and studying that tends to be padded into our estimates, even if mobbing and pairing took the embedded time into that away. Fun is powerful mechanism. Yet, the cost isn't relevant. We won a customer case for that feature. That's what is relevant. 

Conclusions

If I would want to compare individual work to mobbing, I would need ways of making the task the same. Both the individual and the mob would need to produce a result with the same features:

• Same value for production, including same lack of bugs
• Same value for maintenance, only to be revealed long-term
• Same positive impact on the future tasks done individually 
• Same positive impact for the business overall

My evidence may be anecdotal, but it is enough for me to try more of this out. I welcome someone with resources to do proper research to do a good comparison. Then again, there's a gaping hole still on good research on individual and paired performance too. Setting up repeatable experiments is a lot of work, and meanwhile I'm happy to help my organizations improve using mob programming as one of the tools. 

Mobbing with someone who hates it

A lot of times when I talk about how much I've come to enjoy mob programming as a tester (feeling increasingly more comfortable in the uniqueness of my testing specialty among hard-core programmers), a question in the end is: "Did everyone like it, surely you've had bad experiences too?"

My worst experience was mobbing with someone who hated the idea of mobbing (or pairing).

In one of the early mobbing sessions, probably our first without an external facilitator, one session was particularly painful. After all the work I put in to convince the programmers to practice together in the name of learning for two hours, one of them felt forced into it.

Well, he felt forced into pretty much anything. Over the course of 4,5 years with the team, he labeled me as "organizational cancer" - whatever I was doing was destroying whatever he felt was important. He told me I existed to "ruin the life of introverted developers" and other even meaner things I endured on a weekly basis. But one amongst 10 really wonderful people can be dismissed, even if it definitely can wear one out.


But he was one of us, and we wanted him included. So he was, in particular from the invite from the manager insisting we'd do learning together as a whole team.

The mobbing experience that followed was 1,5 hours of agony. There was a consistent flow of negativity. We got to hear how this group work thing is like being in kindergarten. How adults should stop playing at work. We heard in various ways how much he hated every moment of it. When driving, he refused to play by the agreed rules of letting thinking happen outside the keyboard, and just went into coding with an audience, not even explaining. Everyone was in pain, yet none of us said anything at first, just trying to get the work done. At the end of the session, I was exhausted, and so were everyone else.

My frustration finally came out as a remark telling the guy that this thing in life isn't compulsory. If he hates this so much, he is welcome to drop out from the next sessions we had scheduled. His face lit up, with "really?" and he looked absolutely delighted. The others said nothing again, until only two of my team remained, including the manager. They pointed out that leaving him out was bad because he would need the learning mobbing could give the most. But we went with letting him opt-out.

The rest of the team mobbing without him had a great time. We learned a lot, we got things done, we developed empathy towards each other. And every time we showed up from our mobbing cave, it was like we had just been in a great party. He was invited, but opted-out.

Until one day he said he could join in. The fun others are having is inviting. We told him he is welcome, but the behavior we endured once wasn't going to be ok anymore. So he joined on occasion, observing and navigating, still opting out from the driver seat.

My lesson learned: you're better off without someone who hates it. And that the fun, party-like feeling of mobbing you're excluded from might just be a thing to draw you in. So allow opt-out, either completely or partially. Even make that explicit. We did not force him in the first place, but he felt it was compulsory as a whole team activity.

Details into Mob Exploratory Testing

I love exploratory testing, and have a strong belief in the idea that exploration can have many paths to go forward and still end up in great testing. Freedom of choice for the tester is a relevant thing, and I've grown to realize I have a dislike for guidelines such as "find the happy path" first when exploring.

Surely, finding the happy path is not a bad idea. It helps you understand what the application is about and teaches you about putting the priority of your bugs into a context. It gives you the idea of "can this work", before you go digging into all the details that don't work.

I've had to think about the freedom of choice more and more, as I'm doing exploratory testing with a mob. While I alone can decide to focus on a small piece (and understand that I don't know the happy path and the basic use case), people who join a testing mob are not as aware of the choices they are making. People in the mob might need the frame of reference the happy path gives to collaborate. For me, each choice means that it enables something but also leaves something out. Playing with the order of how I go about finding things out can be just as important for my exploration than getting the things done in the first place.

For example, I often decide to postpone reading about things and just try things out without instructions, recognizing documentation will create an expectation I care for. I want to assess quality in the experience of use both without and with documentation, and unseeing is impossible. Yet, recognizing documentation reading matters, I can look at the application later too trying to think of things (with my mind map there to support me) simulating the old me that had not read the documentation.

My latest mob I lead, I ended up with a more strict facilitation. I asked the questions "what will you do next?" and "what are you learning?" much more than before, and enforced a rule of making quick notes of the agreements and learning in the mind map.

When the group got stuck in thinking about a proper phrasing of a concept in the mind map or location of an idea, I noticed myself referring to rules I've learned around mobbing on code. Any name works, we can make it better later, "just call it foo" and learn more to rename it. Any place in the mind map works, we can rearrange as our understanding grows, we don't need to do it at the time we know the least.

Finally, I was left thinking about a core concept of mobbing around code: intentional programming. The shared intention of what we're implementing, working in a way where the intention does not need to be spoken out about, but the code shows it. Test-driven development does this in code, as you first define what you'll be implementing. But what does it in mob exploratory testing?

Working from a charter is intentionally open-ended and may not give the group a shared intention. Even a charter like "Explore Verify(object) with different kinds of objects and contents using Naughty strings -list to find inconsistent behaviors" isn't enough to keep the group on a shared intent. The intent needs to be worked out in smaller pieces of the test ideas.

Looking at this group, they often generated a few ideas at a time. Making  them write those down and execute them one by one seemed to work well on keeping them coherent. So, it looks like I had not given enough credit for the mind map as a source of shared intent for group exploration.

Other lessons shadowed by Mob Testing

Reflecting what discussions took place in the last two days of Mob Testing on a course, I realized there is a pattern I think I'm seeing when teaching in this format:

Mob Testing overshadows the other testing lesson I'm trying to teach. 

Regardless of what my first exercise on testing is, people talk only on observations about Mobbing. And that is not a surprise: mobbing for majority of people is awesome new experience and they need to share both their love of the experience and concerns on "this wouldn't work at our office". And then there are sometimes some people who hate the format. I've now met one who describes the experience as causing anxiety "my brain melts and I can't think". But all in all, the focus with first exercise is in the mobbing.

During two days of mob format exercises, the discussion changes back away from the mechanism of how we learn to what we are learning about. So it feels that mobbing eats away the other learning for people unfamiliar with the style and I need to adjust my teaching to accommodate that.

Instead of having my first lesson in mob being a central one (like ability to create Selenium scripts or Exploratory Testing with Charters), I need the first one to be something people know already.

It's hard to pay attention to all the learning going on at once. Need to figure out leveling things appropriately. 

Mob Testing meets Automation

Some months ago, I received an email inviting me to do a public test automation course in Jyväskylä, Finland. This course would be my third in series with the same title over several years, last edition being in 2013. Thinking about it a while, I decided to go for it again.

Since 2013 I've learned a lot more on test automation. I've also learned how I rather teach things on courses, creating experiences where the whole group shares the experience. For that, I use Mob Testing (or Mob Programming).

I completely redesigned my 2-day Test Automation Course to be around five experiences in Mob Testing format.

1. Creating a basic Selenium Webdriver test (4 times...)
2. Refactoring a basic Selenium Webdriver test to Page Object Pattern
3. Test-Driven Development with JUnit
4. Test-After and Test-First ApprovalTests 
5. Changing Web Application for making Selenium tests easier 

These are all pretty simple first experiences, but as per feedback, people loved the format and enjoyed the experiences. I was particularly pleased with my improved skills on TDD, reflecting to the time when I did my first course as participant and escaped due to my extreme discomfort for lack of understanding. I loved seeing my "I never coded" testers work as part of the group and pick up what we were doing in this format in ways they wouldn't have without the group (or my) support. 

The redesign left 6 slides from my past course. The delivery left me with ideas of what to clarify / improve, and I definitely will do this again.