Thursday, May 24, 2018

More on Jira story to pull request ratio

Today, just as I was blogging away my previous post, one of my team members send me a quick message: "Would you accept my pull request?"

I don't get many of those. There's so many of us working on the shared 'internal open source codebase' that mostly other people get there before me. I've been given rights just as everyone else even if I don't use them exactly as everyone else.

So I follow the link to the pull request, check the repo name and wonder a little, and check the diff to realize it is a one line change. For a small moment, I stop to appreciate how nice the tooling is, showing me exactly what is changing. I appreciated the description giving me context of why the one line was changing. So I pressed the Approve-button.

A minute later, I get a second ping. "Can you merge the pull request? My rights don't seem to be high enough.". I go back, see that my rights are high enough, stop to think about the ridiculousness that someone has again introduced different rights and assigned them this way, and click on the Merge-button.

A minute later, I get a third ping. "I checked downstream things, all worked out well".

Between each minute, I was testing already the exactly same thing the change would have impact on. After all, we were working together, on the same thing, as a team.

This was so painless. So easy. And then I thought about what another team wanted to require of our processes.

For each pull request, there must be a matching Jira ticket "for documentation purposes", because "support needs to read it". The change we just introduced was part of a bigger things we were building, and the bigger thing would require changes to at least 10 different repositories - meaning 10 different pull requests. And the pull request had already all the relevant info. A one-liner of it would end up in the detailed release notes in case someone wasn't into hunting down the info across repositories.

I sighed and thought about stupidity of processes, and decided to write this down.

Don't come telling me that this is needed for a bigger company. This is particularly detrimental for a bigger company. Know more options.

There's a great way of learning about options: listening. There are so many awesome people who speak about this stuff. Pay attention. I try to.

Sticking Your Nose Where It Does Not Belong

There's the things I'm responsible for, and then there's things I choose to insert myself into, without an invite. I have numerous examples, and many experiences on how at some point of my career this became ok and even expected behavior. In the famous words of Grace Hopper paraphrased: Don't ask for permission, apologize if needed. It's been powerful and I can only hope I learned it sooner.


Today, I wanted to share a little story of one of those times I was sticking my nose where it does not belong: another team, another team's choices of how to run their "agile process".

It all started from seeing a written piece defining, as testers, what are the tester requirements for a story to be accepted for testing. This whole vocabulary is so strange to me. As a tester, I am not a gatekeeper. I don't define *my* requirements. Teams negotiate whatever requirements they may have across roles when they are any good. And I would do a lot of things to avoid building the "development" and "testing" phases, even within a change - including mob programming. But the contents of the list were what ticked me on a trajectory this time.

The contents, paraphrased again, were saying that there must be code review, unit tests, functional tests, parafunctional tests, static analysis, documentation in general and in Jira story tickets in particular. But the idea that this was a requirement for being "ready for QA" seemed so off I did not even know where to start.

So I started simple - with a question.
I wanted to ask how you think of this a little more. Some context: here we do continuous integration through pull requests, meaning that a typical Jira ticket could have anything from 1 - 100 pull requests associated with it. We also do releases continuously, meaning that what goes out (and needs testing) is a pull request content not a Jira ticket. Is there something relevantly different in how you work in this case?
Asking this, I learned that *obviously* there must be a Jira ticket for every pull request. It was so obvious that I was cringing because it wasn't. So while I think there are a ton of things wrong with that idea from looking at how developer work flows naturally and incrementally when feature toggles are available, I had one thing I felt the urge of saying out of all the things I was thinking.
If writing a ticket takes 2 minutes, and reading it by various stakeholders takes 10 minutes, I might argue that you could actively think of opportunity cost. The time you use on those tickets is time away from somewhere. Where is the value on documenting on that level? Many teams here have come to the conclusion that it isn't there.
I should have realized to just step out at this point, because I was in for a teaching of how I don't know software development.
Maybe it is not obvious, but things like 'developer checklist' could help to deliver high quality code.. which means less bugs and less cost. If someone would like to discuss about this, let's show him/her "How much do bugs cost to fix during each phase" graph.
 And it continued:
  • Writing documentation - in Jira tickets of pull request size - is essential because R&D is not alone but there are other parts of organization AND we get blamed if we don't deliver as ordered.
At this point, I realize there are fundamental differences not worth going into. There is no interest in hearing opposing views. They are optimizing for a customer - contractor relationship while I'm optimizing for working as a single product company. I've lived years of blameless life that enables me to focus on actually delivering value, they are afraid where I am not. 

Good thing my manager knows that I can stir up some trouble. I may step out, but I never ever give up. The best way to show this is to focus on how awesome my team is at delivering. Nose back where it belongs, until another dig.

Lessons Learned on Two First Weeks as Manager

A few weeks ago, after a long battle, I gave in and applied for a new role: Senior Manager, Windows Endpoint Development. That means I work with two full development teams, handling their line manager duties.

When considering the shift (actually, when looking for reasons to not make the shift) a friend reminded me:
You have always job crafted your tester role to barely recognizable. Why should this manager role be any different in how you end up doing it?
I almost understood what they meant. Now I understand fully.

I've been now in this new role for two weeks, and I barely see any difference. That is how much I had crafted my previous role.

I still test and I still love it. I'm still finding time boxes to test whatever I feel like, and I'm still not taking  tasks from "the backlog" but identifying the most valuable thing I could be doing.

I still look at systems beyond the perceived team / components divisions, following all flows of change into the system we are building.

I still guide us all in doing things incrementally, and the testers perspective is perfect for that.

I still listen to my team mates (now direct reports) for their concerns and walk with them to address things. 

I was as powerful as a tester (with my network of people to do the work with). I might claim I was even more powerful, because I did not have to deal with the "yes, manager - of course we do what you asked" and got to dig into the best solutions defending my perspectives, turning them reality without assigned power.

I never cared for the hierarchy when getting things done. If I learned something now, I learned that others should learn to care less about hierarchy. And that "escalating through hierarchies" is an organization worst practice on the level of actual practical work. I thought others also saw problems and felt they could just go solve them, seeing all obstacles they can get through as potential things for themselves to do.

I always knew many people's salaries. Because I talked with people one on one and made sure it was fair. Well, I told people joining the company my salary for them to know what they can try negotiating on. I also have moved my own bonuses on others who in the bigger scale of things deserved it more because that is what my sense of justice told me to do. I have fought for other people's raises, as well as my own before.

The only thing that is sort of new is the many quirks of recruitment - relocation processes and the work managers do there.

I'm surprised that my new job is my old job.

And talking with the friend again:
I told you you were already doing that job.







Saturday, May 12, 2018

Slowing Down the Flow

This week Craft Conference saw a second edition of my talk "How Would You Test a Text Field?". Regardless of the boringness of the title, I find that this is the type of talk we should have more. 
The talk was recorded on video and will be available later in its recorded format.

What I find interesting though is the stuff going through my mind post talk, thinking through all the things I want to do differently.

The talk had five sections to it.

  1. Introducing a common model of assessing testers in job interviews: "How would you test a text field?" and one way of judging the responses
  2. Testing a text field without functionality
  3. Testing a text field in product context through UI & filesystem
  4. Testing a text field in code context through API with automation
  5. Testing a text field that is more than a text field
As I will not be going to conferences in the upcoming year, I don't have a place to fine-tune the talk to its next generation. Sounds like a great opportunity for doing videos I've been thinking about for a long time! 

The things I want to do differently are:
  1. When testing a text field without functionality, get people to generate test ideas to the same functionality with GUI present or API present - focus on what functionality is in which layer
  2. Visualize test ideas from the group better - use a mindmup. Map them to the four level model of how a tester thinks. 
  3. Teach the model of testing better: I intentionally create first "phases" of idea collection, idea prioritization, and learning from results before selecting or generating a new idea for the next test in the first exercise. Later exercises I allow for prioritized ideas to action, but force discussion on what the test made us learn. When I test, it all mingles.
  4. Force the focus in code context better to just the text field, blur the frame needed to run things out. 
I've been teaching the model of testing before with a story of my sister coming back from her first driving lesson many many years ago. She asked our brother to show her the ropes in our own car, as she felt that after her first real drive she was finally ready to pay attention to all those details. On her first driving lesson, the teacher had made her drive around the parking lot a few times and then surprised her by guiding her right amongst traffic. Her experience reminded me of mine: not being able to remember a single thing. 

When we are learning to drive a car (or to test in an exploratory fashion), we first need to learn all the individual bits and pieces. In the car, we need to remember the shift, the gear, gas and break, the wheel and all the looking around while maneuvering things we have no routine on. New drivers often forget one of the things. Stopping into a traffic light you see them accidentally trying to go with a gear too high and shutting down their car. As they are slowing and turning the wheel to make a turn, changing the gear at the same time feels difficult. So they make just enough room for themselves to practice. Same applies with testing. 

The actions we need to make space for are different for testing. We need to make room for coming up with a test idea and prioritizing the right test idea out of all the ideas we have in our head. We need to make room for properly executing a test that matches that idea. We need to make make room paying attention to the result against both spec and any other ideas of oracles we could use. And we need to make room to reflect and learn about how what we just saw the application do changes our next idea.

Just like when driving a car, the driver controls the pace. Slowing individual activities down is something the driver can and should do. Later, with routine we can combine things. But when we start, we need to pay attention to every individual action. 

Thursday, May 10, 2018

When Your Mind Fails You

I walked down from my room, through the long corridor to get to the conference venue in a big American hotel. I felt great and was looking forward to meeting people. I walked to the registration desk, and while I know many of the conference organizers, I did not know anyone there. I walked around a bit, seeing lots of people but no familiar faces. And I recognized the feeling of anxiety. I was uncomfortable, turned around and walked back to my room, just in time to collapse in a massive panic attack.

I don't know what panic attacks look like for others, but I know they are scary as hell for me. I hyperventilate, lose feel of first my fingers and then feet so that I cannot stand up. My face tingles, like it was waking up from being numb without it having been numb. And the only way out of it is to find a way to calm down. Hugging a pillow helps. Being angry at people close to me doesn't. But blaming some of the uncontrollable emotion on others feels like a plausible explanation, until it happens enough to realize it is something where my mind just plays tricks on me.

The trigger to my anxiety seems right now seems to be conferences, particularly large ones with lots of people I don't know or things not flowing as I imagined. The first one I remember I got from the very first developer conference I ever volunteered to speak at. For the last two years, panic attacks have been a frequent companion to every developer conference, but lately also creeping into testing conferences.

Conferences are too rough on me, so I will be taking a break. Not only because I can't deal with my mind, but also because my presence is needed at home.

I used to be afraid of public speaking, and I trained myself out of it by taking a job that required regular speaking: teaching at university. I still remember what drove me into starting the practice: physically not being able to stand in front of a crowd just to introduce myself. It was crippling.

The panic attacks are more frightening, but also feel harder to control than the good-old fear of public speaking. Over time, I'll figure out a way of working this out. Time teaches things we can't expect or see. It always has.

Monday, May 7, 2018

Changing jobs, setting goals

As I return to office after a week in conference, I come back to a new job. Yours truly is now "senior manager" of two R&D teams. And it was a position I resisted for quite a while until yet another 180 turn to see how things I believe in are when lived for real.

Before I was "just a tester" - with the reminder that no one is just anything. My title was "Lead Quality Engineer" and it meant that my responsibility in the teams was to be a senior senior tester. As someone who has been around a while, I knew that I wasn't serving only my team's developers as the tester, but working on the system to which my team contributed. And just as any other senior senior team member in a self-organized team, I could manage my work, propose improvements for the entire team and drive through changes across what ever organizational limit I felt like tacking.

As "just a tester" who just so happened to also be capable of all things management, requirements, programming and testing, I could model what a team member looks like. I could do things that needed doing, not things that I was told that I need to do. I could show that it is a normal case to have "just testers" who talk to all levels of management and consistently get heard. I could show that "just testers" care deeply for developers ability to focus and work. And I could show that "just testers" change the world on aspects that people believe cannot be changed.

So, now I am a manager. I intend to experiment with a few major things in my new position:
  1. Don't change. As a non-manager, I believed in team self-organization and decision-making. I intent to stick to my beliefs and resist the "managers decide" power tripping that is all too common. I intend to see how much I can do things just as I used to, spending most of my days testing happily. I was available to every one of my now direct reports as a tester, and I am available to them as their manager. Not changing things for worse will be a major effort, and require some candid discussions.
  2. Game the Annual Reviews to Tolerable. As manager, I have to run the company appointed annual review processes with my direct reports. I have hated the process, especially  the part that ends up with emails saying things like "your performance evaluation for last year set during review discussion remained the same after the company-wide calibration process.". I hate stack ranking. And I hate trying to fit people into the same mold over finding their unique strengths, allowing and encouraging job crafting. I have no idea what I do with those, and how much the process allows leeway, but I will figure it out. 
 Not changing will be hard. Already my usual request of "let's make sure we can easily automate tests against  the new GUI technology" was taken more seriously with devs immediately coming back with Proof of Concept on testability in addition to just the prototype, with the half-serious joke of "must do when the soon to be our manager tells us". And a dev just came to me asking to pair test tomorrow - never happened before.


Thursday, May 3, 2018

A lesson from my brother, the developer

"You never talk about your brother!", I was told yesterday as I mentioned I have a lovely brother who is a developer, just a little younger than me that he always needs to keep on competing with me and never quite catch up and who just do happens to work at the same company as I do. 

We don't really work together. Work gives me just as much excuses to call him up as the fact that we're related, and both require conscious effort. My brother is lovely, and really really good developer. He works with identity management systems and I work with end-point protection, so he's on a component and I'm on a product. Recently, he's on a component that has been failing a lot in production and that gets easily blamed even when it isn't, and some of the illusions around that are so much easier to address because I can call him up whenever. 

A few months back, I called him as I was preparing a talk I wasn't particularly into doing. I had originally committed to the talk to support a developer who was new to speaking. They backed out, and left me delivering the talk by myself. So I called my brother to think through what had changed in the last 10 years. 

What he shared was foundational. He talked about how as a young programmer, he got to take a requirement and turn that into code. How most of his time went into writing code. How code he wrote was predominantly Java. And how now when someone joins in as a young programmer, they enter a whole different world. 

Most of a new joining programmer's life is no longer writing code. It is writing code in multiple languages. It is configuring environments (as code). It is tweaking parameters, usually not well documented, to get the third party components to work your way in your environment. And it's not that writing code is enough. You need to write tests. Unit tests. Integration tests. System tests. And as you're writing the tests, you need to explore to figure out all the things you need to test. 

Expectations for a young programmer has skyrocketed. We expect them to start more ready, and cover more ground. 

As a tester, I'm often worried of my mindspace, ability to track different levels of abstraction and keeping quality of my work on a level I can be happy with. Not as perfectionist, but as someone who aspires to be better every day. My brother, as a developer, isn't that different. The world is changing around us for us all. 

We're both asked more each day in our respective professions. The entry level requirements are going up. And with the next generations of future professionals growing through the elementary school now being taught programming from grade 1 onwards, it starts to make sense that programming is an entry level requirement for testers. 

It's more about the foundation, than the active use of it. Seeing the possibilities. Knowing to ask help instead of fighting alone. 


Tuesday, May 1, 2018

Building up to a Treshold

For 1.5 years, I've been with my team as a vocal supporter of mob and pair programming. Getting my team, or any of the nearby teams to mob has been a challenge. We've mobbed a few times on functional testing, once on performance testing, once for purposes of learning TDD together but that is about it.

Being a vocal supporter doesn't mean that I couldn't accept a no. I will not force people into doing things they don't want to do. But I keep on mentioning problems that just would go away if we paired or mobbed. And that people who really like each other wouldn't make the others waste so much time working alone towards a pull request where their early contributions would have made a world of difference.

I see problems of many sorts. Lack of empathy. Not understanding one another. Waiting and building queues. Being less happy, less efficient. Making excuses. Blaming. Avoiding necessary feedback when it is delayed. And I keep believing that we could do differently. We can be ok now, but awesome if we find better ways.

In particular with my teams, there has been one vocal person against the whole idea. When someone everyone else is supposed to look up to is vocally saying what they hate about pairing, it makes it hard for others who are conflict averse to step up and say they disagree.

A week ago things started changing, finally. First one new person joined the team, emphasizing how much pairing and teaching people more junior would impact their happiness. They, for the first  time, stood up as the second strong voice, in disagreement.

It was obvious which side I stood on. Discussions in team emerged, and one by one, people started saying they'd love to pair regularly or pair sometimes. The last joiners clearly joined the now "popular belief" that this was worth doing even if they weren't originally strong proponents.

There's this idea of threshold. That when one person does something, that someone may just be peculiar. But when the group grows big enough, the ones not doing it are the peculiar ones. And as social creatures, we tend to want to be with the in-crowd.

Glad I got to this before they made me a manager. Proved me that long term work and kinds reminders push through without assigned power.

Looking forward to pairing with my team more. And making it a great experience that includes us all. 

So, you're a consultant?

I had just finished teaching a half-day training on Exploratory Testing at StarEast. The group was lovely and focused, 18 individuals with different backgrounds and experiences.

Group on my StarEast Tutorial

We were just about to start a speed meeting event, and I talked with someone I had not met before. They saw that I had a speaker badge, and asked immediately: "So, you're a consultant?". I looked puzzled for a moment before I explained, like so many times before that I was a tester in a team, that majority of my working days went into testing with a wonderful team and delivering features to production on pretty much a continuous cadence. 

The question, however, crossed a personal threshold. It was that one too many to think that I wasn't out of place and fighting against the stream. The default setting was to be a consultant, not an employee in a product development company. It was yet another one of those things that made me happy that I had decided to stop speaking at conferences for now. 

Being a consultant is a great thing. But consultants are a different species. They are more self-certain. They're ok being always on the road. They often live off their analysis of other people's work. They carry a risk that I can only admire they cope with, believing there will be more clients. They get different value out of doing (usually an unpaid) talk at a conference because they have something to sell.

I'm here because I have a strong need to sharing what I have learned, in hopes of finding people who can help me accelerate my learning. I'm not a consultant, but I care. And I'm particularly lucky in being non-consultant with an employer who truly supports me doing this as long as I want to do it. It's just that I no longer really want the travel. Maybe again when my kids are past their teenage years. Meanwhile, my helping presence is online, not in conferences. 


Power dynamics in pairs and mobs


Four years ago, I wasn't pairing or mobbing. Frankly, I found both of those intimidating. Instead of expressing that I was scared, I talked about needing alone time, being introverted and not being able to think when others are too close.

I came back to think about all this today for a great thread of power dynamics in pair programming and TDD from Sarah Mei.


If you ever get a chance of watching a mixed gender group of teenagers, you see some of the gender-based power dynamics at their worst. Teaching programming to teenagers in a mixed group results in the girls giggling, downplaying their abilities and focusing on letting the boys shine. It's easy to think of this as characteristic of the girls up to the point you teach the same girls in a separated gender group. The girls are still bubbly, but now concentrating and doing their best. And their best is often much better than the best in mixed gender groups in general.

The problem isn't men's fault, it's structural. Years of belief systems on how men and women interact. And for women in IT, it often takes years (or a lifetime) to overcome the structures that keep them listening rather than contributing. That keeps them apologizing. That causes them to feel they are not good enough.

We see the same dynamic in conferences. We have loads of speakers who are identified as men. We have all male lineups. And when we talk about including women, we hear that we cannot lower the bar. Yet for conferences doing good work on inclusion and blind review, the shortlists end up being very equal or women dominated. There may be less of women, but quality they produce seem to not lower the bar, quite the opposite. But to get considered, you have to listen to some people's hostility in assuming that you're not up to the bar.

Four years ago, I started first mob programming and then pair programming (and testing). I still think of mobbing as the gateway to pairing in situations where the power dynamics are hard or next to impossible like in my team. Imagine having to pair with a man who tells you "women only write comments in code". The pain of having to sit with that person, alone, is enough for many women to walk out. Their attitude shows in the mob too, but a group of people can help moderate, correct or even punish in ways that an individual on the lower end of the dynamic cannot.

I also remember well the first time I paired with Llewellyn Falco. This is a story we've told many times in our shared talks, yet it was a story that I would have never shared with Llewellyn unless we ended up working on a share talk. I came back to think of this time for one of the Sarah Mei's subtweets:
We had agreed to pair on exploratory testing a new functionality added to the software I was working on.  So we sat down together, I guided him first to get to the functionality just to see it was there. The functionality included a new dialog, and as it popped open, my first words were "I wonder what size it is...". It wasn't intended a question, but very much taken as one. What I meant is that we have an agreement on the resolution where things still must be usable on the screen without scrolling. We were clearly on a higher resolution, and still the dialog was big and clunky. But before I got in another word, Llewellyn picked up on the cue and started showing me tools that enable me to measure the dialog size in centimeters, pixels you name it.

I didn't even understand right there and then that I was uncomfortable. That I felt overridden. That none of the stuff I was trying to show - my work in exploratory testing - got done. Moreover, I'm sure I acted like one of those teenagers, just telling myself that my contributions weren't expected for real. I tried enjoying the results we ended up with, not miss the results that were hijacked from me by a power dynamic.

After this experience unfolded in prepping the talk, we have had great pairing sessions and learned to explore in a pair and mob a lot better. He actively worked against the power dynamic, paying attention to listening instead of talking over me, thinking their way is always correct.

Thanks to Sarah Mei's tweets, I remembered again how far I've come. And how far there is still to go now that my whole team is expressing openness to pairing - finally after 1.5 years.