Wednesday, March 15, 2017

Don't pay to speak, get paid to speak

I strongly believe the world of tech conferences needs to change, and the change I call for is that whoever the conference organizers deem good enough to step on their podium to speak, should not have to pay to speak. And when I talk about paying to speak, I speak of expenses.

In case of paying for travel expenses, and encouraging the cheapest possible travel, there's a second step. When booking early, pay back early. Don't use your speakers as a bank and pay back after the conference.

I work towards changing these two.

Other people ask for more, and I would love to join them. They ask to be paid to speak. They ask for the time they put on preparing to be compensated. And since the work you do is not preparing the talk, it's becoming the person that gets on that stage, the speaking fees should be relevant.

In paying, a big injustice is when some people get paid differently than others. The injustice of it just gets bigger when conferences give replies like this on paying some but not others.
As a conference organizer, I want to share my perspective.

I set up a conference that:

  1. Pays travel expenses of the speakers. All the speakers.
  2. Profit shares with all the speakers. Keynotes get 5* what a 30-minute slot speaker gets. 
The second happens only if there is profit. And I work hard to make profit. In 2017, I failed. I made losses. 

If I would have committed early on to paying my speakers, I would have lost more than 20k that I lost now. This loss is insignificant as it is an investment into a great conference (and great it was!) and an investment in making things right in the world of speakers. But imagine if I had a thousand euros to pay to each of my speakers, I would be down 30k more. 

What I failed in was marketing. Getting people to learn about the conference. Yet, I feel that whoever came are the right people. 


To make marketing easier, famous names help. Some famous names are willing to risk it to not be paid for their time, and I'm very grateful for that. But others have a fixed price range, paid in advance. When as an organizer you want to invite one like that, you fill the other similar slots with people who are not the same: people who don't insist on being paid fairly. But lying about it is just stupid. The speakers talk. And should talk more in the future.

As an organizer, I rather leave out the superstars if the same fees principle is a problem for them. And honestly, it is a problem for many of our tech superstars. But things change with conferences only if we change them. One conference at a time. 

Meeting is not just a meeting

We're sitting in a status / coordination meeting, and I know I don't look particularly happy to be there. The meeting, scheduled at 3pm has been lurking on my mind the whole day and for the last hour before it, I recognize I have actively avoided doing anything I really should be doing. And what I really should be doing is deep thinking while testing. I feel there must be something wrong with me for not being able to start when my insides are seeing the inevitable interruption looming.

It's not just the inconvenient timing at the seeming end part of my day that has negative impacts on my focus. It's also the fact that I know the meeting is, in my perspective, useless and yet I'm forced there trying to mask most of my dislike. It drains my energy even further.

In the ten years of looking at agile in practice, one of my main lessons has been that planning the work is not the work. I can plan to write a hundred blog posts, and yet I have not written any of them except for a title. I can plan to test, yet the plan never survives the contact with the real software that whispers and lures me into some cool bugs and information we were completely unaware of while planning.

I love continuous planning, but that planning does not happen in workshops or meetings scheduled for planning. It happens as we are doing the work and learning. And sitting in a team room with insightful other software developers, any moment for planning is almost as good as any other. The unscheduled "meeting" over a whiteboard is less of an interruption than the one looming in my schedules.

I know how I feel, and I've spent a fair deal of time understanding those feelings. I know how to mask those feelings too, to appear obedient and, as a project manager put it, "approach things practically". But the real practice for me is aspiring to be better, and to accommodate people with different feelings around same tasks.

Planning is not doing the work. But it does create the same feeling of accomplishment. When you visualize the work, you start imagining the work is done. And if you happen to be a manager who sits through meetings day in and out, the disruptiveness of a meeting in schedule isn't as much as it is when you are doing the work.

I used to be a tester. Then I became too good to test, and took the role of a manager. I was still good, just paying attention to different things. But the big learning for me came when I realized that to have self-organized teams as we introduced agile a decade ago in the organization, I was a hindrance. My usefulness as a manager stopped the people from doing the work I was doing. Stepping down and announcing the test manager role gone and just teaching all the work I had been doing to teams was the best choice I've done.

And it made me a tester again. But this time around, I don't expect a manager to be there. I expect there's a little manager in every one of us, and the manager in others help me manage both the doer and the manager in me.

The two roles were different for me. And awareness of that keeps me wary of meetings.

Monday, March 13, 2017

A Mob Testing Experience

During my 6 months at the new job, I've managed to do Mob Testing a few times. Basically the idea is that whenever I sink into a new feature that needs exploring, I invite others to join me for the exploration for a limited time. I've been fascinated with the the perspectives and observations of the other testers I've had join me, but these always leave me wanting after the Mob Testing experiences I had at my earlier place of work. There not only testers joined (well,  there were no testers other than myself) but we did the tasks together with the whole team, having programmers join in.

There's a big difference on if you're mob testing amongst testers (or quality engineers as we call them) or if you're including your teams developers and ever product owners. And the big difference comes from having people who need to receive the feedback testing is providing sharing the work.

With 6 months approaching, I'm starting to see that my no-so-subtle hints on a regular basis are not taking adapting mob testing / programming further. But it became funny at a point I taught developers from another organization who started off with the practice, and only through their positive reports someone relevant enough to push people to try it took initiative. There's an infamous old saying of no one ever being a prophet on their own land, and that kept creeping up to my thoughts - I became part of furniture, "always been here" surprisingly quickly. And I don't push people to do things they don't opt in to.

But finally last week's Wednesday, while my own personal team did not opt in, the team next door did and invited me to join their experience. With two application developers, two test developers and two all-around test specialists, we took the time to mob for about 5 hours during the day.

The task we were working on was a performance testing task, and the application developers were not in their strong area. We worked on extending an existing piece of code to a specific purpose, and the idea of the task was available to start our session. There were a few particularly interesting dynamics.

When in disagreement, do the less likely one first

About half an hour into our mobbing, we had a disagreement on how we would approach the extending of the code. We just did not disagree what would  be the right thing to do as the next step. The two of us who were familiar with what the goal of what we were doing had one perspective. And another suggested doing things differently, in a way that in the moment felt it made little sense to us.

I realized that were were quickly going into discussion mode, convincing the other of what the right thing was - at a time we really knew the least. The other suggestion might not sound like the best idea, so we played a common rule to beginning mobs: "Do the less likely first, do both". Without continuing the discussion, we just adjusted the next step to be one that the other, in minority, felt strongly enough to voice.

And it turned out to be a good thing to do in a group. As it was done, the work unfolded in a way that did not leave us missing the other option.

Keep rotating

Between hours 2-3, two of the six mob participants needed to step out into another meeting. I was one of these two. For first two hours, we had rotated on a four minute timer and pushed the rule of having a designated navigator. As I came back from the meeting, the rotation had fallen off as the mob had found relevant bugs in performance and had two other people join in as lurkers on the side of the table, monitoring breaking services in more detail. The lurkers did not join the mob, but also the work got split so that the common thread started to hide.

Bringing back rotation brought back the group thread. Yet it was clear that the power dynamic had shifted. The more quiet ones were more quiet and we could use some work on dominating personalities.

But one things I loved to observe on the more quiet ones. They aced listening and it showed up as timely contributions when no one else knew where to head right now.

Oh Style

The group ended up on one computer with one IDE in the morning and another computer with another IDE in the afternoon. Keyboard shortcuts would fly around, and made different IDEs obvious.

On the order of doing things, there was more disagreement than we could experience and go through in one day. Strong opinions of "my way is the best way" would be best resolved doing similar tasks in different ways, and then having a retrospective discussion of the shared experiences.

And observing the group clean up code to be ready to check in was enchanting. It was enlightening to look at group who have "common rules" to not have common rules after all. Mobbing would really help out figuring the code styles over the discussions around pull requests.




Thursday, March 9, 2017

A Simple Superpower

There was a problem and I could tell by the discussions in the hallways. I would hear from one side that the test automation doesn't work, and it will be perhaps fixed later - but uncertain. And I would hear from the other side that there's a lot to do, with suspects of not really having time to address anything outside immediate attention.


I don't have a solution any more than anyone else. But I seem to have something of a superpower: I walk the right people into one space to have a discussion around it. And while the discussion is ongoing, I paraphrase what has been said to check if I heard right. I ask questions, and make sure quiet does not get interpreted as agreement.

There's magic in (smart) people getting together to solve things. But seems that bringing people together sometimes is a simple superpower. Dare to take room for face to face communication. If two is enough to address something, great. But recognizing when three is not a crowd seems to provide a lot of benefits.

If you can use 15 minutes in complaining and uncertainty, how about walking around to have a practical solution-driven discussion. It's only out of our reach is we choose so.

Tuesday, March 7, 2017

Testing in a multi-team setting

There's a lovely theory of feature teams - groups of people working well together, picking up an end-to-end feature, working on a shared code base and as the feature is done (as in done done done as many times done as you can imagine) there's the feature and tests to make sure things stay as they were left off .

Add multiple teams, and the lovely theory starts shaking. But add multiple teams over multiple business lines, and the shakiness is more visible.

Experiencing this as a tester makes it obvious. I work on one business line and the other business line is adding all these amazing features. If the added feature was also built and tested from my business line's perspective, it would be ideal.

The ideal breaks on a few things:
  • lack of awareness of what the other business line is expecting and needing, and in particular, that some of the stuff (unknown unknowns) tend to only be found when exploratory testing
  • lack of skill on exploratory testing to do anything beyond "requirements" or "story"
  • team level preference to create test automation code only to match whatever features they are adding
I've been looking at what I do and I'm starting to see a pattern in how I think differently than most people (read: programmers) in my team. When I look at the work, I see two rough boxes. There's the feedback that I provide for the lovely programmers in my team (testing our changes / components) and there's the feedback I provide for the delightful programmers in other teams (testing their changes in product / system context).

It would be so much easier if in the team everyone shared a scope, but this division of "I test our stuff and other teams' stuff" gets very clearly distinguished when seeking for someone to fix what I found. And I find myself running around the hallways meeting people from the other teams, feeling lucky if my feedback was timely and thus a fix will emerge immediately. More often than not, it isn't timely and I get to enjoy managing a very traditional bug backlog.

Features teams that can and do think in scope of systems (over product lines) would help. But in a complex world, getting all the information together may be somewhat of a challenge.

Minimum requirement though: the test automation should be timely and thus available for whatever the team is that is now making (potentially breaking) changes without a human messenger in the chain. 

Thursday, March 2, 2017

The Awesome Flatness of Teams

For a long time, I've known that benchmarking our practices with other companies is a great way of mutual learning. But a lot of times these benchmarks teach me things that I never anticipated. Today was one of these and I wanted to share a little story.

Today, I found myself sitting on Skype facing three people just as agreed. One of the three introduced themselves as "just a quality engineer", whereas the others had more flashy titles. I also introduced as "just a quality engineer". Turns out those words have fascinated me since.

The discussion lead me to realize I have yet really not given much credit to how different from most places out team structure is. Our teams consist of people hired as "software engineers" and "quality engineers" and there's somewhat of a history and rule of thumb on how many of each type you would look for in a team. We share the same managers.

When you grow in a technical role, you move to senior, lead and principal in the same family of roles. And usually the growing means changes in the scope of what you contribute on, still as "just a member of a team".

As a lead quality engineer, I'm not a manager. I'm a member of a team, where I test with my team and help us build forward our abilities to test. With seniority, I work a lot cross-team figuring out how my team could help others improve and improve itself. I volunteer to take tasks that drive our future to a better state. I'm aware of what my team's immediate short term goal is, but also look into finding my contribution to the organization's long term goals.

Our teams have no scrum masters. The product owners work on priorities, clarifications and are a lovely collaborator for our teams. I'm not allocated a technical (quality engineering) leadership, I just step up to it. Just like the fellows next to me.

So I'm "just a tester", as much as anyone ever is just anything. But much of my power comes from the fact that there's no one who is anything more. Everyone steps up. And it's kind of amazing. 

Wednesday, March 1, 2017

Seeing symmetry and consistency

Morning at office starts off with news of relevant discussions that took place while I was gone. So I find myself standing next to a whiteboard, with a messy picture of scribbled boxes, arrows, acronyms. And naturally none of it would make sense without a guide.

But with a guide, I quickly pick up what this is about. A new box is introduced. Number of arrows is minimized. The new box has new technology, and I ask some questions to compare and contrast that to the other technologies we're using to figure out if there's a risk I'd raise right now.

I also see symmetry. There's boxes for similar yet different purposes. Pointing out the symmetry as a thing that makes sense from testing perspective (I know what to test on the new thing, as it is symmetrical to the old thing) gets approving nods.

I end up not raising up risks, but complimenting the choices for symmetry and choices of leaving boxes without changes that I was expecting they might be changing simultaneously just because we can.

There's hope for incremental development.