In search of strengths: when done is not done

A weekly meeting, and an unusual argument:

P: Oh, that feature of mine is ready. It's been ready now for a week. I would have already put it in production if you did not make up a rule that I can't.
T: Hmm, I must have missed something. So it's ready? You fixed all the problems. Last I tried it two weeks ago, it did not really even start.
P: It has worked for me all the time. But I did some tweaks. There was nothing significant. Just give to the customer.
T: We'll team up to test it and see where we are. We're delivering when it's team-definition ready.

It's been such a long time since I've had to endure these discussions, that I almost forgot what they are like. And that they were the standard style of discussion some 20 years ago. For most part, I'm glad those days are gone.

But what's going on here, really? Story continues with three people testing the feature in a group.

T: So, let's just go through the basic flow. This was the command, right? (setting up the data to something a user could use, instead of the developer specific version)
P: Yep. Just run that and it all works.
U: I have a few UI specific remarks, let's go though those in the context of use
P: I hate this nitpicking, couldn't you just go and fix it in the code?
T: Let's just see how it is. Oh, it crashed? It doesn't do that for you?
P: No. I guess there's a bug there. 
T: Oh, I know. This is because you expect this other thing to be run first, right? But look, my data has three things and this list has only one. 
P: The other application is done by someone else in the team, I just move the data here. But I guess there's a problem. But there's another developer who worked close to this area, talk to him first
T: Ok, so this is the summary page.
U:
T:
P: Did you have a picture of how that was supposed to be?
U: And there's still this one thing we need to improve we just talked about
...
T: Let's sum it up. Five dialogs, 2 months of work on the must do list and more on the later iterations list we thought would be in now. See why we disagreed on done yesterday? Could we work out something so that you'd believe the two of us actually know a thing or two about the product and its use, and we'd need to collaborate?
P: I guess I go work on this stuff more. 

This story has background that is not visible in these discussions: knowledge of bad code design, bad choices of how things are implemented and a 3-year experience that fixing just makes things worse. So I ask:

There’s loads of stuff on hiring, but is there anything good on having hired a wrong one and needing to live with it?

— Maaret Pyhäjärvi (@maaretp) February 19, 2016

Here's the answer I love the most:

@maaretp we evaluate strengths and weaknesses and use the person accordingly. In my experience training rarely dramatically helps.

— Jukka Talvio (@Jukka_Talvio) February 24, 2016

Now, in search of the strengths I work on empathy and hope the programmer would stop opting out of our team mob Thursdays. People are the way they are because of environment and experiences. Play the strengths. And accept that conflicts can turn into something positive, even if they are draining.

Testing isn't testing: A story of Skilled vs. Random Tester

You know, testing isn't testing. Sounds weird, right? So let me try to explain a discussion I seem to be having over and over again.

There's two people, and both of them could do testing on the exact same thing. Let's say one of them is a skilled tester - which is someone who is really paying attention to how you learn using a software product as external imagination - and the other is a random tester. The random tester might be good, but she is not the same as skilled tester, not unless focus is on learning to test great.

The random tester often is a developer, doing her end-of-development testing to the best of her abilities. And those abilities might be great, and the overall result well worth being called good enough.

When we then compare the "final testing" of a skilled tester and random tester, there seems to be this mysterious magical idea of skilled tester just being dropped in and doing their best performance. But, since the skilled tester learns in layers, the first time testing at the end of development isn't going to be the best performance. There's layer after layer to get deeper, and each layer provides useful results - just not the same.

Some managers still let skilled testers be around a little in the end, and confuse a good performance with the best performance. And many testers still confuse the Skilled Tester's good performance to the Random Tester's Best Performance, in particular when there's always an aspect of testing and learning even when you decide to all it "programming".

If you're serious about good quality, you'll want to enable the Skilled Tester's Best Performance. The Skilled Tester's good performance happens somewhere along the line, but the final show with the final results is the best you can get from her. The best performance happens at the end, after rounds of learning and practice.

So testing isn't testing. Performance and output from such a performance varies greatly. Random testers do a great job, and some of them are very close to skilled testers. It's a question of motivation and focus.

And if you wondered why this? I just had yet another encounter with someone who thinks they get to buy my best performance without practice. Because skilled must mean packaged, like a machine.

Small batches vs. context-switching

I've just spent an hour ranting about how much I love small batches and how I don't understand why my neighbor team still releases monthly and not daily, since we are so similar in what we should be able (and willing) to do. Then, opening twitter I get reminded on a theme that I heard but decided to redefine on the fly yesterday in Jess Ingrasselino's webinar with Ministry of Testing Masterclass on the Lone Tester: context-switching.

Jess mentions in her talk a few times that context-switching suits her working style and personality. Then she talks about the variety of types of tasks, where all have a common theme: helping quality emerge. She's in meetings with designers, developers, and support. She does exploratory testing and test automation. She works on requirements to discuss them, and the final checks. And as a lone tester, she might share her time in some way with several feature or product teams. Overall, she is responsible for defining where she will be, and not sticking to someone else's shallow notion of what a "tester" should do.

I loved the talk, perhaps because I too am a lone tester with a lot of freedom to put things together in whatever way I feel helps us. I tend to identify all sorts of things that don't seem to be getting done, making some of them visible and doing some of them myself. There's no task I wouldn't be allowed to do.

When Jess talks about context-switching, my brain right away decides she does not mean that, but she means small batches. Finishing one small thing before taking another small thing. Not interrupting in the middle and ending up trashing. But the natural state where you can do something and then it's done. There will be more like it, but they won't be the same.

Learn to love small batches. Releasing daily to production is the most liberating experience I have. Small changes are smaller risks and smaller to test. And while testing is never done, delivering things over warehousing investments without returns is rewarding on its own.

I feel that if you know how to create small batches - for you and for people around you - you'll do great as a lone tester.

Testers see things and should speak up!

I've been a tester and a software catalyst for two decades. A lot of time the discussion around my kind goes around feedback, and a particular kind of feedback is bugs. By finding out about them, we react to them and make the world together a better place for our end users and customers.

There was a particular lesson through that I took at heart quite a while ago, long enough that I think of it as common sense. When all that comes out of you is bugs and problems, there's a dire need of balance. Don't just share the bad, share the good too.

Remember to say out loud when you're positively surprised. It could be that you did not find as many bugs or any, or that the ones you had to find were different in profile than what you would expect. It could be that you notice that things change and improve. Recognize, acknowledge and share the positive things you see.

I try to live to this in my at-office life and in my online life on twitter: say thanks, share excitement, promote others. The latter has been a learning route for me but we all do better when we all do better.

Early this year, I learned about yet another way of showing appreciation in a very public way. There's a new competition in Finland around promoting the good we do in software, in 7 categories called Blue Arrow Awards. Think of this as the Oscars of IT. The moment I learned of it, I asked for the 150 euros to submit my team into the competition - still struggling with the day of writing though, but committed to doing the service for my team.

For me, the acknowledgement did not stop there. This is me: 

🙇 First Propellerhead award candidates received! Remember that exposing a candidate is free. Keep them coming.https://t.co/G7ajgHZmF0

— Blue Arrow Awards (@bluearrowawards) February 23, 2016

I'm proud of my first candidate, one that would be unlikely to have been recognized regardless of his significant contributions in community. While he should win, my main hope is that his work gets a little more recognition. Winning is not the point, showing appreciation is.

Everyone needs someone to run the rounds for them. Will you do it for your team and your candidate? I'm happy to help. The good stuff needs to come out!
 

Testing the same old but with a new implementation

Many of us testers run into these occasionally: there was a feature that was done and tested a while ago. Then new information emerged and a complete rewrite in order. More often that not, there's a new understanding of requirements driving the change. There's often something new that needs to be implemented, that would be hard to extend on the old implementation.

Me and my team are in the final rounds of one of these changes. We had 3 reports (which are basically the main output for the users using our software) and we needed 3 new ones, which needed to be essentially different. And while discussing these 3, we realized that what we actually need is a report configuration engine, as the each of the new organizations coming into this is likely to have their own configuration needs even if the information would be same or similar.

With this rewrite, one of the shining stars in the team took the problem and turned from someone who could deliver incrementally into a protective person, focused on the technical structures. In hindsight, he was doing a lot of research on components he could use but it all appeared one big chunk. And digging him out the hole he dug was quite an effort.

At some point, all the 6 reports were all intertwined and needed to be released together. A discussion by discussion we untangled them, and delivered the 3 new first (already months ago) to learn what they would be in real use. We learned just few weeks ago they are missing an essential feature, so a second round of work on them is in order. And the 3 old ones, we found ways of delivering them one by one. After 3+1 out, we decided on changing the layout in relevant ways, and again agreed on the steps to deliver this further.

As we're now on final rounds, there's two reports left to test. I was feeling the testing was particularly straightforward in the pattern:

• search for customer feedback on the old reports
• pick any special data mentioned in the reports
• generate a new and old report, and compare

I found many problems with the approach today. I learned that for a particular set of data and options, the report wouldn't generate at all. I learned that there was extra information and that some of our conciseness goals were nicely achieved. Over the day, I felt as if I was surrounded by a warm blanket: there was the old version, the version that worked "right". And it was so rare to have that that I realized I almost had forgotten how much that helps. 

Feeling too comfy, I decided to try something different, and cover combinations of options in more detail again. I made a list on paper of what I wanted to try, and to my surprise found more relevant problems of how things would misbehave. 

At the end of the day, I was reflecting back what I had done. How close it was that I called it done when I did what I had in mind test design wise. And how relevant it was to find the other way of approaching to learn what did not work. 

All it takes is finding the next stretch. But I love having the old system as an oracle. Why did I ever settle in not keeping the old installation available when I was newer to this? Can't imagine.  

Planned vs. Emergent Doing

I've had a few months of more intensive self-reflection than usual, and usual level is pretty high level for me too. There's goals in life I'm being coached at, and one of my major goals is to find my focus. I'm all over the place, looking for the common thread and dropping stuff were the thoughts I started from.

I tried very hard to make a plan for myself, but plans rarely work out. When I plan to organize a meetup and put it in a calendar promising I will deliver a talk there, that works for things that can be event-driven. But there's other stuff too.

We had a time management session for the Software Testing Finland crowd, and the speaker there suggested to put stuff in calendar. Reserve slots for things you need to do. I tried that, and messed up my calendar completely. Because, most of the stuff I need to do does not have to follow a plan, but an inspiration.

When I test, I see what are the things I try to avoid (e.g. testing stuff made by a developer who fights back with everything I say) and I push myself to make space for those. I see what are things that I feel strongly about (e.g. fast feedback and making things available for production in shortest possible loops)a and I naturally give space for those. I see things that are short term and long term benefits, and I balance my progress to include a mix of each. I value helping others over doing my own "responsibility", but work to balance both into a mix.

When planning failed, what I did was that I listed the things in life I want to take forward. I ended up with 28 items, none of them are small, more like themes: "Change the world of conferences", "Startup dreams", "Teaching programming to mom's and daughters",  "Writing my blog", "Writing paid articles", "Exercise", "Family and friends" and so on. And instead of planning what I would do, I just let my plan emerge and document it.

For a month now, I've been doing stuff I feel inspired on for various reasons. I've followed my fears, I've carried my responsibilities towards others and been inspired by things I could not foresee but that fit my overall idea of life. My balance sheet keeps me true to my overall goal. It's my emergent plan, my anchor I can reflect against to see what themes I've driven forward. I've marked down each day which themes have had my attention, and I see things I've worked more and less on. And I can decide what to do with it, or if I just want to let it be as it is.

I don't believe in multitasking. But I believe in a continuous flow of delivered value. This is it for my personal and work life. I live in the moment and that is how I get all of the things done, 

Changing the world of conferences: pay the speakers

I spent last night reading up links on speaking as part of your professional career and a few lessons I found particularly insightful:

• Cate (of TechnicallySpeaking) reports her costs of a year in becoming speaker: 3767 USD. It is quite an investment to start speaking when conferences are #PayToSpeak, and only give you a free entry for all the work you do to create the talks. 
• Jenn Lukas shares a formula for speaking fees, that is the money you should ask on top of paying travel and expenses. Delivering the same talk 2000 $ and delivering a new talk 5000 $. Her hours sound about right. 
• Lena mentions a typical honorarium she's heard of is 150 - 700 $.
• Jurgen Appelo shares his speaking fees that are based on where the speaking will happen and how much those areas typically can pay.  His price includes travel and stay and range from 1900 €to 3900 € in Europe and 3900 € to 5900 € for outside Europe. 

 I set up a conference (European Testing Conference) to change the world of conferences. There's two changes in particular that I seek:

1. Getting programmers and testers (and others) to work together on solving the testing challenge in spirit of dialogue, without fear. We need to actively mix testing as programmers know it and as testers know it, to find better mixes.
2. Getting delivering valuable sessions in conferences to be treated as paid work instead of a favor in marketing. 

With this post, I'm focusing on the second change. The speakers should not have to pay to speak, and speakers should be paid to speak.

Reading the posts from others, I felt there's a post I need to add: one from a perspective of a conference organizer. Let's use European Testing Conference as an example. It's a bit different example in the sense that normally organizers need to also get paid, and with this one, organizers are not on salary.

The group of speakers + organizers is in total 27 people. It includes 4 organizers,4 keynotes, speakers with hands-on 1,5 hour workshops and speakers with 0,5 hour talks.

For sake of simplicity, let's assume every one of these delivers a session they've delivered before and that preparing a shorter talk session or a longer hands-on workshop would take only the same time as an hour talk . The amount to pay with Jenn's rule is 25*2000 = 50 000. If the talks were new, the sum would be 25*5000 = 125 000.

That's would be the fair way of running it, but that is a goal I quite can't reach. And worst from an organizer view, what if I had to commit to that level of payment in advance and I wouldn't get enough people?

The commitment to speakers we did with European Testing Conference is that they will not have to pay to speak - we will cover expenses, even with our own risk. And a risk it seemed to be, up until 2 weeks into the conference when we finally went from us paying to organize to being able to pay something to speakers and leaving a little for next year / other causes (*) we raise money for.

Lena's honorarium sums would end up with  3750 - 17500 to be paid as a conference, and we seem to be landing somewhere on this range this year on what we'll split to speakers. In future years, the goal is to move from this per speaker 150..700 range to 2000 ... 5000 range - sharing the financial risk and opportunity with the speakers.

We're also working on openness of accounting, so when we have numbers together, we'll share them. That should be a few more weeks into it. A change is starting, even if just with one conference.


(*) on other cause: we're going to be starting a fund over the years to pay speaker's travel expenses for other conferences and looking to partner on that with communities that support speakers. The world needs better and more diverse conference sessions. One experiment at a time.