Wednesday, March 30, 2016

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

Tuesday, March 29, 2016

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



Thursday, March 24, 2016

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

Wednesday, March 23, 2016

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. 

Friday, March 18, 2016

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.   

Wednesday, March 16, 2016

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