Changing conversation from bugs

Today feels like a good day to celebrate the progress we've made in my team. I'm approaching four years at this job, and while I'm regularly thinking of moving on, I just love what we do.

Four years ago, one of the hallmark moments was a day few months into me being in the company, when the product manager came to my cubicle, started shaking my hand and told me first he owes me a beer. He had thought until that point that when software comes to him, he should expect it to be broken. I changed that by providing information to my developers they needed.

At first, there was a lot of pain. Our sprints were awful and always late. I convinced the team and product management to try out daily releases and things improved a lot. We also stopped estimating efforts to implement stuff, and focused our discussions on how we can make it small and whether it is the thing to do at all. All the energy that went into looking good in estimates could now go into developing ourselves and our product.

About a year ago when writing my CV as I was looking for opportunities to work in US (still looking, but I need to find my brilliant team/organization that sponsors the H1N visa). I looked at some of my results bugs and added this: "Personally reporting and getting fixed 2261 issues over a period of 2,5 years on Granlund Designer and Granlund Manager projects". I was shocked as  that means that on average I had reported 2,5 bugs every day. I had already worked on improving the skills of the developers in developing and testing, but I felt I needed to step up the game.

A year ago, I intentionally emphasized discussion and developer learning. I started pushing my team to practice together pairing (rarely, they hate it) and mobbing (more regularly, as they learned to love the learning). And the result is that I've logged 348 issues in the last year, but that is only  1,1 on a daily average. My big (and regular) successes are the times when developers get in touch explaining a feature, and just look at me and tell me what they now know is wrong with their implementation. They hit the mark better, and our relationship has increased in quality.

We release on average twice a week, and our end users rarely see problems they would complain about. The amount of test automation is ridiculously low, but the technical quality of our code (a thing I champion for regularly) is good and improving.

I feel I've gone through an intense year of changing the conversation from bugs to value and skills, and it's been worth it. For a second year in row my collaboration review with the manager focused on how much I've helped the team to grow to empirical feedback and actionable suggestions, not on finding or missing bugs.

This is why I love long-term commitment. I now know that apart from one troublesome individual (see the previous post), my team will excel without me when I leave.

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,