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.

So...

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. 


Friday, November 18, 2016

Thinking you're the best

I've been to organizations where we talk about "being the best". It kind of strikes a chord with me, in particular for the fact that I believe I'm really, really good testing specialist - and a decent software generalist too. But today, I'm thinking of the risks of thinking of being the best.

If you think you're the best, you think there is nothing to learn from others, and in the fast-paced industry of software development, that attitude would be irresponsible and dangerous. If you are the best, you often view yourself as an individual contributor who may also fear being revealed not to be as perfect as she'd like to be when in collaboration settings.

For years, I prepared in the previous night for every relevant meeting. I went in with a ready-made plan, usually three to prep my responses for whatever might emerge in the meetings. Back in school, my Swedish teacher made me translate things out loud every class, because of my "word-perfect translations". Truth is I had them pre-translated with great effort because I was mortified with the idea of having to do  that work on the fly.

Through my own experiences, I've grown to learn that the pre-prep was always my safety blanket. I did not want to look bad. I did not want to be revealed. I was the person who would rather use 3 days on a half-an-hour task. And I would say it was for my "learning". It was for my "personality". But truth is, it was for my fear of not being perfect.

This might explain why I'm nowadays such a strong proponent of collaboration: mobbing (safer) and pairing (personal stretch). When two non-perfect people work together, the result is magic.

Pull systems

If you've been around agile a while, pull systems are probably a thing you've heard of. This is not directly related to pull requests that are requests to review code, but with pull systems the idea is that in a process with many steps, the step after you determines when you should be producing. This is to avoid inventory (stuff lying around without moving forward) that is a form of waste.

If I think of my testing as a pull system, the consumer of my results is the developer making changes or the business person making decisions on accepting risks knowingly. It makes little sense for me to produce information that no one wants. There needs to be a consumer for that information.

However, the stuff we work on does not include clear cut rules of what people are interested in. No one can tell me exactly what these different stakeholders already know, and what information they find useful, or even more, if their finding something useful is correct as per their stage of learning about what is relevant. So, I shoot some info at them and stop to look at reactions. I try same or similar thing several times and stop to look at reactions, including if they even notice I'm trying establish a pattern. I have a heuristic that at a point they still reject the info and they see the pattern without me pinpointing it, we may be approaching a point where my time is best used delivering a different message. Except that time changes things, so it makes sense to try again later because it was clearly relevant enough in my perspective to conspire on getting the message across in the first place.

There's again a trigger I'm thinking through this. And the trigger is me realizing that pull systems thinking had become very ingrained in me and, as it turns out, some of my closest colleagues. Taken far enough, it means that no information is offered without you pulling it. Broadcasting things in hopes of serendipity can be considered waste.

One of the biggest puzzles for me with the new job in the two first months has been that it took forever before anyone offered me info I did not have to go hunt for. As a new employee, I felt lucky I was not here for the first time, so I knew things from the past and had the means to go for the information. But at end of every day, I've felt exhausted. Every day of work has required all my senses to be fully aware, and nothing has come easy.

I never sensed that this was ill-intentioned as whenever I would have a question, the response was overwhelmingly positive. No one refuses to help me, not by words, not by expressions. They are there whenever I know what I need from them.

And finally yesterday someone voiced out the words "pull system" when discussing my experience in our first ever (during my time here now) retrospective. We've been trained to think of pull rather than push, when we're trained agile thinking.When no one voices the idea of pulling information to a new hire, the new hire can end up feeling overwhelmed and exhausted without a good reason. In my thinking of plausible explanations of the behaviors, values/culture were high up on the list, but my guesses were targeted more towards individualistic culture ("I'd rather work by myself") than the idea of encouraging pull systems.

And there is such a thing as taking pull systems too far. When you're in a discovery process, you don't know what to pull unless you first discover more. Without broadcasting some information, you will minimize serendipity: the lucky accident of something relevant finding you that you did not know you could know.

The world is a balance. I'm still a big believer in pull, but some of the stuff we just need to push. Finding the right balance is fascinating, and I will think about this a lot more with regards to the ways I test. I still believe in teaching my stakeholders to pull information from me, remembering that I'm not the one fixing bugs here in the middle of the night if they escape into production. My expertise is valuable, and through pull system thinking, deemed more valuable by the consumers of the information I provide. But there might be stuff I need to just push through broadcast more.