Wednesday, December 7, 2016

Tester as a Catalyst

Back in my school days, I was a chemistry geek. And if life had not shown me another path through being allergic to too many things, I would probably be a chemical engineer these days.

It seems very befitting that my past team helped me see that a big value I provide for the team could be best described in terms of chemistry - of me being a catalyst in my teams.

Catalysts don't make things happen that wouldn't happen otherwise. Catalysts speed up the reaction. Catalysts remain when the reaction is done with.  Potential for reaction exits, but sometimes you need a catalyst to get to a speed of noticing visible changes.

I love to look at my contribution with that perspective. The things that happen with a tester like me around are things that could happen otherwise but I speed up the reaction with information that is timely and targeted, and delivered in a way that is consumable. For many of the things, without a tester like me, the reaction doesn't start or is so slow it appears not to happen. A catalyst can be of any color, including completely invisible. I would like to think of myself as more colorful addition.

I'm working through my techniques of being a good catalyst in my teams. Here's some that I start with.

Introduce ideas and see if they stick

I have had the chance of hearing (through reading and conferences) to be introduced to many people's ideas of how the world of software could be better. The ideas build up a model in my head, intertwined with my personal experienced of delightful work conditions with great results that I want to generate again and again. The model is a vision into which I include my perceptions of what could make us better.

Out of all the things I know of, I choose something to drive forward. And I accept that changing is slow. I speak to different people and through different people. I work on persistence. And my secret sauce for finding the patience I'm lacking is externalizing my emotions on counting how many times it takes, writing notes for future me about my "predictions" to hide out of sight and venting to people who are outside the direct influence of the change.

I believe that while I can force people into doing things, them volunteering is a bigger win, leaving us working on the change together. I can do this, as I'm "just a tester" - as much as anyone is just anything.

Positive reinforcement

People are used to getting very little feedback, and I find myself often in a position of seeing a lot of things I could give feedback on. And I do, we talk about bugs, risks and mitigation strategies all the time. But another thing I recognize myself doing is positive reinforcement.

I found words for what I do from Jurgen Appelo. He talks about managers shaping organizations with the best behaviors leaders are willing to amplify. I try to remember to note exceptional, concrete contributions. I try to balance towards the good.

And recently, I've worked more and more on visualizing and openly sharing gratitudes with kudo cards. Not telling just the developer that his piece of code positively surprised me on some specific aspect, but also sharing the same with her manager who has less visibility on the day-to-day work than any of us colleagues in teams.

If I want to see more of something, instead of talking about how it is missing in one, I prefer talking  how it is strong in another.

Volunteering while vulnerable

I find myself often in middle of work I have no clue on how to do. I used to hate being dependent on others, until I realized there are things that wouldn't happen without a "conscience" present.

In mobbing, I could see how the developers look at me and clean up the code, or just test one more thing before calling it done.

It's not what I do. It's what gets done when I'm around. And in particular, it's not about what I can do now, it's about what I can do with people now and what I can grow into.

Amplifying people's voices

A lot of people, not just testers, feel they are not heard. Just like my messages get through best with other people, I can return the favor and amplify their voices.

I can talk to the managers about how it feels to a developer with a great idea to be dismissed, until I repeat the message. Through the feelings discussion, I've had managers pay special attention to people with less power in their communication that I seem to find.

We're stronger together, I find. We have great ideas together. It's not a competition. It's a collaboration to find the diverse experiments to give chances to perspectives that make only sense in retrospect. Emergence is the key. Not everything can be rationalized before.

How to write 180 blog posts in a year

Yesterday, on December 6th - the Finnish Independence Day - I learned that I have apparently written 180 blog posts in 2016. The detail alone surprised me, but the context of how I learned this trivia was even more surprising. I was one of the mentions of my many achievements as I was awarded the MIATPP award - Most Influential Agile Testing Professional Person - at Agile Testing Days 2016 in Potsdam, Germany.

I'm still a little bit in a state of disbelief (influential, me?) and feeling very appreciated with the mentions, likes and retweets on Twitter. But most of all, I get stuck on the idea of 180 blog posts - how did that happen?

With the number coming out, I wanted to share the secret to regular blogging with all of you. I learned it from people who talked to me about my blogging and in particular from Llewellyn Falco.

The secret to regular blogging is not planning for it. Not monitoring how much you're blogging. Using all your available energy around blogging into the action instead of the status.

There's a time for doing and a time for reflection. I apply cadences to reflection. There's the daily cadence of showing up to try things. There's the weekly cadence of seeing progress in small scale. There's the monthly and quarterly cadence of trying to see flow of value I generate. And there's the annual and lifelong cadences of appreciating things I've learned and people I've learned with.

I write for myself. I still surprises me that people read what I write. I'm still "just a tester" believing no one is really just anything. I live and breathe learning, and blogging is just one of the many tools to learn. If I write (or give face to face) awful advice, I can learn from it. If I don't give the advice, if I don't share my experience, I'm one more step away from being able to learn what could really work.

Share to learn. Care to learn. And wonderful things will emerge.

Wednesday, November 30, 2016

We love our little boxes

There are days when I feel I shouldn't tweet, because my *intent* is just to make a note of something and someone else takes it as "Interesting, I want to understand this" - and a long discussion emerges. Twitter really isn't a good place for having discussions and personally I at least seem to be confusing people more than clarifying over that medium.

So this is a place for a blog post. Here's what I said:
Let's first talk about the principle. For years, I've been working as a tester and I view my job to include working through information and uncertainty. I'm somehow involved in an activity that makes a discovery of something missing or off, and then we'll do something about it when we know of it. Making lists of things we are missing is core to what I've been doing.

However, reading through lists is a huge time-waster. There's a lean principle of avoiding inventory, and lists of things we should/could do are definitely inventory. Creating and maintaining the lists is a lot of work. And a lot of times with focus on a shorter list in a group that does development is better. Let's deliver this value first and look at what we know the world looks like after that, right? So I've chosen to try to work on value we're delivering now.
My usual example of minor changes and tracking is my inability to unsee or dismiss typos in applications. I can go by them, but they leave me backtracking and drain my energy. But there are a lot of these things where, if I look from just *my* perspective as a developer, I could do the "minor" task also 5 minutes before the release. But the trouble is, there may be others who will backtrack all the way until the change is done.  

I see two patterns of how these discussions  with minor changes go (that are really honestly minor).

Case 1: Yes, this. 

There's tool with a local testing script for making sure our schema follows the rules. I change the schema, and I get told to run the local script. Except that the script won't run. Going through the code, I learn there's a parameter I need to use, no clue what it would be. And when I ask about it, I learn that in addition to the missing parameter, I also miss some libraries.

Instead of passing this information to me (and the 50 others who will run into this), the fellow I go to programs relevant error messages to the tooling, so that anyone coming after me gets the info from the trying to run the tool. And all of this happens while I sit with him, with changes being in the version control by the time I walk away.

A day later, I see someone else struggling with the tool. They appreciated the error message right there and then. No backlog. Small thing, do it now. Same amount of time would have gone into just making the backlog item.

Case 2: No, not this. 

There's the schema and it's shared with 10 teams. It's actually only becoming a contract between the teams, so it's work under progress. Reviewing it in a group with representatives, we agree on things that need doing. Like splitting according to our rules. Like removing values that are not in use ("it says DEFisEnabled" and there is no DEF at all yet, maybe in 6 months). Like making sure the names don't confuse us ("it says ABCisEnabled" and "true" means it's disabled). 

So we agree they need to be changed and they keep not changing. Because no one volunteers to change them. No one volunteers because anyone could volunteer (including me). And only one of us (me) will be directly suffering the consequences on a continuous basis with the mental load of remembering what works, what doesn't and what still needs doing.  While we're avoiding doing things that are part of that value we should be taking forward together, the side effects hit other people than the ones avoiding the work.


We all have our ideas of what else we could be doing, and a lot of times that does not come from the perspective of value, but choices of the type of work I personally would like to do. If I'm a C++ developer and we need a Python tool, that is surely a task for someone else? If I'm a senior developer and the change can be done by a junior, that is surely a task for someone else? If I can find someone, anyone, to do it, it isn't my task to do. Because when it isn't mine, I can do more of things I personally would choose to do. Like complex algorithms. Or only testing. Or studying more of something I'm into because I don't have to do *that*. You name it. 

I could frame my original question to be: why so many people volunteer to only work on things they see as "their job", without caring about the overall flow in the system. And all this is a very human thing to do. We like our boxes. We like staying in our boxes. And we love the idea of someone else doing the stuff that doesn't belong into the boxes I like doing.

Saturday, November 26, 2016

In search of value and bottlenecks

Back in the days when agile was new to me, a lot of teams played all sorts of games to learn about the dynamics relevant to software development. Some of the best training courses included a simulation of some sort - maybe they still do.

I played the Marshmallow Challenge with Antti Kirjavainen at Tampere Goes Agile, and thinking of it, I realize it has been a long time since I've been playing any of these agile games.

One game that I remember particularly fondly is the Bottleneck game. I'm thinking of that game today, as I'm thinking about bottlenecks and people's attitudes.

A lot of times talking with programmers, I sense an idea of self-worth in writing code. It's true, there isn't a program we can run (and test) if there isn't the act of writing the code. However, looking at professional programmers in action by sitting next to them, you see that clearly it's not all about writing the code.

In fact, writing the code is hardly the bottleneck. Thinking smart to be able to write the right code is. And for a non-programming programmer like me, thinking together, in right kind of batches, tends to be the contribution I seek to improve.

Without writing the code, the thinking isn't complete. It's still a theory. The trust we experience in testing the system is in the part of the thinking that ended up in the code.

I also find it absolutely fascinating to look at programmers thinking about a line of code together. Having that chance (by inviting myself into that chance) I've learned that for each line we write, we have a lot of options. I remember looking at one of those cases unfold in particular, in a mob format.

We were replacing a component with another. We were not particularly good at talking in intent, all we knew is we need to take out calls to one component and replace then with calls to another. And very early on, someone suggests a way to do a thing. Someone else suggests another option. And another. And very soon there's suggestion of something none would have suggested without hearing the other suggestions. And that feeds into yet another suggestion.

While a lot of times we would go about doing all, we did not because we did not actually propose those as ways of doing. We listed them as possible ways of doing it. From doing the one selected, we still built more on top of the experience.

In a period of just a few minutes so many things happened. And all these things were about thinking, and bringing in various perspectives and experiences into that thinking. It made me realize that each line of code can have a lot of options on what it includes. From a perspective of a tester, those options have implications. Being a non-programming programmer further away from code, I would not see or understand those implications quite the same way.

The amount of tradeoffs in selections in building software is fascinating. The idea of getting it to work is so different from getting it to work just right for all the criteria we can be thinking of: the rightness for this particular technology, the rightness for future maintenance and extendability, the rightness for performance and security considerations.

So all of this leads me to think about the problems I'm experiencing in (some) developer thinking. The problems of "just tell me the requirements", "just specify what it needs to do". The problems of not volunteering to finish the details when the big lines have already been implemented. The problems of not caring about side effects when there's at least some way it already works. The problems of not considering future self and others in maintaining the code. The unwillingness to cross necessary technological borders and rather waiting for someone else to do their bit and solving problems in the interface together, real time. The inability to spend time on testing with an open mind to learn about things that didn't quite work as intended, that we did not even know to expect.

A lot of times the other thinkers, like product owners and testers are around to compensate for the programmer interests. But I still appreciate the programmers who can do all of these types of things the most.

And I find that they usually don't exist, except momentarily. And in programmer groups when they are in their best behavior. 

Not a consultant

I don't have excessive experience on how consultants do their jobs, I've been one only for a very short period of time in my career. The consultants that I see seem to be self-certain people, some very aware of their specialties and limitations, but all taking significant steps to go about helping organizations transform in some way. With the big visible cost number per day, there's an expectation of impact. Consultants being realistic, the impact isn't usually an overnight transformation, but a slow movement of changing perspectives and habits and including skills to stretch the status quo.

I've done short gigs with companies. Most recent one would be one where I first helped assess skills and potential of tester candidates delivering a video of pair testing and report on what to pay attention to in that video and then later training the hire into testing the product, again through strong-style pair testing with me never touching the keyboard. My "consulting" gigs are usually very contained, less open ended than what I see other consultants doing. And all this comes from the fact that I work as "just a tester" in some organization. Now F-Secure, and other product / customer organizations before that. I love the company ownership of the solution and the business development aspects, and I've always felt I get into that all the way immersing myself into the organization and its purpose.

Today I was listening to Sal Freudenberg Lascot talk about Neurodiversity / inclusive collaboration and I was thinking about how much nicer it was to think of aspects of being neurologically different in our needs of how we feel comfortable working than talking of being introvert/extrovert/ambivert. This thinking also helped me outline my favored style of working in organizations that I've been framing in contrast to styles of some people who try to achieve similar results.

I tend to avoid pushing people directly to do stuff. I'm very uncomfortable telling my team to do a retrospective (I mentioned that 20+ times, each time marking one in my bookkeeping to see how many mentions it took to get it done - 23 was the tally). I'd like to tell my automation tester colleagues to go pair with other automation testers because they just write the same code and it makes no sense to me to have personal repositories, but instead of telling, I again mention. Over time, I will show specific examples of problems, hoping people will take up solving those.

The same goes with me wanting to try out mob programming. I go and pair with people who work on exploratory testing in areas I'm learning deeply about right now. I organize practice mobs on areas I work on, but I don't push people to mob, I wait for them to volunteer. I keep the theme out in the open. I point out how the distributed way of working takes us weeks to complete some tasks that could be done in a day together. I share my excitement about doing learning like this with others. But I don't easily go and just book a time when we will do that. I give people time, assessing applicability of my perspectives and slowly moving in the themes of value. And I have an overall goal: I want us to feel happy and included. I want us to feel useful and valuable. I want us to make a difference together through the software we're creating. I want us to be able to say that we get better at what we're doing, every day.

I experiment with everything. The way I mention things and the ways they get caught. The ways I can personally complete a task. With every action, there's a response. And I spend a fair amount of my time finding patterns in those responses. I love the introspection of my own responses. And people around me occasionally hate that I overanalyze their reactions.

I realize I'm a consultant in a way, even if I am an internal consultant, and employee. I'm around to serve my chosen purpose, share my love of testing and great products, and it's ok that the changes I participate in take years and years to accomplish.

Looking back, I'm super proud of what we became at my previous place of work. From monthly releases and loads of bugs in production, we went into daily releases and rare occasions of bugs in production. From individuals avoiding talking to others we went into a well-working remote team that got together twice a week. From me feeling alone with my interests in testing, the change to the team caring for testing and me caring for technical solutions was immense. From people feeling they had no power, we went into a team of strong experts who cared for all activities from value to delivering it. The broke the ideas of working on an assembly line each with our tasks, and contributed according to both our strengths and stretches. We opened every corner of single code ownership and cleaned it up to be team's. We dropped all work estimates, and worked on a limited number of things at a time, delivering things in pairs (or mobs) as quickly as we could. We worked out ways to include work on technical debt, which we understood that came from the fact that we were learning: the things we coded a year ago needed an update, because every one of us was a better version of ourselves now.

When I look at consultants, I wonder if their different style of communicating and more direct driving of change is something I should practice. And I recognize my discomfort. Ir's not that I don't speak out. It's just that my preferred ways of communicating are slow. I like to take my time to see if my proposals will actually improve things. And I see that I regularly dismantle implementations of my great ideas at a time that others did not notice yet that they are not really working.

Not a consultant, yet a consultant. Aren't we all? 

Tuesday, November 22, 2016

New World Problems in Automation

I did a talk yesterday, which I think of being around the idea that in a world where we've found useful and valuable ways of including automation in testing in a relevant scope, what more is there to do on that theme. Surely we're not ready and future (and today) hold many challenges around spreading skills and knowledge and innovating around today's problems.

I keep thinking back to an after conference discussion with someone who I think first my idea of where we can be if we stop fighting against test automation's existence. They had loads and loads of automated unit, component and integration tests. They found their tests valuable and useful while not perfect. But I'm most intrigued with the reminder of how the problems we talk about change when we have automation that isn't just wasting our time and effort.

The problem we talked about was that it takes too long to run the tests. What to do?

I want to first take a moment to appreciate how different a problem this is from the idea of not knowing how to create useful test automation in the first place. Surely, it sounded like this organization had many things playing for them: a product that is an API for other developers to use; smart and caring developers and testers working together; lots of data to dig into with your questions about which tests have been useful.

So we talked about the problem. 30 minutes is a long time to wait. They had already parallelized their test execution. But there was just much of tests.

We talked about experiments to drop some of the tests. The thoughtful reading to remove overlaps taking a lot of effort. Tagging tests into different groups to be able to run subsets. Creating random subsets and dropping them from schedules to see the impact of dropping, like having different tests to run for each weekday so that all tests end up run only once a week.

We talked about how we don't really know what will fail in the future. How end-user core scenarios might be a good thing to keep in  mind, but how those might stay in the mind of the developers changing code without being in the automation. And how there just does not seem to be one right answer.

I have some work to do to get to these new world problems. And I'm so happy to see that some amazing, smart people who also understand the value of exploration in the overall palette are there already. Maybe the next real step for these people is machine learning on the changes. I look forward to seeing to people taking attempts in that direction. 

Sunday, November 20, 2016

Remind me again, why do I speak at conferences?

It was 1997 and all I wanted was to be one of the cool kids in the student union board of executives. I announced my interest, and was standing in the queue for introducing myself. At time of my introduction in front of the large classroom with probably 50 people at most, I was shaking, about to faint. They could see me shake. My voice would escape me. The introduction did not go well, but it changed my life. It changed me through starting to work on my handicap of fear of crowds and public speaking.

With public 59 talks in 2015-2017 timeframe, I can say that the change is quite relevant.

Public speaking is not an inherent talent, but it is a skill we can practice. It's a skill I have practiced, and an area where one is never ready. All it takes is a decision: I will do it. Opportunities to practice are everywhere. Start safe with something you know and care for, with a short talk, with an audience that shares your interests. They want to see you succeed and they are interested in your framing of the same topics. You don't have to travel across the world for your first talk. Talk at your own company. Talk in your local community. Don't worry about failing, we all do bad sometimes.

I've learned not to do theoretical talks as they don't sit well with me - I speak from experiences and cases, even if those cases are full of imperfection. I've learned to take down the amount of text on my slides as my comfort levels of speaking went up. And I've moved from talks to live demos. There is no one recipe for a talk. I find the recipe to seek is bringing yourself to the talk and for me, it's been a long journey of experiments with all sorts of topics, approaches and emphasis.

I recently listened to Agile Uprising Podcast's Women in Agile -episode, and listening to it made me upset. One of the panelists introduced the idea that it's bad for all of us women if a women who shouldn't be speaking (not good enough) gets a chance. It made me think back to the chances I was given to practice. I wasn't always good. I got better by practice. Speaking isn't a one off thing, but it is a journey. Amongst all the average men, why is one average woman framed as bad?

Getting ready to yet another talk, I ask what I've recently asked so many times: why do I bother? Why do I speak at conferences? What's in it for me? As my friend reminds me, there's three things conference speaking gives me.

  1. Network and connections. My network isn't of immediate financial value to me as I'm not a consultant, but I've found (and keep looking for) special people to connect with. People who can inspire me, teach me and keep me honest when I'm learning. 
  2. Strive for learning. Speaking in conferences gives me chances of participating in conferences I couldn't be in otherwise. Many of my colleagues talk about years without being in one, and I go to tens of conferences every year. My unique position as someone who goes out a lot in combination to my personality makes me the person who drives my organizations for better directions. I know what is possible outside my company, and I don't believe in "impossible". I'm never completely happy with where we are not but always seeking for options to do things better at work. 
  3. Setting an example. I speak so that people like me would dare to speak. People who are not consultants  but practitioners. People with severe stage fright. People who don't see people like them on stage, just like I still don't see people like me. We have still unrepresentative amount of women in the field of testing on the stages. 
I try to remember this when I'm in a different country while my son is sick at home and I can only offer my voice as comfort. And I reflect on this as I work to pass the ball forward, to take time to stay away from conferences to work on other projects. 

If you are someone working your way into the speaking circuit, either right at the beginning or anywhere on the journey, and believe my experiences could be of help, please reach out. If I can be a speaker, anyone can.