Tuesday, August 15, 2017

Dare to be the change you want to see

"Thank you for not having the steering group preparation meeting", he carefully said after the 1st steering group meeting after the holidays. I probably looked puzzled, as for me it was obvious and part of what I had signed up for. I wasn't about to turn into a project manager in an awesome place that has no scrum masters and usually also no project managers. I'm a hands-on tester. But when the previous project manager stepped down and I saw a need for people to meet weekly to exchange management-level news (to leave teams alone unless they pulled the info in), there was no other option than promising to hold the space for the steering group to happen.

Let me go back a little in time. I joined a year ago, and we had no project manager. We had teams of software engineers and quality engineers, and as with new teams, we were finding our way with the guidance of self-organizing. Many of us were seniors, and we got the hang of it.

Meanwhile while we were stumbling to form as individual teams and establish cross-team relations across two sites, someone got worried enough to "escalate". And escalation brought in a project manager.

The project manager visibly did two things. He set up a steering group meeting, where I ended up as a member ("just a tester, but none of us is *just* anything these days"). And he set up a cross-team slot. He was probably trying to just create forums, but they felt more of ceremonies. The cross-team session was a ceremony of reporting to him, as much as he tried to avoid it. And the steering group was a ceremony of reporting cleanly to the management, as it was always preceded with a prep meeting as long as the actual meeting, but only 3 out of 8 people present.

As the project manager left for other assignments, teams abandoned the cross-team slot and started more active 1:1's as they sensed the need. Out of 10 of us, only 2 strongly stated over time the slots were not a good use of time, yet everyone was keen to give them up. Others just came, because they were invited.

And similarly, the steering group meetings turned into actual discussions, creating feeling of mutual support and sharing without the pre-meeting. I stated I was there to hold the space, and that's what I do. I start discussions, and end them if they don't fit the idea of what this meeting is about as per our mutual understanding.

But for the last 6 months, I did not like the way we did things. Yet I too, while expressing my feelings every now and then, went with the motions. I only changed when the environment changed.

All of this reminds me to be more brave: dare the be the change you want to see. Experiment with fixes. And not only when the people leave, as they were never the real bottleneck. It was always in our head. My head amongst the others. 

Friday, August 11, 2017

A Serendipitous Acquintance

We met online. Skype to be precise. Just a random person I did not know, submitting to our conference. And we talk to everyone on Skype.

As the call started, we had our cameras on like we always do to begin a call, to create a contact between people instead of feeling like a phonemail of strangers. And as his camera was turned on, we were in for a surprise. It was clear we were about to talk to a teenage boy who had just submitted to a testing conference.

We talked for 15 minutes, like with everyone. It was clear that based on his talk proposal, we would not be selecting him. But listening to him was different. His thoughts were clear and articulated. He was excited about learning. He was frustrated about people dismissing him - he had submitted to tens of conferences, and we were the second he would hear back from. We asked him questions, poked his experience and message and got inspired. Inspired enough to suggest that regardless of what would be our decision on this conference, I would be delighted if we would accept my help as a speaker mentor, and I could help him hone his message further. He had delivered a keynote in Romanian Testing Conference through local connections, and was driven for more. 15 minutes was enough to realize that Harry Girlea is awesome.

When later met him for going through his talk and talked for 40 minutes, the first impression strengthened. This 13-year old is more articulate than many adults. When he told me stories of how wonderful he felt testing with professional games testers in game realms, I could hear he was proud of his learnings. And when he coined why he loves testing as "As tester, things are similar but are never the same“, all I could do is say that with my extra 30 years of experience, I feel the same.

It became clear that he wanted to be a bigger part of it, speaking in conferences and learning more on testing.

We improved his talk proposal, and he submits again. For European Testing Conference, we have not made our choice yet. But I hope we are not the only ones seriously considering him.

The kids of today learn fast. Us adults have lot to learn from them.


Thursday, August 10, 2017

We don't test manually at all

We sat in a room, the 7 of us. It was a team interview for a new candidate and we were going though usual moves I already knew from doing so many of these in the last few weeks. And as part of the moves, we asked the programmer candidate on how they test their code.

It wasn't the candidate that surprised me, but one of my own team's developers, who stated:
"We don't test manually at all".

My mind was racing with thoughts of wonder. What the hell was I doing if not testing? How could anyone think that whoever was figuring out scenarios, very manually wasn't doing manual testing at all? Where has my team's education failed this much that any of them could even think that, let alone say it out loud?

At the team room, I initiated a discussion on the remark to learn the meaning of it.

What I was doing wasn't included (I do a lot of exploratory testing and find problems) because I refuse to test each build the same way.

What the developers were doing wasn't included because manual testing targeted for a change is just part of good programming.

Figuring out scenarios to automate and trying them out seeing if they work when turned into code and debugging tests for failing wrong (or not failing right) wasn't included because it is part of test automation.

So I asked what then was this infamous manual testing that we did not do? It is the part of testing that they consider boring and wouldn't label intellectual work at all. The rote. The regression testing done by repeating things mindlessly without even considering what has changed, because there could be things that just magically broke.

We test manually, plenty. We are no longer mindless about it. So I guess that's what it really means. Not manual, but brain-engaged.

I can just make sure that people who matter in recruiting make sure someone is particularly well brain-engaged when joining the teams. That someone sometimes is not the tester who specializes in automation. 

Sunday, August 6, 2017

Community over Technology in Open-Source

So, you have created an open source tool. Great, congratulations. I'm still planning on adding mine to the pile. But let me say something I wonder if techie people understand: *your tool is not the only tool*. And as a user of these tools, I'm feeling the weight of trying to select one that I want to even look at. I've looked at many, to find myself disappointed in something I find relevant to be missing. And yes, with an open source tool, I've heard the usual mantra that I can just change it. But forking my own version to have faster control over it creates a merge hell, so you better make sure you let things in the main repo fast enough and not leave them hanging in the pull requests queue.

There's loads of awesome open source tools, but the user challenge is no longer so much about finding some, but finding one that is worth investing your time on. Having something die out of your tool stack and replace it creates distraction. So most of us go for tools with good communities. Tech matters less than the community.

With European Testing Conference Call for Collaborations, many people who have created a tool propose a talk on that tool. A quick and simple search to github tells me there are 1,004,708 repository results for "testing" and over the two years of these 15-minute calls, I've got a small insight into maybe a hundred people creating and maintaining their own tools, wanting to share their awesomeness.

Last year we defined what kind of things we might consider, saying that it has to be either an insightful idea that anyone could relatively easily bring into their own testing frameworks or something that an open source tool supports. This year, I'm learning to add more requirements to the latter.

The open source tool is not of support if it does not have a proper community. There needs to be other users and active core group answering questions and improving the experience of getting introduced into the tool. But also, it matters now more to me how the core group deals with their project.

If I see pull requests that have been in the queue for a long time, it hints to me that the community contributions are not seen as a priority.

Building and supporting a community takes an effort. I see some projects understand that and emphasize a community that welcomes contributions, while other treat the community more as outsiders.

I'm grateful for the 15 minutes of insight into tools I would never given even that time unless I had the main contributor as my guide in the call, wanting to share on their project at one of the limited spots of the conference. For a conference, any conference not just European Testing Conference, the organizers are always working against the idea of a limited budget of spaces. and that gives an indication that out of a typical 10-20 slots in a conference, not all of these tools will ever be presented.

What are the tools that are worth the spots then? Selenium / Protractor are clearly choices of the community already. Others need to have a common problem solved in a particularly insightful way and life ahead that the community can believe in.

Community is more relevant. 

Wednesday, July 26, 2017

Making a conference talk practical (for me)

I've again had the annual pleasure of talking *amazing* people from around the world, both seasoned speakers and new, and get inspired by their stories. It pains me to know that a small percentage of all the awesome people can be selected, and that our specific selection criteria of practical relevance makes it even harder for many people. Simultaneously, I'm delighted to realize that while I may say no on behalf of European Testing Conference 2018, I could help those people make their proposals stronger for other conferences.

Today, however, I wanted to write down my thoughts on what is a talk that is practical, to me.

I've had the pleasure of listening to lots of presenters on lots of topics, and over time, I've started recognizing patterns. There's one typical talk type, usually around themes such as security testing, performance testing, test automation and shifting work left that I've categorized into a talk about importance of a thing. This is one where the core message is selling an idea: "bringing testers into the whole lifecycle in agile is important". "Test automation is hard and important". "Performance testing continuously is important".

I get this. Important. But I know this. My question is, if it is important, what do I do. So here are stories I'd rather hear that make this practical.

1) I sort of knew X was important,  but we did not do it. We failed this way. And after we failed, we learned. This is specifically what we learned and how we approached solving the problem. So, learn from my mistakes and make your own.

2) I'm an expert in X, and you may be an expert or a novice. But if you try doing X, you could try doing this specific thing in X in this way, because I find that it has been helpful.  This answers your questions of how after quickly introducing what and enables you to leave this conference knowing what you can do, not just that you will need to do something.

3) Here's a concept I run into. Here's how I applied it in my project, and here's what changed. Here's some other concepts we're thinking of trying out next.

Assume important or necessary is a prerequisite. What would you say in your talk then? 

Tuesday, July 25, 2017

Greedy Speakers are the Death of conferences

Conference organizing is hard work. Lots of hours. Stress over risks. '

But it's also great and amazing. Bringing people together to learn and network makes me feel like I'm making a small difference in the world.

And for me in 2017 it has also been losing some tens of thousands of euros on organizing a conference that was totally worth the investment, regardless. 

I organize conferences idealistically. My ideology is two-fold: 
  1. I want to change the world of conferences so that money isn't blocking the voices from getting to stage. 
  2. I want to raise money to do more good by supporting speakers for conferences that don't pay the speakers.
I also organize without raising money, and I've made organizing without any money a form of art for myself in the last 15 years. But that's local meetups, and I do a lot of them. I have four coming up in the next month. 

I'm tired of conferences, where majority of speakers are vendors, because they have an interest in paying for the speaking. I want to hear from practitioners, and sometimes consultants if they keep the selling to a minimum. Bottom line is that all speakers have something to sell anyway, their personal brand if nothing else.

I would like to believe that conference going is not a zero sum game, where choosing one is away from the other. People need places where to share, and there's a lot of people to listen to various perspectives. But I also feel that people need to make choices in which conference they go to, with their limited budget. Cheap conferences are great, it enables your organization to send more people out. But conferences are cheap if the money comes elsewhere. And this elsewhere is sponsors and speakers as sponsors, paying their own way to work for the conference.

Being able to afford the cost is a privilege not everyone has. I would like to see that change and thus support the idea of Not Paying to Speak at Conferences. And this means travel + hotel paid. No fancy expense accounts, not even paying for the hours of work to put into the talk you're delivering, but taking away the direct cost.

Conferences that don't pay but yet seek non-local voices have made a choice of asking their speakers to sponsor them and/or the audience (if truly low-cost). If they're explicit about it, fine.

The could choose to seek local voices so that travel and expenses are not relevant. But they want to serve the local community with people's voices that travel, and people (who can afford the travel in the first place) have the freedom to make that choice. The local community never has a chance of hearing from someone who won't travel. They haven't heard that voice before, and still won't. And the ones who can't afford (I was one!) can be proud and choose to remain local, rather than go begging for special treatment. Some people don't mind asking.

I wrote all of this to comment on a tweet:
I've been told that travel expenses for the speakers and in particular paying the speakers is the death of commercial conferences too. They need to pay the organizers salaries. It's a choice of ticket pricing and who gets paid first. Local conferences don't die for travel expenses, if they work with local speakers. But they tend to like to reach out to "names" that could bring news from elsewhere to this local community.

The assumption is that a higher ticket price is death of a conference. It's based on the idea that people don't value (with money) the training they're receiving. Perhaps that is where the change needs to be - expecting free meals.

I can wholeheartedly support this: 
Do that even if you're not a first time speaker. There's nothing wrong with building your local community through sharing. It might give you more than the international arenas.

Greedy speakers are not the death of conferences. There's conferences with hugely expensive professional speakers that cost loads, and still fill up. If anything is death of conferences, it's the idea that people are so used to getting conferences free that they don't pay what the real cost of organizing a *training* oriented conference is.

Luckily we have open spaces where everyone is equal and pays. We're all speakers, all participants. Conferring can happen without allocated speakers, as people meet.

Saturday, July 22, 2017

A Team Member with Testing Emphasis

Browsing Twitter, I came across a thought-provoking tweet:
Liz Keogh is amazing in more ways that I can start explaining, and in my book she is a programmer who is decent (good even) at testing. And she understands there's still more - the blind spots she needs someone else for. Someone else who thinks deeply and inquisitively. Someone else who explores without the blind spots she has developed while creating the code to work the way it's supposed to.

Liz is what I would call a "team member with programming emphasis". When asked to identify herself, no matter how much she tests, she will identify as a programmer. But she is also a tester. And many other things.

Personally I've identified as a "team member with a testing emphasis". That has been a long growth from understanding why would someone like Ken Schwaber years and years ago suggest to my manager that I - who want to be a tester - should be fired. Over thinking about it, I've come to the conclusion that this is one of the ways to emphasize two things:

  1. We are all developers - programmers, testers and many others 
  2. We need to work also outside the focus silos when necessary or beneficial
For years, I did not care so much for programming so I found a way to call myself that I was more comfortable with than a "developer" which still is loaded heavily on programming. I became a self-appointed team member with a testing emphasis.

This works still, as I've grown more outside my tester box and taken on programmer tasks. It means that while I code (even extensively, even production code not just test code) the tester in me never leaves. Just like the programmer in Liz never leaves. 

Liz can be a brilliant tester she is in addition. And I can be a brilliant programmer I intend to be. And yet she can still be the programmer, and I can still be the tester. 20+ years of learning allows growth outside the boxes.  But it's still good to remember how we got here. 

If software industry doubles every five years, half of us have less than five years of experience. Perhaps it makes sense to learn a good foundation, starting from different angles and build on it. 

Individuals make teams. And teams are stronger with diversity of skills and viewpoints.