Sunday, November 12, 2017

Why Do I Go to Conferences?

I find myself asking this question more often these days: why do I go to conferences? And in particular, why do I speak at conferences? And my answers vary, as I really don't know.

This week I spoke at Oredev, a developer conference, and felt totally disconnected and invisible. I did not talk to any new people. And new people did not talk to me. At first, I was quick to blame it on a tester identity, but it isn't that as I also identify as a polyglot programmer. I just did not have the chances for a discussion without first being active on it and even when I did, topics changed from tech to life. I listened to many sessions, some really great and others not so much, and came back with a decision on cutting down on conferences.

I used to get learning from conferences, but now my "being aware of techniques" learning quota feels full. Knowing of AWS, SAM, lambdas and step functions takes me somewhere, but the real application of those ideas takes me a lot further. And conferencing is threatening my time for practice.

My situation with this is not quite the usual one. I've been collecting the number of talks I do per year, and I already decided to cut down a year ago. Yet, looking at where I ended up isn't exactly showing the commitment: I have 27 sessions in 2017. 30 each year for 2016 and 2015. At this point of my life, talks emerge from my need of organizing my thoughts and driving my learning, and there are smaller time investments that would give me the same value.

So I wonder if people are finding pieces of joy, enlightenment, thoughts from whatever I end up sharing. Maybe that is worth the investment? There was one women I can thank for from Oredev that really made my day, coming to say one thing to me after my talk: "Thank you for speaking. It is so wonderful seeing women in tech conference stages." Most people say nothing, and pondering on this made me realize one of my speaking motivations is that that I crave for acceptance and acknowledgement.

Thinking a little further, I was thinking of the test conferences I find the most valuable for me: TestBashes. I've come back from those with new colleagues in the community to learn with, even friends. People I get to meet elsewhere, who bring so much joy into my life. But in particular, I remembered there is one accomplishment from each test bash that fills my heart with joy: I came back with a connection that created a new speaker.

Thank you Gita Malinovska, Bhagya Perera and Kate Paulk for making me feel like I had a role to play in the world seeing how awesome speakers you are. Gita and Bhagya I mentored in speaking after TestBashes brought us together, and they never really needed me but I needed them. Kate blew my mind with the discussions we had in TestBash Philly a year ago, when she seemed shy to take the stage, and I feel so proud seeing she delivered awesome in TestBash Philly this year.

There's a lot more names that I could drop that make me feel like I've served a purpose. But these three remind me that without going to conferences, our paths might not have crossed.

So I go to conferences for:

  • Collecting ideas that I need time to turn to actions at work
  • Making friends and maintaining our relationship
  • Encouraging awesome people to be the inspiration on stage they are off stage
I speak to make it cheaper to go. I speak in hope of recognition. I speak in hope of connection, as I have hard time initiating discussions. But most of all, I speak to sort out my own thoughts. 

What are your reasons? 



Monday, November 6, 2017

Making Everyone a Leader

A year ago, some people were fitting the "Leader" title for me in the context of the testing community, and I felt strongly about rejecting it. We have enough of self-appointed leaders, calling for followers and I felt - still feel - that we need to stop following and start finding our own paths, and just share enthusiastically.

Today, someone was fitting the "Leader" title on me in the context of work and our No Product Owner experiment. I was just as quick rejecting it, but this time realizing even more strongly that I believe that for good self-organizing teams, everyone needs to become a leader instead of one self-appointed or group-selected leader.

I believe our No Product Owner experiment will show its best sides if I manage to avoid being appointed the "leader". There will be things where people choose to follow me, like the idea of experimenting with something we thought is out of our reach, meeting people who "never have time" yet find time in three days when we ask, imagining the possible. But each one in my team will lead us on different things, I follow with joy. Today I followed one of my developers on them leading the way on solving customer problems and they could use my contribution. I followed another one of my developers in supporting him when he imagined a feature that we thought wasn't wanted that turned out to be the "dream we did not dare to hope for". I followed my two tester colleagues in solving puzzles around automation where recognizing an element (no Selenium involved) wasn't straightforward, and working together was beneficial.

Everyone has room to be a leader. We don't have to choose one. We can let one emerge for different themes.

And what makes a leader, anyway? It's the followers. I choose to follow leaders in training, enthusiastically. It does wonders to how my group works. Maybe it would do wonders on communities too? 

Thursday, November 2, 2017

Trawling for feedback

As a team without a product owner, we needed to figure out what is our idea of what someone with product management specialization could bring us? And we hit the discussion around the mysterious "customer voice".

At first we realized that having someone allocated as a "customer voice" with "decision power" (a product owner), isn't an automatic ticket for the team to hear any of that. So we ended up identifying a significant chunk of work the team isn't doing, would love done better and goes under the theme of trawling for feedback.

With customers in the millions, there's the feedback we get without them saying anything through monitoring. Knowing when they have troubles, knowing when they use features we think they must be using, all of that is primarily a privacy but then a technical challenge. Just the idea of going for no product owner made us amp up our ability to see without invading privacy. It was necessary before, but now it was our decision to include the tools that improve our ability to help our customers. Mental state does wonders, it seems.

Then there's the feedback that requires time and effort. Reading emails and replying them. Meeting people on specific topics and meeting people on general topic for serendipitous feedback to emerge. There's the skill of recognizing what feedback is critical. Being available for feedback, and identifying what of it is the core, not the noise. And passing the core to people who can do something about it - the team.

We realized there is a fascinating aspect of timing to this feedback trawling. Think of is as comparison to trawling for fish.

If you get a lot of fish without the proper storing and processing facilities, it will go bad and get wasted.

Feedback is similar - it is at its maximum power when fresh. That extra piece of motivation when you see the real person behind the feedback gets lost when we store the feedback for an appropriate time to act on it.

Having to deal with lots of fish at once creates costs without adding much value. 

While writing down a thing is a small cost, going through all the things we have written down, telling people of their status, and our ideas of their importance isn't a small cost anymore.

If you pass a fish from the fisherman to the second person in the chain, it is not as fresh anymore. 

First-hand delivered feedback to the developers just is different. It's more likely to be acted on the right way, with added innovation.







Tuesday, October 31, 2017

Starting a No Product Owner Experiment

In the usual two week cadence, our product owner showed up our team room looking exhausted. We were glad to hear it wasn't the fact that he came to do planning with us, but that the early hit of winter and snow and related tire change left him feeling beat up.

Our Product Owner usually sends us a ton of emails (forwarded bits he wanted us to react on), shows up regularly every two weeks, and whenever we ping him in between. The is not a part of our team and does not sit with us. He used to, but in an experiment to change the way the team communicated, was moved further away to make a huge positive impact. The developers who used to report to him changed reporting to the team, and we have not been the the same since.

We started going through the usual motions of how my team plans, listing things that we knew that needed addressing. I was making my own notes on a computer without sharing a screen, hoping someone else would step up and write stuff on our whiteboard like we always do, without success. The list was starting to get long, and yet another thing came up. The product owner spoke up: "I want you to prioritize this", cutting the discussion leading to understanding with the power voice. I could feel the energy sinking.

So I stepped in.

"Hey, this would seem like the time to introduce this thing we've been talking about for the last month or so with the product owner. We've agreed to try out an experiment with no product owner."

It wasn't the first time my team heard of it. It was definitely not the first time the product owner heard of it, as it was a stretch we had agreed on together.

I summarized the change in the context of this meeting that the team now has the control (and responsibility) of priority calls. We did not have one person who "wants us to do this", but we had a team that was set out to be customer obsessed and care enough to understand what would be our real options and the right choices.

With an agreement to agree on what PO used to do and what it really means to not have a product owner but a PMS (Product Management Specialist - the person is still around for helping), we continued planning with high energy.

There was a little bit of rebellion in the air. But everyone discussed things together, heard each other out and ended up with exactly the thing our ex-PO wanted us to prioritize - our route, feeling more energized.

The outcome of the rebellious planning seemed better than what I had come to expect. There was no passivity around "officially delivered items", where the real outcome of what would happen would end up very different. We talked enthusiastically about improving some of our core automations, agreed on pairs that could contribute on things, and prioritized our short term backlog.

My team does biweekly planning, but it is more of a biweekly backlog creation. And out of that list, we just work on items more in a kanban style.

My first lesson: it's not about what the change is, it's about changing. Trying something new out is energizing. Our real challenges of understanding what "No PO for three months" means are still ahead of us. 

Sunday, October 29, 2017

Yes, I am a manual tester and ...

In my team, we have two testers and our interests and contributions couldn't be more more different. While I like to refer to myself as an exploratory tester, most people around me think of me as a manual tester. I try very hard not to correct their terminology, but I often use the improv Yes and... rule to add to what others say.

Yes, I'm a manual tester and I create disposable automation.
Yes, I'm a manual tester and we just addressed some major issues that would have been next to impossible to spot without thinking hard around the product.
Yes, I'm a manual tester and while my hands are on the keyboard, the software as my external imagination speaks to me.

The practice of avoiding correcting people's established terminology is not "help to cheapen and demean the craft"(1). That practice is focusing on what matters, and what matters is us collaborating, creating awesome stuff.

I might not have always liked the terms manual and automated testing, but I can live with with established vocabulary. Instead of changing the vocabulary, I prefer changing people's perceptions. And the people who matter are not random people on twitter, but the ones I work with, create with, every office day.

Looking at the two testers in my team, I can very easily see why I'm the "manual tester" - I think best with hands on keyboard, using the product as my external imagination. I prefer to bias myself to experiencing much of the testing as the users would - using the product. Even when I test with code, I prefer to bias myself on using the APIs as users would. The mechanism of running the test - manual - leaves me time and focus to think well with the product giving me hints on where to go next.

Similarly, I can easily see why the other test is automated tester. Their focus is on getting a program, unattended to run the tests. They too think hard (often with less of an external imagination due to focusing on coding around a problem) while creating the script to run, and are all the time, with each test, forced to focus on the details. So their tool and approach of choice biases them to experience the product as a program can. The mechanism of running the test - automated, eventually - leaves them time to do more automated tests. Or rather, try to figure out why the ones created are failing, again.

Together, we're awesome. If we were more inclined to move between the roles of manual and automated tester, we'd be more awesome individually. But as it stands now, we have plenty of bugs to find that automation couldn't find: they are about aiming for the wrong scope. The person doing automation could find them, if all their energy wasn't going into the details of how hard automating a Windows GUI application can be. So right now we're lucky to have two people, with different focuses.

I wrote this inspired by this - Reference (1):

So here. I just cheapened and demeaned the craft. Except I didn't. The word policing is getting old. The next generation of manual testers can just show how awesome we are, giving up the chains of test cases and thinking well with our hands on they keyboard and our brains activated.

Imagine what would work be like if we stopped policing the word choices and approached communication with a yes and -attitude.

Wednesday, October 25, 2017

Your stack isn't as full as mine

Recently, I've seen increasing amount of discussion on "full-stack engineer" coming my way. Just as it was important to me at some point to be identifying clearly as a "tester", I have now colleagues who find similar passionate meaning around the "full-stack engineer".

Typically, one of these full-stack engineers works on both front-end and back-end. So on the web stack, typically they cover the two ends.

An engineer wouldn't be properly full-stack if the stack did not include both dev and ops. So being DevOps is clearly a part of it. 

Some of these full-stack engineers take particular pride in including testing (as artifact creation) into their stack of skills. They can deal with testing so that they are not dependent on testers, and more importantly, so that they feel safer making changes throughout the stack that is getting too big to keep in mind at once.

The first place where the fullness of the stack starts really breaking is when we face the customer. Can a full-stack engineer expect to get all their requirements cleanly sliced, or should they also have capabilities on understanding, collecting and prioritizing the customer's explicit and implicit wishes? This is usually where a full-stack developer throws responsibility over to a complete product owner, who magically has the right answers. A Complete Product Owner is the customer-side match for the Full-Stack Developer.

And for me, the idea of being Full-Stack Developer breaks in another way too. The web stack isn't always the full stack. For me it most definitely is less than half of the stack. The system created with the web stack is just as dependent on the system created on C++/Python -mix than the other way around.

So frankly, my dear full-stackers. Your stack isn't full enough yet. Time to move towards polyglot. Onwards, to the unicorn state.

*said on a day I had to look at C/C++, Python, Groovy, JavaScript/Angular, Java, CSS for work, and C# for hobbies. I feel slightly exhausted but certain it isn't going to change for anything but wider.

Saturday, October 21, 2017

How is European Testing Conference Different?

One sunny afternoon in San Diego over three years ago, I took a call with Adi Bolboaca. That call has since it happened defined a lot of what my "hobbies" are since (conference organizing) but also set an example of how I deal with things in general. From idea to schedule that call was all it took. We decided to start a conference.

The Conference was named European Testing Conference to reflect its vision: we were building the go-to testing conference in Europe and we'd take on the challenge of having the conference travel. In the three edition so far, we work with Bucharest (Romania), Helsinki (Finland) and Amsterdam (Netherlands).

As the Amsterdam Edition is well on its way to take place in February 19-20th 2018, someone asked how we position ourselves - how is European Testing Conference different?

Testing, not testers

Our organizers are an equal mix of people who identify as tester and programmers. What brings us together is the interest to testing. The conference looks at testing as different roles do it and seeks to emphasize the collaboration of different perspectives in making awesome products. We like to think of testing as Elisabeth Hendrickson said it: it is too important to be left just for the specialized testers. Our abilities to solve the puzzles around feedback make a difference for quality, speed of delivery and long-term satisfaction for those of us who build the software.

Practical focus

We seek to make space for sessions that are practical, meaning they are more on the what and how as opposed to why, and they are more on the patterns and practices. We start with the idea that testing is important and necessary, and seek to raise the bar in how testing is done.

Enabling peer learning

We know that best sessions in conferences with regards to learning often happen in the hallway track where people are in control of the discussions they engage in. Many conferences formalize hallway track to happen on the side. We formalize hallway track sessions to be a part of the program so that we increase the chances of everyone going home with a great, actionable learning from peers.

Peer learning happens with interactive sessions that have just enough structure so that you don't have to be a superb networker, you can just go with the flow. As a matter of fact, we don't give you choice of passively sitting listening to a talk when you could learn from your peers in an interactive format, so these session are always conference wide.

The do three different kinds of interactive sessions:

  • Speed Meet makes you go through people while giving the structure to ensure that it's not the usual chit chat of me introducing myself, it is learner driven what the introducer gets to share. Each participant creates a mind map, and the person you get to know will drive the discussion based on what they select on your map. 
  • Lean Coffee is a a chance of discussing testing topics of the whole group's choice. Regardless of its name, it is more about discussions and less about coffee. We invite our speakers to facilitate tables of discussions, so this is also your chance of digging in deeper to any of the topics close to heart of our speakers. 
  • Open Space makes everyone a speaker. A good way to prepare for this is to think about what kinds of topics you'd love to discuss or what knowledge you'd like to share. You get to propose sessions, and they could also be on topics you know little of but want to learn more about. 

Lean Coffee and Open Space are regular sessions in conferences, but we have not seen anyone else do them as part of the day program, whole conference wide. You will meet people in this conference, not just listen to the speakers we selected.

Schedule by session types

Interactive sessions have no talk sessions to listen to passively at the same time. Similarly, when talk sessions take place, we have four of them scheduled on tracks. We also have in-conference workshops, and again when it's time to workshop, there's no talk sessions available simultaneously. This is to encourage a mix of ways of learning. It's hard enough to select which topic to go for, and if the session type is also a variable, it just gets harder to get the learning mix right.

Speakers selected on speaking their stories

All speakers we have selected have been through a collaborative selection process. This means that we did not select them based on what they wrote and promised they could talk on, we had a chat with each and every speaker and know how they speak. We're hyped about the contents they have to share as part of our great program.

Some of the talks are not ones the speakers submitted. When collaborating with a speaker, sometimes you learn that they have something great to share that they did not themselves realize they should have submitted.

Track speakers are keynote quality

We take pride in treating our speakers fair, meaning we guarantee them that they don't have to pay to speak but we compensate the direct costs of joining our conference. We go a bit further, sharing profits with the speakers. This means that the speakers are awesome. They are not traveling to speak with the vendor marketing budget to sell a tool or service, but are practitioners and great speakers.

Enabling paired sessions

Our program has sessions with two speakers, and when we select a session like that, we pay the expenses of both the speakers. While we strongly believe that a two person talk is not a talk where two people take turns on delivering a talk one could deliver, we actively identify lessons that require two people. We pair in software development, we should be able to pair with our talks too.

Organized by testing practitioners

Our big fancy team is a team of practitioners doing the conference as a hobby. We love learning together, creating together and making a great program of testing available together. We spend our days testing and programming. We know what the day to day challenges are and what we need to learn. Our practitioner background is a foundation for our ability to select the right contents.

Traveling around Europe

Europe is diverse area, and we travel around to connect with many local communities. It sometimes feels ambitious of us, as every year we have a new community to find and connect with to sell our tickets. Yet, going to places and taking awesome content to places is what builds as forward as a bigger community. 

We love other testing conferences

We don't believe that the field of testing conferences is full - there's so many people to reach and enable to join the learning in conferences. If your content and schedules are not right for you, we encourage you to look at the other. We love in particular conferences that enable speakers without commercial interest by paying their expenses and often give a shout out to TestBashes (all of them!), Agile Testing Days (both Germany and USA), and are delighted to be able to mention also Nordic Testing Days, Copenhagen Context and Romanian Testing Conference.