Letting people go

I tweeted a little thought:

The price of letting the bad people stay in your team is that the good people leave.

— Maaret Pyhäjärvi (@maaretp) June 14, 2016

I'm not really into talking about the recent experiences I've had on this topic, but it's great to have old experiences to refer to. I want to elaborate a bit on what I mean with bad people.

First of all, I believe all people are products of their environment. There are no inherently bad people. There are no people who wouldn't be able to grow should their environment be the right one. However, I believe sometimes the damage done to people by their past environments is hard to unlearn.

What makes a person bad, in my experience is that there starts to be a common perception in a team that someone is not really contributing, or that the value they contribute is negative. I'd be very careful on assessing so called badness on a short timeframe and without significant effort in helping anyone perceived bad first get a fair reassessment and then help in growing.

With these warnings, I want to share an old experience.

Over ten years ago, I was a test manager (the good old days, when I still thought being a manager was more power than being a great hands-on tester... Empirical evidence trumps speculation. Every. Single. Time.). I had a tester in my team, and the other testers were mentioning in passing that he wasn't  really contributing much. Of anything.

I worked more closely with him. I talked about how he defined his job. He was enthusiastic about automation, and considered that one of his main tasks was to run a test automation set on every daily build. He had no skills to maintain the automation set, but he loved running it. He could skip the one that was failing, or remove it. And he could mark down 272 tests run every day. There was _never_ a single bug found by that automation, but he felt it covered a lot of ground. Manually, he could run maybe just 10 tests a day.

I suggested he would start skipping some of automation runs and just use every second day on adding 10 tests that were completely new, outside the automation set. I showed him how his area of responsibility had more support complaints from production than other areas, and explained I would like to work with him to figure out ways of testing that would find problems that clearly were there as per support feedback, and stop paying attention to the automation that wasn't really taking him forward with his goal of helping the team deliver better quality.

We worked on various ideas over a period of six months, and none of it stuck. We tried a lot of things, but it always all came to the conclusion that I had no clue of what good testing looks like and eventually, that I speak so much only to cover the fact that I know nothing.

At some point, I started making a journal of every encounter we had. I started giving all assignments both in writing and spoken form. But essentially, I started making a case of getting the person fired.

Out of this whole incident, I remember best one colleague who approached me. In not so many words, he came to plead me for letting this tester with troubles keep his job. The words stuck with me forever: "Just let him stay in his cubicle, doing nothing. This is a big company. They wouldn't know he does nothing if you did not tell them."

Back then, I worked to the conclusion of having the bad person leave. I was close with some of the good people leaving, as not everyone thinks its ok to have someone to share the work so that others will have to carry his weight too.

I learned back then that it is a lot of work to first make sure you help the person. And then collecting the fair case of letting them go.

Nowadays, I believe the tester back then was very harmless. He was just not providing any value. He was also not on the way of others, really, other than leaving more workload for others to carry. Nowadays, I work with developers and I know bad developers are not harmless. A bad developer can easily not create value but also make two other people work on fixing the mess they leave behind.

I still believe these people are products of their environments: years of accepting stale technology and little learning, years of siloed work, years of not considering the craft but hacking together whatever might appear to work without considering maintenance or quality.

As a tester, I tend to shine light to places that were secluded and hidden before. And when you see the mess in the corner, you need to start addressing it. Agile has many other mechanisms that do similar things. And when the cat is out on the table, it needs to be addressed.

Everyone pitching in

There was an interesting note I at a developer conference retrospective workshop on the topic of team dynamics. With a room full of developers, a bit of frustration to someone identified as tester was expressed.

The frustration was described as pigeonholing. You know, learning the parts of agile that you choose to enforce your message. Like as a tester, you would learn that "everyone tests", but you'd fail on learning that it would mean that you'd also need to do other things than testing. Everyone pitching in means *everyone*, not just the programmers.

The whole mention of this sounded very familiar expression of not understanding what the other party sees as the whole scope of tasks that need to be done combined with a bit of bitterness on unfairness of how we end up being treated.

I believe the core of the problem is in not understanding how to break down programming and testing into activities, perspectives and needed skills within them.

I find that it's fair to ask of everyone in the team that they grow their skills. I find that the umbrella term of testing (or programming, take your pick) includes a lot of width and depth, and gives a team endless possibilities of mixing up individual's focuses on what stretches them best next.

I don't find it fair to ask that when there is e.g. 1 testing specialist amongst 10 programmers to say that since programmers need to test, the testing specialist must do programming. In particular, if the "doing programming" means doing it alone in a corner, trying to pick up skills.

It seems to me that a lot of times these discussions are hard because we don't share an understanding of what the umbrella terms actually include. The tester saying "everyone tests" could easily mean that  there's a lot of that work and people need to pitch in and that she won't be feeling available to leave the post for learning stuff outside her usual stuff.

I find that the container "testing a change" is easily a 10 minute task for a programmer and a 100 minute task (or more) for a tester. The results also vary.

Making the actual work more visible is one of the main reasons I love mob testing. All of a sudden the 10 minute task, with an expert in the room, grows into its full length, often extending even the original idea.

My main concern with the remark is that the honest discussion about how people feel might not happen at the workplace - instead we go to our own peers to complain and the work at office continues to annoy us just as much as before.

Feelings need to be talked about. I'm sure the only reason for testers to stick with their turf is not pigeonholing. It's often the feeling that someone needs to take real responsibility of that turf no other really really understands.

SpeakEasy looking for EuroSTAR speaker

Speak Easy is a diversity program that works on bringing new voices to conferences on Testing. The way they work is  that they pair up mentors and new speakers, and they have agreed special channels to various conferences outside usual Call for Proposals. Speak Easy is awesome, and that is why I volunteer with them as a mentor. We need the new voices in the field.

Currently the Speak Easy call for EuroSTAR conference is open. I would really love for them to get the best of the world of new speakers, so this is my call for any new-to-international big arena's speakers to sign up!

Want to speak at @esconfs? Novice speaker? Apply to the @spkeazee programmehttps://t.co/VbKIN5je4n

— TEST Huddle (@TESTHuddle) June 7, 2016

The Call for proposals is open until 31st of July, so you have time to act! 

This call also gives me a chance to announce an experiment we're running to change the world of conferences. EuroSTAR is a typical what I call "pay to speak" conference, that I have had trouble submitting to because they give the conference entry but do not pay for the travel + stay (or lost income).

I want things to be different for someone who came after me and had similar feelings. So we're launching a scholarship to pay for the travel + stay for whoever gets selected. Don't let the cost of the travel keep you from proposing the talk the conference audience deserves to get!

Lost income I can't help with (yet), but will figure that out eventually too.

Show Speak Easy what you've got. Submit. And if you feel you could use help in formulating what you're talk is about, I'm still one of the people who are happy to help with that.

The world of testing conferences needs you. Start the process of getting your voice out with Speak Easy EuroSTAR 2016. And when you get a no (most people do), you've already worked out the first step to do that talk in other conferences and local meetups that are just waiting for people like you to volunteer.

** Who is we? That is organizers of the European Testing Conference and me leading up front as the main organizer. I want to see things be better. 

Programmers make great testers

Patrick Prill published a throughful, and heartfelt blogpost on Reinventing Testers and Testing Prepare for the Future. Read what he said, there's so much good in that.

There's a piece I want to write on more on in that blog post:

As a tester in the role as tester, used in the right situations, I can provide value to the project only I as tester can provide. And I don’t want to give up my role as a tester. I want to continue asking questions, experimenting with the system, analyzing strange problems, I don’t want that to go away.

These words could almost be mine. On some days, they are exactly like words I use. But when I use them, I recognize that for me, those phrases are grounded in fear. And justifiably, I'm afraid of not getting to do the job I love. I'm afraid I wouldn't at some point find work in which the management understands the immense value I provide because they'd worry about developers giving up on their quality-responsibility for just mere existence of someone like me.

However, I see programmers asking questions - better questions even - than me, and it fills me with delight. I see programmers experimenting with the system and showing genuine curiosity. I see programmers analyzing strange problems, using debugging tools to deeply understand what is going on. I see programmers doing brilliant testing, changing perspectives, realizing new stuff. And I don't feel fear of losing my work, but I feel pride in enabling other people to get to enjoy the stuff I've enjoyed so much. And I feel delighted when they identify tedious points of doing this and add automation to help out with that.

I'm proud to be a tester. But I'm more proud that my programmers are testers too. 

I recently met with a tester, who was waiting or coming up with other simple tasks while she couldn't test. The discussion reminded me on the fact that even with my programmers testing very close to my skills, there's so much work on feedback that there's always stuff I could propose to contribute on. (Actually, just contribute. Ask for forgiveness, not permission).

Now that we release daily, there is no more testing phase, but the whole life is a testing phase and for all of us. There's always the view of testing as artifact creation (giving us spec, feedback, regression and granularity) and the view of testing as performance/exploration (giving us guidance, understanding, models and serendipity). The views and deep skills to those views peek at different times with regards to adding a capability for the software. We test continuously.

As a tester, I've spent a lot more of my time with things some people like to call "shift left". But since this is all a cycle, there's no more right or left, really. While in the past as a tester, my main contributions were on tasks with focus on exploring before production (letting the software speak to me) and contributing before implementing, now my focus is more on exploring while in production, with help of metrics and insights supported by patterns of real use. I get to do more while implementing when we mob too, and absolutely love the half-sentence picks that save us hours and days without programmer ego in play.


I believe we need new ways of explaining what is the "testing" we speak of. Because it is more of testing as performance. The performance feeds the artifact creation. The artifact creations constrains the performance - often unnecessarily.

Learning in layers - testing as performance - takes time. The time taken is what makes some programmers bad at testing as we know it. Time comes from outside as well as from within.

I will do whatever I can to make sure we enable the programmers that see big picture and work wonders. Enforcing a tester role, and founding it in arguments of fear has not helped me. Enforcing understanding of testing has. When I speak of my fear, I get helpful responses. When I set up defenses and claim I'm not afraid, I feel attacked. 

Being nice, being active

Meeting wonderful people at conferences, I get reminded of how lucky I am in many ways. I get to work in an environment that feels safe, where I can voice out my concerns and feel that when I fail in communicating, I can recover.

This is not always the case. The story is adapted from inspirational real circumstances, combined with some of my past experiences and then shared.

It was an important project, with a deadline. You know, one of those "deadline regulated by law" types of things. People had high hopes on new technologies being introduced making us more productive. But new technologies had surprises, and under pressure people were starting to feel like someone else was slowing their bit down.

On one occasion, there was an outburst of frustration. Two weeks later, the fellow who had not contained herself, was replaced. Consultants are replaceable. We needed the good atmosphere, something that said that we can make the challenging schedule.

It's not that anyone had evidence on the schedule being off. There was just a lot to do. Including a lot of surprises. 

But with all these things between us that we couldn't say for various reasons, I suspect none would speak up if they were concerned. So I focused on my tasks. My work. And while there was nothing to test, I was just prepping mentally, reading stuff online, asking for tasks I could do every now and then. 

I can't imagine having to be afraid of being fired for speaking up. I can't imagine even being afraid of being fired if I lost my temper and said something inappropriate, as long as we work things out afterwards. 

I can't imagine I would passively wait for work to be assigned to me, or that I would go ask for tasks. I ask for goals and purposes, and in collaboration find the things I can contribute or learn on.

I've worked in places with reputation like this, without having the same problems. I've always attributed this to skills of how to take things forward: being nice, being active.

We're all work in progress and while we can't change the way others behave, we can change how we behave in response. I would hope to learn to model better behaviors with hopes of some of it catching on. Say nice things. Encourage. Be helpful. Believe people mean good. Have patience.

It's hard work, but makes life so much nicer.
 

Work on culture: being told and offering views

Some days I feel there's serendipity in the air. Today, the serendipity emerged with two tweets of totally different sources close by in my tweetstream.

The first tweet got me really excited and thoughtful.

Attitudes in two different industries pic.twitter.com/fwcVLmuLGK

— James (@jameswhatling) May 17, 2016

I feel there's a lesson for the software industry here. Being realistic about our abilities. Respecting everyone's contribution. Thinking in bigger scale. Making mistakes and not trying to hide them.

So it seemed very appropriate that the next tweet I looked at was one by Anne-Marie Charrett, proclaiming "Leave testing to the experts".

Just seeing the title, I disagreed. Seeing who wrote it I was sure I wasn't disagreeing, that the disagreement is probably around rhetoric. Reading the text, I feel there's some experiences I have that make me feel different.

When Anne-Marie says: "I don’t tell you, oh developer how to code your program. I don’t tell you oh, sales person, how to sell your product.", I instantly realize I do tell developers how to code their program. I regularly mob with my developers, and feel increasingly comfortable offering my views. I do tell sales person how to see our product. I offer my views regularly and in good spirit. If my team in large (sales people belong to my team in large) felt protectionist, they would not take my offered views as that. And if I offered views that were dismissed because experts just know better, I wouldn't feel particularly good about that. And we'd make more mistakes, improve less. So I love the fact that everyone tells others what they could do, and everyone tries to understand why the other would think that would be a good idea.

This tweet sums it up perfectly - Respect. I show respect and I'm shown respect. Respect is like trust, cultural aspect that can be offered without me working hard to earn it. Believe good in people and you get good in people.

@maaretp Telling and offering views is quite different I'd like to point out. I'm ok with the latter. Respect is the difference here

— Thomas Ponnet (@ThomasPonnet) June 3, 2016

Offering view is often taken as telling. I like to try to hear people are offering views even when I feel they are telling. 

Having worked side by side with developers, it's clear I bring in some special skills and I develop some special skills, both in myself and in the people I share work with. As there's less of need of me being the expert in testing as everyone tests like an expert, I feel sad when we reclaim testing saying things like "Leave testing to the experts". I'd like to see that we could distribute that expertise and with a mix of different skillsets to it (in particulation the automation mindset developers apply to any problems they encounter), we will find ways of doing great things even better.

So when Anne-Marie asks:

So why do you think its reasonable and perfectly acceptable to tell me how to test software? 

I would consider reframing what we hear as people telling as people being bad communicators with good intent and missing information they could well have on how software testing actually works. And like with the expert pilots listening to advice from newbies, we should open out to listen what advice we're given. And instead of taking advice as advice, I like to think of responding: "That sounds interesting. Would you like to pair with me on trying it out in practice?"


Paraphrasing Woody Zuill from memory "It's in the doing the work we discover the work that needs to be done". I find that while doing, some things that I considered worthless or wrong, turn out to be interesting ideas that combined with existing knowledge transform the ways we work.

Backlog-filling specialties of testing and UX

There's a major change going on with work as I knew it. Half of my team's developers are moving to other work, and I'm bound to analyze on what I feel is the right ratio of testers - or rather, if it makes sense to double it.

Over the last four years, I've learned that one good exploratory tester can both help developers hit the mark better AND fill the backlogs with work undone (some might call these bugs) to an extent that it makes sense to add power to fixing, not testing. The information testing provides gives us little value if we are unable to react to the feedback. There's some types of information that is useful to know even if there was no fix applied. But that is more of a special case.

Since start of this year, my team has had not only a tester but another person with very similar goals, working on a more limited set of problems: UX (user experience). With an existing product and loads of ideas of improvement, I see the same pattern that emerged when I first joined. One person can easily fill the backlogs with work undone, this time from a UX viewpoint.

So all of this leads me to think of the idea that all too often, both testing and UX are backlog fillers. We create plans without action. We rely on developers to take the plans, fine-tune them into something that can actually be implemented without losing the value we hope for, and turn them into actions through code.

While it is worthwhile to try to figure out things before we're building it, there's still a whole lot of stuff we're figuring out as the product grows. This is true for both testing and UX perspectives.

Plans without actions make us backlog-filling specialties. I find it fascinating to seek for better ways to do this, where the effort won't go into building inventories and going through them for prioritizing them into the pipeline, but instead, have the expertise readily available. Unsurprisingly, the best mechanism I've seen for this so far is Mob Programming. No more plans without actions, but plans with actions and a good follow through.

If it only was easy to get people to do it, other than the practice sessions...