The destructive forces against conferences

My social justice need raises its head once more to blog as a response of what is going on in the interwebs: the Agilia Conferences rude response to a query on diversity. But the recalling of sponsors and asking speakers to take a stand starts to feel like a witch hunt. And there still are no witches!

What happened?

Agile development (and Testing) in my experience are areas of software conferences with very healthy gender ratios in general. Take Agile 2015 in US for example: lots of women.

When  there is a conference with 27 speakers on Agile, and only 2 are women, it is hard to not wonder. And I love the world where we nowadays are (mostly) encouraged to point that out, because awareness is the first step to change things.

So Agilia Conference representative had a rude response. The response refers to caring about this as feminist game, makes the choice of a he-pronoun on welcoming speakers, and and mentions engineer diversity games and not being a political party. Judgmental language, sure. They further referred to extensive screening and later even shared blog post of what that means unintentionally implying that since women don't get through their screening, they are lying more often in their conference presentations.

A step back

Surely the responses have been insensitive and unaware. But what is this campaign I see of twitter going for killing the conference? They were very clearly defensive with their first reply, and their defensiveness under the attack isn't going to change things, just make them feel the great injustice.

So, they miss out on a lot of things:

• They most likely invited some of the speakers as paid keynotes. There they had full control of choosing. When they did not choose a woman, it more often is about not being aware of great women than an intentional choice of the 2-4 absolute best speakers in the keynoting circle. The chosen men are great. There could be other chosen people who would be equally great.
• It matters if you see people like you speaking for future years for availability. Conferences that struggle with diversity keep struggling with diversity, because none of the minority speakers wants to be on stage as the token. Software is built by people for people, and we're relatively even on the gender ratios as users. Across roles in organizations (esp. non-technical agile) the ratios are not that far off balance in creation of software over its use. 
• Their call for proposals is responded by people who  have something to sell. They might pay their own travel to be there - we'll, their companies do. Looking at the Agilia commitment to extensive screening it looks like this applies to people's promises to speak there. But they are very likely to miss out on groups of people to submit that they are willing to publicly insult. 
• Insulting anyone and not being nice is always  bad. The underlying idea of not really caring for the gender of the speakers gets distorted and just oozes unwelcome.

But really, is this crime so bad that there needs to be a campaign to hurt them?? If they don't see things our way, they should go away??

Regardless of the bad expressions, I'm reading into their responses:

• They might be genuingly puzzled on what aspect is making people upset. It's not the amount of women they ended up with, it's their response to raising that issue. 
• They might not have the help to solve this. They need women to help but it is not the womenkind's responsibility to stop all their doing and jump to help (even if they seem to be thinking that). 
• They're oblivious that conference organizing is not about passively waiting for your call to be found and responded to,  but you need to actively seek. Very much the same way the extensively screen what they get for being truthful, they need to pay attention to the truthfullness of the industry they are aware of.

If you have energy for the negative action, how about targeting that energy for a little more positive? 

Things I learned while being coached

Some months ago, I felt it might be a good idea to try coaching. The idea emerged from an actual problem I felt I could use support in solving that a coach within the Agile Finland activists group picked up without directly mentioning it. And it lead to me reaching out to him, asking if he would be available to work with me.

I was curious and filled with skepticism. So a coaching relationship started, ending today. And it was great. 

My skepticism was met with a nice dose of what I would call coaching humor - making a point when using "tools" on me.  The format we used became known soon. Work on my goals. Work on working on the goals. And asking a lot of questions, leaving a lot of space.

The sessions with the coach were not my main source of takeaways. The main takeaways came with the increased introspection that tended to follow the sessions when I was trying to figure out what I wanted to do with my goals when following even a self-made plan from the sessions often felt off. 

I learned things about myself:

• I've been heavier on introspection for a long time which might be atypical. I find it core of exploratory testing to not only look at what I did but also what I felt and what I learned and how I could fool myself. Realizing that made teaching this more explicit for me.
• Sticking to plans I expected of myself is an external expectation I mirror on myself. Creating a list of things important to me and letting my plan emerge through action both increased my efficiency but in particular, helped me find balance I was seeking.

In the coaching process, the main thing I feel in retrospect I needed help with was identifying and naming my goals. With the goals in mind, progress was possible. 

I'm still work in progress and thinking of my next steps. Friends might suffice for a while, but later I need to try more of this with a different type of coach. 

A lot of the introspection during this process lead me to create another talk. I call it We're Work in Progress: Lessons on Becoming a Great Tester and I think it is going to be awesome. 

Conference diversity discussions makes my kids be late from school

The topic of diversity in conferences lures me in and makes me pay the tax of time away from things I thought I would be focusing on. Sometimes I think someone needs to do it. More often I just can't help myself. To an extent that I forgot to send out my daughter to school on time this morning being intellectually engaged in thinking about this.

It should be a normal thing by now that one of the women will ask if a conference is low on women. The best of conferences work hard to encourage and reach out to more diverse set of speakers (not just women), but the worst conferences respond with questionable approaches.

@samlaing Why we shoud worry? We do not play feminist games here nor politics. Whoever pass our extensive screenening, he may come.

— Agilia Conference (@agiliaconf) March 29, 2016

I look around quite much, but just as I'm sure this conference had never heard of me (because I'm confident in passing "extensive screening" as they describe it on their pages), I had not heard of them. Now I have and know a place to not go to.

Personally I believe extensive screening would include both knowing your options (that would naturally lead to more women in the program) and knowing their contents - not just the latter.

With lists of hundreds and yet again hundreds of great female voices in tech and agile all around the internet, there's often something wrong when the end result is women not having been reached out and not on the program. This is organizer work, to work on their natural biases of connections. Saying there is not more of worthy female voices is another excuse. Today that could  be someone else's discussion.

Yesterday I suggested that for those who actively look for women (or great speakers), looking for paying work would provide better results. I got responses, for which three I feel I must address to get them off my chest.

Don't bite the hand that feeds you!

I am a conference speaker. 33 sessions of various sorts in 2015, and close to 20 booked for this year. Very few sessions that pay for my time, but just enough to afford this expensive hobby. My side business income goes completely to support other businesses (conferences) who don't pay expenses (nor fees). I'm taking my side business up a notch and starting to pay other women's travel through scholarships. I clearly can't change the conferences, but I can change things for the women like me.

Writing posts about diversity is deemed as biting the hand that feeds me. The conferences give me a platform to speak and I respect that. But using that platform does not include a promise of not saying that I disagree with their approach that I live by when I feel like it.

I can ask for more and better even from the best ones out there, like Agile Testing Days. And they are great in seeking solutions to get one step closer to where we should be if in any way possible.

Women don't self-promote - my fault I wasn't invited!

Whenever I talk with people about why I find easily a hundred new women to choose from for my conferences & meetups every year (and need only 20), I realize my approach is very different. I'm a woman who talks to women and men in conferences to find out their passion and experience. That information in many cases transforms into a great talk.

I just got an email a week back. A lady from Finland emailed me to tell she had accepted a speaking position at the local major commercial conference because the conference knew to contact her. They knew, because she was on my list of people who amazed me in the last  year that I forwarded to the organizers. She did not know this, as far as I know. She said in her email that she remembered a discussion she had with me last autumn on speaking and she had been thinking about it since. When asked, all she needed was to get to work on something she wanted. She asked my mentoring, which I happily commit to. Find you ambassador. Even better, recognize that is a service you could pay for. I do it only for those organizations I'm self-invested in seeing succeed for a deep, personal connection.

With this background, it feels weird being told that women need to self-promote better. That we should share stuff continuously. That we should be out there, not just in our work places. That's a tricky balance. I organize a lot. Most men take the platform I organize and just self-promote - smart prioritization or an inherent bias - who knows. I speak and write (share) a lot. But I also still test. Every day. I'm not a consultant selling myself - as in getting paid for that. Everyone sells themselves to some degree. I'm a tester, in love with a better world for software professionals and in particular success of the product I work with on a daily basis.

Whenever I hear something women don't do, I think of something women do do. When women stay focused on the success of their product in company, they are not visible outside as much. When women focus on being visible, they do a little less of something else. The balance is hard, but it is also something that there isn't one recipe for.

I've been told speakers fit a pattern. The pattern seems to identify that conference speakers are company evangelists or consultants selling their skills. The diversity I care for most isn't gender, it is to hear more voices of people who do this stuff for majority of their time. People who focus on doing, are not promoting. But they are ones with interesting questions and engaging discussions in conference after-hours who need to asked to speak / share. All genders. 

It's easy to get to a feeling of being an imposter. There's always something I have to do to be wanted ('If your job would be more interesting', 'If you would spend more time promoting yourself'). It's never what I do now, it's always something different. I've even heard I need to look different to fit the part. Enough crowd, all kinds of views and it's good to remember that feedback often tells you more about the giver than the receiver. It's not that I'm stalled, but I'm internally driven.

Speaking is self-promoting. It also (for me) comes from a place of deeply caring for people around me. I've failed and learned, I'm trying things. Dialog helps me improve and gives different things to different listeners.

I was speaking first, self-promoting actively later. So I will speak for speakers who start from just sharing to learn. My peers. People as shy to express their true thoughts as I was when I was younger.  People who need the encouragement from me that I got from the amazing people around me when I needed it.

Fixed amount of money and who deserves it?

The last bit I want to share on is the discussions I end up in with people assuming I have no sympathy for the organizing work. As serial organizer, I might not emphasize enough how hard a job that is and how that too - obviously - should be paid for. There's also a financial risk. The organizers pay the bills even when the participants don't buy the tickets. And scale of participation matters, a lot.

You should get paid for the hours you put in organizing a conference. Just like the speakers should be paid for the hours they put in speaking at your conference.

One full-time organizer is 150 hours / month. With one conference for the year, that's 1800 hours. And most have organizing teams.

If you then have a speaker, let's say it takes 80 hours to a talk with all necessary pieces (often more as you first use days on abstracts, submit & get rejected, try again, get accepted, organize all the travel related details, promote the conference for months in your channels, prep and practice the talk and travel and deliver it).  That's little compared to organizing.

But let's say you have 100 speakers. That is 8000 hours of free labour, and a much more relevant figure in comparison to the full-time organizer.

Do your math and find a way to split the money is all I'm saying. Keeping the organizer alive is in everyone's interest - organizer needs to be paid to do it again. Find a way of sharing the risk so that payments are conditional:

• Pay (more) IF financially successful after covering running costs including organizer compensation
• Pay (more) IF delivered session attracts lot of attendees
• Pay (more) IF speaker promotion brings paying customers

Eventually, the problem seems to be that there just isn't enough money around to share in relation to how much work there is to get a conference running. And we're used to cheap conferences and speakers volunteering for practice / promotion reasons. But that could change.

When I told a speaker at European Testing Conference that we will be paying them - every one of them - for speaking, I remember his face and response. He looked at me, puzzled and said: "I don't speak at conferences to be paid, I speak to share and learn, and make my money elsewhere". I respect that. But not all of us do. My claim is that many women don't opt for speaking because of the financial reasons. 

Speakers and organizers are in a symbiotic relationship. Could we improve the win-win here? 

A fun day with APIs

While my article on things I've learned on exploratory testing APIs (spoiler: self-confidence, we know more than we give ourselves credit for!) is being reviewed and finalized, I needed to write a bit about some recent discoveries of how much I love legacy and history.

I was thinking back to APIs I've run into, some today:

• APPC (Fixed length messaging) on mainframes
• Text parameters over COM 
• Complicated XML over SOAP request-response combinations
• URL-like REST services
• public classes in various libraries
• protocol implementations based on a RFC

The detail I was realizing that for me, the technology was never the key. The developers I would work with would seem to twist themselves in weird ways to emphasize how we needed a complete rewrite for a better technology.  I was enjoying myself with the ideas of forgetting the technology and just taking it as it is, considering how we could make the best out of what we have - what feedback would be relevant. 

I find I bring two things into the discussions around APIs right now as a tester:

1. Feedback brings in discipline. We remove stuff we don't use. We clear up the names. We're more specific about the changes we communicate outside. 
2. We talk more of why than just the how. We go back to the sources of requirements to question things we take for granted. I suspect we keep learning again and again that thinking of the purposes of use we will end up with simpler solutions. 

I still don't care of all the details behind. But if we made it, we surely can test it too. And enjoy ourselves while at it.

Want more women speakers? I can help!

I'm having a difficult day that is generating brilliant ideas. After you've read this post, you'll probably agree.

This morning, I checked if I would want to travel to Nordic Testing Days. It's close by. Not very expensive. Often good. Conclusion: No. Four men as keynote speakers. 5 workshops all lead by men. Very few women in general on the program. Not my kind of a conference. Maybe next year.

This evening, I saw a tweet directed to one of my favorite gender diversity advocates and tech power ladies:

.@agileTD Dec 5-9 https://t.co/flaqRHGLz8 wants at least 50% women speakers. C'mon #agilewomen make it 70% :) @jdiaz_berlin #changetheratio

— Cindy Gallop (@cindygallop) March 29, 2016

Great that Agile Testing Days is trying to reach out to women. They are clearly doing so much more than most other conferences. More than the morning opener. But they could do more.

They could pay for speaking. 

Right now, they pay 700 euros of expenses within Europe and 1400 euros of expenses outside Europe. This includes a limitation of number of hotel nights - to an extent that I lost 100 euros speaking under these conditions and not reading the fine print in 2015, arriving on time and not leaving right after but the following morning.  My total costs were less than the budgeted, but they were not paid in full. My loss.

Instead, they could pay e.g. according to Jurgen Appelo's public speaker fees. I can promise 50 % great women speakers if the price is 3400 euros within Europe and 5900 euros for outside Europe. I can promise we submit and work out our best if the money is available.

To top that, I can commit to selling that service. I will find the women from my networks. I will find the women to coach the women to deliver great. But I expect the conferences to put in the money.

I introduced this idea on a Women in Testing group with 76 women. I feel I can stand behind that promise. We're all amazing. We deliver well. We're worth it.  There's great new speakers who deliver brilliantly with support. There's those of us who should be considered professional speakers. What's the message you want? I can tell you who delivers that beautifully, practically and with inspiration.

Want to change the ratio? Change the way you pay.  

(and just for the record, I think men should have exactly same prices. When this service starts selling, I'm happy to extend to all the great speakers)

ADDED AFTER POSTING

I am, and was while writing this well aware that Agile Testing Days pays something for all their speakers and are exceptional in this sense in the field of testing. I want to emphasize I respect them greatly for that and their diversity work reaching out to women to feel welcome.

I have enough experience around speaking to claim there's five main models of treating your speakers from call from proposals:

1. Speakers pay all their expenses AND conference fee (full/discounted) when accepted as speakers (e.g. XP201x)
2. Speakers pay all their expenses BUT not conference fee (e.g. EuroSTAR)
3. Speakers pay some of their expenses (usually travel but not accommodation) (e.g. Agile201x)
4. Speakers don't pay expenses to a capped level - either sum & general policy, like travel in coach (e.g. AgileTD)
5. Speakers get paid to speak: they get to invoice a sum to compensate for the time they use on delivering and prepping the talk

I simply say that if you want - really want - to see women rush to your conference, make it financially worthwhile. Not just that they don't lose money directly. But also that they get paid for the time they put in. Time away from work. Hiring someone for childcare while you're gone. All the work put into becoming the speaker since you don't pay just for the time they give you now, you pay for the time they've put into becoming the speaker you want to have on your stage.

This is how AgileTD treats keynotes and it is great. I'm just saying it could extend beyond keynotes. And if it does, I'm happy to line up more brilliant women, the ones that no longer do this for free. 

ADDITION 2

I am aware that there should be paid staff to run conferences. I'm also sure value of their time and value of speaker time are not mutually exclusive.

Let's still state this: I don't think we should only pay women. I respond to the idea of asking for more women. I would also like to ask for more diverse experiences from men. We have same names going around a lot of the time. Then again, audiences change and the same people are new to the new crowd. 

From teaching kids programming to teaching adults

Two weeks ago, I was sitting in a bus on my way home from Brighton TestBash, and something very typical happened. From a random discussion, I turned the idea into an actual event within a short timeframe. We decided a session to teach my colleagues, the "non-programming testers" programming was in order. The event just emerged. "It does not have to be a big deal" to learn programming as Anna Baik and Andrew Morton had just reminded us - or organizing events out of a whim.

With open invitation to the community in Finland, we found 10 people within a very short timeframe to join us for a basics of programming session this evening.

We worked on the next generation of "Teaching Kids Programming" -materials  - with the added stuff included since the project branched.

The participants got to experience the basics of Java and Eclipse, with regular discussions on how this "simplified stuff" connects with real programming. The group learned loops with Sparrow Decks (code examples of knowing how many times things get run shown in fast progression without instruction) and learned to work together in pairs with Strong-Style Pairing. Everyone got through the instructed part, passed the quiz with lessons they had just learned from the teaching and topped it up with deepened learning through unit test Koans in a Mob Programming format.

The biggest reward for me on organizing was a friend who said she'd join the session to see why I would make such a fuzz over this experience of learning programming being different. At the end of the event, she said she really enjoyed it, and could see what I love about this.

The energy in the room was towards continuing to learn this way at work, asking people to let us learn through immersion as being the hands in a pair or joining a mob. We decided we should get together to continue on with another session, to dig deeper and practice.

There's hope for all adults who want to learn this stuff. It's never too late. And there's many ways of learning, not having experienced this way might just be one of the things that make you energized on learning.

There was a great reminder on twitter as I mentioned we're doing this session:

@maaretp @LlewellynFalco Annoys me how strong the "don't learn new skills, you'll never be any good at them!" meme is.

— Anna Baik (@TesterAB) March 24, 2016

Like we reminded the group: we all know how to read&write, but few of us have ended up as award winning novelists. Any level of programming skill is useful.

My reminder of all of this is this:

@TesterAB @LlewellynFalco I don't get this. I get (and do myself) the one that gets annoyed with overvaluing _this new skill_ over others.

— Maaret Pyhäjärvi (@maaretp) March 24, 2016

Given enough time, this skill is lovely to have in one's toolbox. And it's not away from valuing the skills I've learned in the 20 years leading up to this point.

Mob programming and groupthink

Back in the days of my very first agile introduction, I run into a problem. We had (junior) testers who had just joined in without a tester background working in very close collaboration with the programmers in the teams. These testers struggled to turn into testers at all, they were more of programmer groupies. It felt like they idolized the programmers (I even felt we had a group of programmer groupies amongst us), and thought their own perspectives on what might be valuable were always less valuable. If the developer argued something was by design, it stayed that way regardless of how bad it was for the users.

I thought about this experience today, as there was a discussion started on mob programming and what that does to how people work together. I feel there's a lot of benefit for me in having the self-confidence of a senior tester in being close to programmers as my ideas turn into code just as much as anyone else's, but I suspect things would have been very different if I was a junior joining similar settings and just starting to build my professional identity.

With regards to mob programming, it still seems to me that most teams mobbing are very homogenous. People with similar backgrounds and experiences. Mostly men. Definitely not having full-time non-programmers sticking around. And some of them even report that collective overconfidence, "groupthink" was an issue for them.

I find that having a diverse group can help with groupthink, as someone different naturally steps out of what the common path is perceived to be. But it also brings struggles. With the full visibility on what is going on in the mob, the group might feel that they don't recognize the value the different person brings in, even formulating that as extreme as "there was none, he just did not learn / did not do his job". I find that in retrospectives, I've been one to point out stuff I contribute on and that what I did as a non-programmer could have easily been discounted without the discussions.

It's been clear I was different. I still am different after all my mobbing experiences. I will probably never be the same as I have my route of growing into the person I am nowadays. But being different, I also tend to keep us honest. I tend to go hunt for evidence from real users. I tend to ask for metrics of use. I tend to suggest optional views, just so that we would not choose blindly.

Being different has been somewhat of a personal trouble. It has meant that I have needed to volunteer to be totally out of my comfort zone for extended periods of time, feeling totally exhausted. Believing there's a greater cause of helping build our team relations is what kept me going when it just felt like I was exposed and failing to any standard I would set for myself. I know none other in my team would have volunteered for the discomfort I volunteered for. And I suspect that not many people naturally would.

Having people like me is having outliers in the team. But it also seems to be a very effective way of avoiding groupthink when we're not all the same.

Groupthink is not special to just mobbing, but mobbing could potentially drive you to it quick. My team had groupthink already before mobbing: for 10 years, the developers and business people believed that software cannot work when it comes out of the development team. That changed quickly with the first experience of things being different.

Being different enough might be helpful. Daring to believe what you have to say in relation to what the others contribute is at least essential. 

Mob Testing: Definition and Clarifications

I did a webinar on Mob Testing as Ministry of Testing Masterclass this week, which will later be available in the Dojo if you missed it. My slides are available on Slideshare. There were some post-session questions I thought I'd take a moment to respond on in a blog. 

What is this?

Mob Testing, as I see it, is Mob Programming (Mobbing) applied to any activity we consider testing. I personally love both Mob Exploratory  Testing and Mob Testing to create automation artifacts. And best of all is intertwining testing with programming so that activities become hard to separate, which would then just really be mob programming (with an embedded testing perspective). 

So we take any testing activity, put the whole team together to work on that and rotate roles every 4 minutes - that's the start. The group finds a way to test it, building on what is going on, working as one mind on one task. No deciphering of what goes on in the computer, as the things that driver do must come from the navigators in the mob: no thinking at the keyboard. 

Q&A

Someone working in an Agile project (between the lines definition of agile is Scrum) asks more.
 
1. When does Mob-Testing takes place in project/feature life-cycle? Is it during the sprint along with User-Story Testing or post-sprint during as a regression/bug-hunt activity? 

These when-questions are tricky. Let me elaborate.

For a very agile project using mob programming, the whole question of timing would be irrelevant. When the team members come to work in the morning, they start mobbing. They do that throughout the day until they leave. No code gets checked it without the team being there to work on it. Testing is getting intertwined with development. And releases of changes happen typically throughout the day. But this is not the agile you speak of. 

Agile I live with does not in-sprint and post-sprint activities. All activities happen in flow, I don't even have sprints. Each feature for me goes to production when it's ready and tested. And that happens daily. But the concepts in the question give me an idea of an organization that splits done to in-sprint and post-sprint activities, as there's work that leaks out of the sprints (and best way to fix that is to get rid of sprints and move to kanban and continuous delivery, but that's another topic of my earlier webinar available on Dojo on Continuous Delivery without Test Automation). 

I'd say almost anyone considering mob testing (over mob programming) isn't at a point where we'd mob full days. Then Mob Testing is a learning activity, during which we also contribute. So timing becomes a question of when appropriate activities take place. I personally find a few timings particularly great:

• Mob Testing (exploring) after feature is "done" to find out what is the real use experience and how the changes sit together with the rest of the product. This is typically for the purpose of learning about a feature / change in the context of the system. Creates a great experience of what a tester would see looking at something that is "done" in the eyes of a developer. 
• Mob Testing (exploring) when we're assessing the new feature in the context of it getting implemented. Knowing the state before (and finding problems in the state before) tends to result in shared understanding of what we're building and overall better quality through fixing around while at the change. 
• Mob Testing (automating) when there's anything you can automate. It could be shared unit test creation, it could be shared BDD implementation of tests, it could be adding some Selenium. 

You have in-sprint and post-sprint testing, and both have different focuses as activity. You can mob on either types of activities. This of it this way: which activity would benefit from having all brilliant minds collaborating around the task the most? Where are special skills of individuals that others would benefit from being exposed to? Where do we most need the fun and motivation that working together on a problem gives us? (boring and challenging are both good answers).

2. Is there are multiple Scrum Teams and Testers are assigned to specific specific team, How does knowledge sharing takes place before getting together for such activity? Or is it some kind of activity where only people with prior knowledge will speak and others will attend just to gain knowledge? 

I've worked with software I have no prior knowledge on, and as a tester I learn in layers. I don't need all knowledge to be useful. For testing something you don't know, you learn while you test. And you are always free to ask people in the mob (other than the driver) to help out with their knowledge. Typically if there's only one expert available, I tend to not have that expert be the driver at all, but take turns in navigating as designated navigator and mob navigator. I would also ask the expert to only navigate when others get stuck or off the path in a relevant way. 

I've noticed that doing something (trying) I don't know creates a focus on knowing more. Passive following creates less of it.

Think of it this way. When I was mob programming with my team for the first time on refactoring, I had no idea of what we'd do. The whole IDE was strange. They would tell me, when I was driving, keystrokes on the first round. But I learned immediately. And when it was my turn to be the designated navigator, the rules of the game were clear. If I see something long, we'll look at breaking that. If I see a bad name, we'll rename. I was not alone, even if I was responsible in a particular role for my 4 minutes. 

I tend to choose activities to mob on so that it does the leveling of knowledge. If something is very advanced, I would do that after I've done other mobbing activities leading up to it. 


3. Who all are contributors in the activity, only Testers / Tester+PO / Tester+Dev / Tester+PO+Dev / etc.?

For mob programming, we're talking of whole team activity. Every skillset present. Non-programmers turn slowly into more of a programmers. And programmers create a lot more empathy for business and real users, when these sit together with us in the team. And the fast answers make a lot of difference in what comes out. 

For mob testing, you really need to think of who would you like to share the experience of testing with. It could be just testers like on most of the training courses I deliver. It could be an equal mix of testers and developers, like on the training course I deliver with Llewellyn Falco. It could be one tester amongst a whole team of developers like at my day job. It could be testers and product owners, when focusing  on better business understanding for tests. Any mix of these. 

If your group gets bigger, you might want to consider rather having two separate sessions. 

4. What should be the frequency of Mob-testing activity, per-sprint / per-PSI / per-Release / etc.?

I think I might have answered this in the previous question. It could be that all work - including all testing work - gets done in the mob. Or it could be any amount of time you choose to use on mobbing. 

2 hours a week is a great way to exercise mob programming with my team. But we do more than mob testing. All activities are included. The week in between lets people "grow muscle" from the exercise we did, and manages the worries people have in thinking individual contribution will get them to the end goal faster.   

Going a level up as speaker

I still get nervous every time I get on stage, but I feel the need of doing that anyway. For me, getting in stage is about making connections. I try to give ideas to people who choose to use their time on listening me, most often from a deeply personal perspective. Being a better speaker has really been my focus this year, and I thought I should blog a little about it.

I've chosen a couple of activities to try out on improving my speaking game.

A Women Keynoting Mastermind Group

By this time of the year, I'm towards the end of a group coaching experience with a wonderful group of ladies. Facilitated by Deborah Hartmann-Preuss, we've been searching our strengths and development areas and been challenged on things we did not think of ourselves. This group lead me to my first challenge, sticking to a fewer amount of presentations.

Fine-tuning of slides through fiver

I just put in a gig on fiverr.com on looking for someone to turn my style of slides into a great talk slides style. I was planning on trying 10 for 5$ and then make my decision. Seems there's stuff I don't have to do myself - a great realization!

Commit to a Few Talks for Now

With years behind me, I have a lot of stories to share. And I've shared many. Sharing and presenting have lead me to learn of things, and learning of things have lead me to sharing and presenting what I learned. I seldom volunteer the same topic more than once.

The theory however goes, that going around, I will be speaking to different audiences. Giving more room for a great talk to grow through delivering it again and again could help the talk evolve. Being comfortable with knowing the talk I can move my focus from my delivery to the audience reactions. Fine-tune and perfect.

I've believed strongly it is not the way to go. So I'm testing my beliefs. This year I'm doing just a few topics around in different places. A combination of Mob Testing, Mob Programming and Exploratory Testing is what I speak on. I do talks, workshops and trainings on that topic. And I will get even greater at delivering these sessions.

Become a better storyteller

I will be shortly starting an online course on storytelling. There's an overall story to our presentations, and there's many smaller, supporting stories. I want to learn to be better at doing those. This should be interesting.

Become a bad actress to become a great speaker

There's a group of people who already think about how to deliver great experiences on stage. I will find the courage in me to join one of these groups and face yet another paralyzing fear of mine.

Focus on speed and pacing

On my current level of speaking, I recognize my fast delivery of words is a challenge, and I'll very specifically practice on that. The best places for that might be the local Toastmaster's clubs.

Watch myself on video more

I commit to watching all my recorded talks this year and giving myself feedback to react on. For self-critical people like me, that is extremely hard activity. And I make a promise myself. For everything I do wrong, I will work to find one thing I do right and do more of it.



That should get me started. I reserve the right to learn that I want to do something different, as long as it is not for avoidance and self-deceit. Do you have similar plans and would you like to share some part of my journey with me? Get in touch. 

Fear of technical and unknown

I've been a tester for 20 years, and it has been (and will continue to be) quite a learning journey. With this post, I wanted to take you back on my memory lane of something that really spoke volumes to me, enough that I remember to keep going back to it 15 years later: Bret Pettichord's old article on how testers and developers think differently.

Here I wanted to address one of these four dimensions in particular: Need of Mastery. The reason I want to discuss it is that I delivered a half-day workshop on API testing last Thursday, and looking at how the group responded to the work lead me to recognize a common pattern in people facing exploratory testing in course settings: fear of the technical, fear of the unknown. Paralyzing fear.

For longer than I care to remember, I've learned to tell myself that as a tester I'm expected to be able to work with partial information and understanding, and still be useful. While I definitely am not a product expert on day 1 of a new product, I take pride in being able to provide results and being useful already then. It's about the choices I make on what to focus on next. And day 1 is always just a beginning, it opens up the chance of treating every day as a learning experience I walk out of knowing just a tiny bit more than I did before the day.

As a tester, I've learned to think that my job is to get up to speed quickly, and be brave about addressing stuff I don't know - to learn, to change what others know. Ignorance is important, it helps me work with the way a new user feels, but it is also temporary. I need to pay attention to to it before I lose it. And I need mechanisms to get closer to it again and again.

When facing a new application to explore, I feel the tingle of fear of me not being good enough for that particular application or domain. I fear there's no feedback I could provide on top of what is already known and what people care for. But the fear isn't stopping me, it's driving me. It reminds me that when facing fear, I can do something, anything, to learn just a little more. If I choose to plan a lot but do a little, I know a little. There must be a balance that ties my considerations into the actual doing of testing. I know that if I don't start testing while clueless, the time is ticking away and I'm not providing anything. I'm not learning or contributing. And those two tend to go hand in hand.

When faced with something we don't know, we can step away and say we need more info before we start. Or we can plunge in and accept that trial shows us something of what we know.

I'm realizing there is a particular skillset to test code I don't yet understand. I can feel I need to know much more, but still make progress. There's a similar skillset for programmers on working with code they don't yet understand - techniques and approaches that make learning fast while already doing the work.

Need to think of how I could explain the skillset better. If you have ideas, I'd love to talk. Ping me on skype: maaret_pyhajarvi if you feel like contributing on this.

Exploratory Testing an API

This week Thursday, I'm running a workshop at Booster Conference on Exploratory Testing an API. I decided to go for ApprovalTests as the test target because it's something I've been meaning to learn, and what is a better way to learn than to test. Also, having the creator close by seemed like it could be an advantage.

Before my prep of me testing it, I knew there was extensive unit tests. ApprovalTests are tested with ApprovalTests, and a lot of them. So my main interest is not on the stuff that is already being tested, but on stuff that tends to slip through the cracks when unit testing.

With a bit of personal brainstorming, I came up with three approaches to focus on.

1. Usability and Consistency of the API and functionalities
2. Environment
3. Inputs and outputs

It's been quite a ride for preparations. 

First I noted cosmetic bugs - typos in the interface. Within 5 minutes, those were gone, fixed. I may still be snarky on the backwards compatibility for the poor users who rely on the mistyped but these were in the interfaces that are not intended for external users, regardless of being visible. 

Then I pointed out a specific difficulty for the users of the API. ApprovalTests uses the concept of Reporters, that get introduced with something of this format:

    [UseReporter(typeof(DiffReporter))]

And there's a lot of reporters! But they are all over the IDE-provided list, as they have no means of grouping them together. And honestly, the idea of a user going to check what is available in reporters in the open source project just seems a little more than most users I can imagine will do. Although I'm first to admit that I might be even more on the lazy side on this stuff. 

End result: change request to rename all reporters to start with Report. And while at it, clarifying the names otherwise too. Some of the reporters have the purpose of running silently with the builds, while others pop up the best tools for analysis. 

I built up a nice list of purposes that the Approvals and Reporters serve, that will make a great foundation for further exploration with my workshop participant. And mapping those out through learning about the consistency (and inconsistency) might be helpful as documentation also later on, so I'll share that later. 

I concluded my prep with a research on inputs and outputs in the unit tests. The innocent request of "please run them" revealed that they had not been run with the last change and had tests breaking. Software & tests got fixed - and I got my confirmation that my hunch on environments being still troublesome is worth going for with line breaks in the files. We sampled different types of tests, and found groups of tests that had been accidentally excluded from the solution. Added some of them back too. 

I'm going to have so much fun with the people at the workshop revealing problems with this. The best of all of it: I don't need to waste my time on trivialities of simple bugs, because there's been a significant effort into the unit tests. They are pretty impressive, but showing those isn't what this is about: it's about learning things you don't learn with the unit tester glasses: flaws of your design logic, inconsiderations of your environment and things that just slipped through the programmer's eyes. 

Semi--automated tests, with an advanced version

Remembering back a few jobs ago, I was working with a great team of testers and we were trying to figure out automation. We put together weekly retreats on the other side of the company premises to find time away from the regular work and interruptions, working on adding incremental value through automation to the testing we were doing.

Back then, one of the leaders from test automation perspective introduced us a concept of semi-automated tests. There's things that are easy to have the computer do, and things that are harder to have the computer do. Tests that would take us to the point where human intervention was required and then just pop up a message allowing you to do your bit after all the leading into -steps automated was useful. We really needed something like that back then: a reminder that with "test automation", it's not about automating all things testing but some things testing - any that is useful.

Today I remembered this experience as I was exploring ApprovalTests with Llewellyn Falco (the main developer of this open source project). He was showing me a particular group of test, using fancy words like iExecutableQuery and at first, I was somewhat disengaged. Hard words of stuff that don't map out in my mind. He run the first test, explaining what was going on and I started connecting pieces. With third and different test, I realized the usefulness of what he was doing.

He had unit tests running on 3rd party software, and I was thinking these cannot exist, making me more disengaged than I should have been. The idea on how the tests were set up were interesting and useful.

His test would create a call to the 3rd party app (diff tools in this particular case) and save it into a file and launch that 3rd party app.  This would only pop up on failure. If the call had remained the same, he would only verify the call, but on1st time and later on failure he needed to see also that the 3rd party app did what was expected.

This was a much more advanced way of doing the semi-automated tests I found useful already a decade ago. This turned the semi-automated while testing once into automated for regression purposes. Surely it does not test "the real thing". But the abstraction it tests feels useful.

With all the tests I've been seeing, why haven't I seen more of this before? Have you?

Products as scrapbooks and modeling your way out

I spent a bit of time with my team's designer to help model a particularly complicated area of features. I knew from having tested it that it was not good, but the discussion and our joint efforts into making it better made me realize more than what I knew from past testing of it.

As I was listing concepts and features, and categorizing them while introducing them, patterns started to emerge. The assignment we were working on was to add one more feature to a complicated area. A feature described to us as "just add this dialog" made us talk about all the work we do to avoid building products like scrapbooks, and how hard it is sometimes to go beyond the obvious request.

With each concept we listed, a pattern started to emerge and we started scribbling on paper. At first the user is handling a massive amount of data by default, then filters some of it out. But also adds some more while filtering. And then again there's selections to add more. And again filter more. A lot more. We calculated 7 different scoping actions in a seemingly random order, and realized it was no wonder we had hard time following through the area.

From the first shape, it became obvious that this was not a good, clear and simple model for the user. So we draw concept shapes that would be clearer. We could start wide and consistently narrow down until we're where we want to be. Or we could start really narrow, and carefully widen up to be only at most where we end up wanting to be.

Drawing silly pictures comes almost instinctively from modeling. The pictures help us work out which of the straightforward routes we can get our design into, but also, they generated a lot of ideas for me on how to fool the current system to reveal complicated bugs.

Scrapbook of a product is a bug. But it's a bug that won't get fixed in an hour. 

Video: Styles of Pair Testing

After months of procrastinating how hard making videos is, I did one! Very proud of myself, and wanted to share the end result with you.

I already have ideas on how to make this better and how to learn new stuff on making videos. Now that the first step is done, it will be fun to work on an improved version. 

From identity to skill sets

A little over a year ago, I had a discussion on twitter that I look back to realizing I've made yet another 180 degree turn on my perceptions. I had a discussion with my co-creator for the European Testing Conference, Adi Bolboaca, a software craftsman on the topic of "testers are developers too". I remember very specifically responding in twitter and in following face to face discussions that for me being a tester is my identity. It tells me where I came from. It tells me what I'm good at. And it tells me how I'm special, after all the years of hard work on learning to become better at it every day - a job that never ends though.

Then various things happened. I started reading more about mindsets and went back to listen to the brilliant talk by Linda Rising that we also invited for European Testing Conference. I started to realize that what I really want to be about is learning, not testing. I've always considered testing to be learning, and that my focus on interests has been from value and business and systems, not the details of the code.

But when you've been learning every day for 20 years, limiting your learning becomes an idea that is no longer a necessity. As a new tester, I really needed all of my energy in learning about how to model the value, how to identify bugs and how to put the best of me together for any single day to produce useful results. As a seasoned tester, some things I've practiced atrophy, but others are almost muscle memory, things I have to think hard to even explain. And I have room for new skills areas.

This all leads into a discussion with a friend on identity vs. skill sets. Think of firemen. Being a fireman could be an identity. In the past, there was a bigger demand for firemen, but things have changed. There's early detection systems, sprinkler systems and the sort. Firemen wait to do the thing they exist for. There's even firemen who say they hope that there would be more fires, so that there would be more to do. More within that specific skill set.

When your entire identity is wrapped around a certain skill set, you want the need of that skill set to exist, whether is good or bad. If you expand your skill sets and find ways to be useful in a bigger scale, you're no longer dependent on your specific skill set being in demand.

Sounds a lot like what I've been going through as a tester. From identity to expanded skill sets. I'm still a brilliant tester. I'm also accepting that I'm just as good product manager, project manager and agile coach. And becoming just as good a programmer. One day at a time, learning every day, like before.