Two 1st timer mobbing mistakes

We run a few mobbing sessions (both programming (selenium & unit tests) and testing (exploring & identifying security holes) at European Testing Conference 2016 this week. As usual in conferences, there was also a lot of amazing eye-opening discussions, and one theme in particular was about people's experiences with mobbing.

With Llewellyn Falco, we summarized the two most common mistakes people seem to be running into when doing their 1st ever mob, and ending up with a bad experience.

1. Long rotation
   When you start, use 4 minute timer to switch roles. The reason for this is simple: when you rotate fast, you get quickly used to changing perspectives between the driver and navigator. The rotation enables you to acquire skills related to working in this format, and keep everyone engaged. It also prevents getting stuck on one person and having one person dominate the mob a lot. It keeps the idea in a mob as opposed to in a single person. Iterations matter more than time. If you are going to spend an hour at the keyboard, it's better to have 10 iterations that to have one.
2. Not using strong-style driver-navigator approach
   In strong-style, the person at the keyboard is doing no thinking. The rest of the mob navigates her through the task. When you don't use strong-style, the navigators have to reverse-engineer what the driver is thinking. Also, if you don't use strong-style, every time you rotate you have one person thinking and when you rotate, you have a new person thinking. When you use strong-style in a 5 person mob, you have four people thinking and the rotation causes no disruption to taking the task forward. 

There are many other aspects having a successful mob, but these are the two big ones. If you are interested in reading more on this, check out our Mob Programming Guidebook. 

A public reply: Collaborative Exploratory and Unit Testing Course in Brighton in few weeks

In just a few weeks, I'm running a course with Llewellyn Falco on Brighton "Collaborative Exploratory and Unit Testing". It's a wonderful course, and we've heard a lot of positive remarks on the previous run of it around TestBash New York, so if you are around, you can still join us. 

I'm a tester (who finds coding not so interesting and exploring the best thing in the world) and Llewellyn is a developer (who finds coding the best thing in the world and tries to turn anything testing into code), and on the course we test together, in a mob, an application to find insights thru exploration and then turn them into code. 

I just received a question I felt was appropriate to answer in public:

"I'm thinking of joining the training you have on March on Collaborative Exploratory and Unit Testing. I was wondering whether I have to attend as a pair with developer or can I attend on my own?"

The course has been set up so that we get the group together to work in a mob. One computer, a mix of people and specialty skills, including the skills that we, the two trainers, bring to the table. The one on the keyboard is not responsible for solving a problem or taking a task forward, but that is the position of resting and listening, when the rest of us give the guidance on what to do.

You can join the group as an individual programmer. It would do good and take your skills more towards what we see on hands-on software architects. Knowing testing makes you a better programmer, and the guidance we have available is very much practical. 

You can join the group as an individual tester. In addition to brushing up your exploration, observation and test idea generation skills, you will get a basic feel of things you can do together with developers. 

Any mix of testers and developers works for the session at hand, but more variety introduces more opportunities to collaborate with different kinds of people. 

We hope to see you in Brighton in just a few weeks. 

Join us for a training around TestBash?

TestBash 2016 is sold out (good job people, great choice!) except for people who are joining also the pre-conference training courses. Whether you care for joining the absolutely wonderful crowd of participants and speakers for the TestBash main event, I'd like to tell you that you should join the course I'm doing with Llewellyn Falco on Wednesday March 9th: Collaborative Exploratory and Unit Testing.

I wanted to give you a bit of background info on the course, with the hope that it would make you realize that you or a colleague of yours should be there.

I'm a really good tester, and I specialize in doing the work at my day job, and distilling it into a teachable format on the side. Llewellyn is a brilliant developer, and an agile technical coach teaching developers throughout the world. And the two of have a connection, that enables us to do something that rarely happens: we bring together the best of testing as testers know it (as performance) and the best of testing as developers know it (as artifact creation).

During our 1,5 years of collaboration, we've learned to cross-pollinate ideas from the two communities and put them together in a special pairing style called strong-style pairing and a special teaching / working style called mob programming. I believe both of these styles are transformative work the ways we work at the office, and the troubles we have as testers and developers - I can surely say they have been that for me and my developers.

This course creates you an experience to go through lessons we've gone through, to feel the amazement of all the things a professional tester sees when they look at an application, and how those insights we create, as we work closely with professional programmers, can transform into working and maintainable test automation that is worth having.

Shall we meet you around TestBash to work out on this together? You can sign up here.

Best ideas win when you care about the work over the credit

With all the twitter-buzz on debate, there was a gem among all the noise as in tweets that make me think.

@maaretp thanks for the blog the best idea should win but I've seen head to head debate of ideas get in the way of ideas for some groups

— James Salt (@saltpy) February 3, 2016

My experience is, as a vocal person myself, that it's often that the best ideas don't win, they get hidden under the need to win a debate. This has come more and more clear to me being exposed to Mob Programming.

Meeting dynamics

Think of a typical meeting. You have a bunch of people, discussing a new feature, it's scope and implementation, things to consider and risks. It's probably a cross-functional team where people take a bit different viewpoints.

Let's look at the meeting from the point of view of game theory: how do you win in a meeting? If you go to a meeting and come away being successful, you must have said something. There might, for us testers, be just the right question to ask on risks that changes the whole design that made the whole painful 2 hours worthwhile and exhilarating. Especially since there was a time that many of us remember when we weren't invited and lack of our contribution made us fail big time. In meetings, it's the ideas we can think of that argue. We often have a debate of some sort, with the idea that the best idea should win. In a meeting, there's an incentive to have your ideas be adopted.

Even better. If your idea gets adopted, for most people in the meeting this means that you get to step away from the responsibility of doing the work. If it takes you an hour of a meeting to get your idea across, it can easily take a day or week for the idea to be turned into an implementation. So there's even more incentive to get your idea across there. The idea is credited, it was my idea even if it was your work.



Mobbing dynamics

In a mob, we work on one thing, on one computer all together. It's like a meeting, but the dynamics are nothing like a meeting.

In a mob, the incentive moves from coming up with the idea to getting the work done. A typical dynamic of achieving this is that we don't debate ideas, but we adopt them. If there's two ways of doing the same thing, let's do them both. And perhaps start from the underdog, the more quirky idea.  And you start to trust. Trust enables you to unlearn the concept that idea matters over implementation. Getting credit becomes a team thing. You will also see combinations of two ideas from two people. And emergence of a third, because both ideas you could come up with don't quite cut it.

In these cases, the incentive is very different: get the work done. So, people are more willing to work together, more willing to try things out, and when it is done, they are more willing to let it go rather than continue fighting.  It's important to care about the work and result, over caring about the credit.

Best ideas don't come out in debates. Best ideas come out in collaboration, when people feel safe. Loud and quiet alike.

On credit: while this stuff right now is something I can easily say, I know where I learnt it from. Thank you Llewellyn Falco for opening my eyes on better ways of contributing.

Stepping in on bad behaviors

It was one of these Tuesday afternoons, and nothing said it was supposed to be any different. There was the scheduled regular weekly meeting. And there was the work around the meeting, probably on yet another release and feature. Business as usual.

I was having a great time, socializing with my team on the work we needed to do. Or most of my team at least. But then the meeting starts.

At first it was all regular, checking in on what we're working on just like we do. And then we start talking of a specific area.

The specific area has been for years something we'd call a silo. I have recently been part of breaking that silo, and the code quality revealed makes me think of Matt Wynne's funny sarcastic talk on Mortgage-driven development. But as always when you do something like this, you bring out discomfort and pain.

So when I asked on progress and things I could help on in the area, I could anticipate all sorts of responses from the developer. And there it was again: the personal insults, the insisting of me being unreasonable and the wishes that I would just walk away and leave. Something has been learned though: the sexist remarks that completely strike me off balance are gone and just a memory that keeps me on my toes.

All I did in my perspective was to try to negotiate on the next testable increment, and the push back was harsh and personal. I can deal with it. But what surprised me was how my team of 8 others, including the project manager reacted. Most of them were looking into their toes, hoping they were invisible and pretending they did not hear anything. None would join, correct me if I was wrong or help us resolve the issue. I feel often alone at work, and I felt even more alone, realizing I'm the only one who goes face first into resolving a conflict, trying to talk it through and understand.

But this left me thinking of dynamics at work. Is it really normal that if you see something bad happening to someone you know, you rather stay away? I'm hearing it's a phenomenon that everyone waits for someone else to step in.

I asked my team why no one spoke up to learn they felt that I was doing fine by myself. That I did not need help. But a little support would surely have been nice.

I get similar feelings from some online arguments. So if you feel you're an outsider joining in, please do. It just makes it feel so much better in case there's really something threatening going on. 

Consent first debate

Recently, I've been putting a lot of thought into how I want to handle myself in the professional circles. It started with a friend from Agile Finland mentioning he sees me getting into these arguments on twitter, where there just isn't a winner. Everyone loses. Time. Peace of mind.

From that comment, I signed him up as my personal coach. I wanted to work on "mindful online presence" and so far only thing I've learned that I feel much better when I manage to step away from the arguments. To remember that I don't have to respond, even if I sort of initiated a discussion by venting on something like people saying things like "detrimental to our craft" on something I believe might just as well be taking things forward.

Stepping back from the discussions doesn't usually please people, they tend to seek answers on why would I do that. The way I think about it right now found words from a blog post by Marlena Compton, titled "Feminism in the Testing Bubble". My takeaway from that article isn't the feminism, but the idea of a tax. 

"There is a tax for people who are part of any marginalized group.  The tax requires that you will spend your time and energy not on the actual topics you care about and want to write about such as software, but that you will spend time and energy defending your participation in the space and your right to be there.  The tax is so far-reaching and insidious that you will end up paying before you even realize what’s happening."

"Payment comes in many forms:  your influence, showing actual emotions on twitter, a boss’s anger, exhaustion from explaining yourself (again) and then there are all of the requests people make of you to teach them because they don’t feel like finding answers for themselves."

I feel part of a marginalized group in context-driven testing. I don't want to stop saying "exploratory testing" or "test automation". I don't want to discuss the one true way. I don't want to build walls where you only hang out with people in one camp. And I don't want to spend my precious little time on trying to convince those who want things I don't want that my way is the true way.

I blog to share what I think. I write more for myself than for an audience. If any of it is useful, great. If it starts discussions checking first on consent it's great. When I refuse to invest my time, I would rather have people accept my choice, than tell me that I must discuss all things testing.

I'm not paying the tax anymore if I learn to avoid it. I want to talk with my peers on how we teach testing skills without RST models, in a very particular style: pairing/mobbing and slow change, an idea at a time intertwined with reflection. I want to find time for that, and I prioritize other things out so that I have the capacity.

Marlena sums it well:

" I don’t mind if people communicate with me to tell me how wrong I am about that, just don’t expect me to give you a cookie."

 "...it is ok for me to push back on taking responsibility for fixing things.  It is ok for me to voice a frustration or call someone out and leave it at that."

Could there be a lesson on importance of consent in debates to take from here? At least teaching/coaching without permission is considered more of a bad than good thing.

Thanks, but I still have test automation

There's another big buzz in the world of testing, as the allowed and acceptable words are being refined. This time, the word is automation.

I know testing cannot be automated for now. In its full features, it's a process of collecting empirical feedback on things from we know to expect to things we had no idea could exist. It's full of all kinds of wonderful activities, where a thinking human is in critical position. It's hard to talk about testing because your testing and my testing won't be exactly the same anyway. Why would it be such a bad thing when people talk about test automation meaning the parts they believe they can automate.

I also like to think of it this way. If programmers job in general is to automate things, to get started on that does not mean everything has to be automated. A robot that does heavy lifting for people is valuable, even if it only operates in the warehouse and does not deliver things at your front door.

Merriam-Webster defines automation as "the process of putting an apparation, operation or system under control of mechanical or electronic device". When we put parts of testing under control of electronic device (the tool that we need to attend to differently than if we did not have it), I'm doing test automation.

Having more words to explain the details would be helpful. What type of test automation are we talking about? Is it execution? Monitoring and reporting? Setting up data and environments? Which specific problem in the domain of testing we're trying to control removing humans at least partially? 

I've seen my share of wasteful test automation. I've seen it replace thinking where thinking is due. But I've seen that fixed by introducing experimentation culture and empirically assessing what worked for us. It can include failing with automation on the value it provides. We already have words to discuss that problem: value, opportunity cost, short-term and long-term. Many of us are having that conversation continuously.

A main principle I always remember of context-driven testing is that people are the most important aspect of any context. How about believing that people will look for solutions, and figure out what does good enough job for them without redefining anyone else's namespace. If using the word test automation makes me less of a context-driven tester, so be it. I just want to ensure the organizations I'm working with have the best chances of doing a good job. And good job looks different depending on organization and the day we're looking at it. Everyone is learning every day, including those of us who think they've already learned a thing or two.

** as for calling automators technical testers, no. There's technical testers who don't program but are intertwined into the system / environment technical aspects. Like saying people in IT departments wouldn't be technical.