Wednesday, March 26, 2014

Collaboration review - take the driver's seat

I had my collaboration review today. You know, the annual routine of discussing how you did and how you will develop, the routine that I'd prefer to just become a natural way of how we work together continuously. And as usual, as I want things to be different, I tend to take them differently and pretend I don't know how others do it.

As so many organizations I've been to before this, there's a form to fill out that presumably guides the discussion. The bits in the form are supposed to be filled in collaboration with your assigned manager, and they include points like feedback on the previous year. 

What I enjoy most is taking the routine where someone else plans my future with me into my own hands - it's my future anyway. So I stopped to reflect on stuff I've done over the past year, things I've learned and things that I keep on avoiding.

With the feedback taken care of (doing good job, and my enthusiasm to seek better ways is still surprising to my manager in the difference to the status quo he is used to)  we quickly moved to talk about stuff I would like his support on.

With my preparations, we walked through areas of my work. And as a result, I draw up a silly picture of it.
What I mostly do is testing - with the recent changes, finally with a focus of delivering continually whenever a feature is ready. Continuous delivery is new for my team, we just started with that this week so that will be still the baseline of a lot of what I will do this year. I work with test perspective before implementing anything, and will help with feedback while implementing so that we complete the delivery together. The 'before implementing' seems to be a bigger challenge with us, with a short-term history of delivering the same thing a few times as we learned together too late. I'm pretty comfortable testing and would seem to deliver value in the team in just that. Yet, the application and our implementation does not bring me so many learning experiences right now, more on repeating the lesson on the difficulties of making the choices of what to spend time on and how to track what I learned by now to build on.

On top of that, what I need to work on is my skills on helping the team change its culture. People are much more difficult than our application and how it would be tested if I did the testing. We have somewhat of a role-based idea to software development, where developers do just implementation and I need to continuously work with practical ideas of how we could not assume that the one tester (me) will do all the testing. We'll need a bit more of team building and goal setting work, and it was nice to notice that a team building budget can result from discussing how this goal of mine could be supported by the organization. 

Another area that I felt I wanted to seek into my goals is working on how we measure value delivered. I want to work out ways of seeing if (and to what extent) we're actually delivering valuable features, to move away from counting the tasks. In the last year we've learned that being busy and delivering many "Jira issues" may not tell anything about the value outcome - especially if we redo same things over and over again. Learning to talk about value we deliver might also help with breaking the silo thinking that keeps popping up. 

Third area I brought on the discussion was that I will start coding with the team. Reviewing the code, adding unit tests, and adding features. I realize I will be limited with this, as the trouble still is that while I test I see problems that are there, and others in the team miss them. And I will do much of this by pairing with the developers, who refuse to pair on stuff that I currently do "my way" - exploring. But taking this into my goals of what I do will help me with two things that I hold dear: I get to prove a point of skills being learnable (if I code, why the developers couldn't keep their eyes and mind open when they test) and working on the automated checks on a level where we as a team can't escape into the "task is done but the value isn't delivered"-mode we so easily slip into. 

The final bit on my things to do is the smallest: I wanted to reserve time this year to work out how to run the basic security tools on our software. 

I look forward to another great year of learning. Apparently I'm the only one in my team who actively sets their own direction and negotiates on the contents of the work, but I also feel the reward is that I do get the support I need from my manager. No magic wands available, but a helping hand and perspective.

Wednesday, March 19, 2014

Reading and writing code could be two different skills

Yesterday's workshop 'Brutal Refactoring Game' left me thinking about the regular discussion about testers coding skills. The workshop was about writing beautiful, well-structured code. While I consider myself a non-coding tester, I've done some programming in my years in software development - I still keep realizing that with all the things I could learn that are related to testing, programming isn't that high on my list.

The workshop left me thinking about my relationship with code.

We were supposed to pair up to create tic tac toe -game. With the first smell note of 'no code', we (a team of two testers) googled up a solution to copypaste, knowing that the next smell note would be lack of tests. And that the idea of the exercise is not to show copypasting and googling skills, but actually learn stuff on programming.

We looked at the solution we had, with the idea of adding tests and changing the code so that tests would be possible. We could easily read the implementation, we could see it was not beautiful in how it was structured. And that adding tests on that structure would not be a straightforward task.

We started working with our own solution, to run into problems with inexperience with the actual coding part. So again I faded out to googling, looking at examples with tests. I found some really nice implementations that were a pleasure to read.

I realized I do this as part of my work regularly. I read code, usually with the purpose of understanding what is included to guide particular ideas I would test with. Reading code is not that difficult and it gives me a lot for the testing. I don't read the code to cover it, but more from the point of view of understanding complexities or exceptions, and the scope of the actual implementation.

Just like with the workshop-time googling, I feel I recognize good and bad, and different styles. With the bad ones, I can tell why it's bad (againts a set of expectations I've learned) but it's clear I can't do it better myself. I feel awful when this happens, to a scale that makes me not speak out loud  about it depriving the developers the chance of feedback. Instead of talking about the code, I turn to using the software and showing problems the code has in execution.

So just an idea: could reading and writing code be two different skills, and when we talk of testers needing to code, reading - even shallow reading - might be sufficient? Feeling apologetic for what I can and can't do isn't helpful, and just leads to not optimize what we can do in the team together.

I think I'll try actively doing more of code reviews and talk about my perception with the developers. My lovely team mates would appreciate my effort regardless of my inability to tell how that should be.

Thursday, March 6, 2014

Are we all selling our time or is contracting different?

This post is a longer version of a tweet I posted earlier this week: "How many times can a contractor sell a full-time tester to different projects without losing trust? I'd say one is enough. Need to blog."

In a way, we're all contractors selling our time. As a full-time employee, my company expects to have 37,5 hours of my dedicated time each week. Some of the employers limit my right to do what I want with my free time. And some appreciate that I mix work and hobbies so that a lot of my self-development happens outside project work and office hours. I happen to be employed at a company that is fine with me selling my free time for other companies for money as It was part of the contract and salary level we negotiated when I joined.

We realize that splitting focus is just that - that it can and occasionally will  - lower my presence and focus level even if the hours are full. On the other hand, from fullfilling my needs of autonomy and self-development, there can be support and extra energy  available for the working hours.

On my usual month, my choices bring me to 'selling' 60 hours a week for different types of work. Some of it is paid by different parties, and some is investment into building my professional path that may pay back eventually but also serves other purposes.

With years of practice, this model works for me. I'm happy and convinced I have a career.

While I, on individual professional's level, am fine with how I organize this, I find the very same issue to be different from a contractor (group of employees and employer) point of view. If I, in the role of a customer, contract for a monthly fee a full time tester of 40 hours a week, I don't expect to contract someone like me selling 60 hours a week unless I'm told that. And when I'm told, I can address if I want that.

The employee I'm contracting for may be just as ambitious as I am, and think that their free time is theirs - as it is - and just make sure the hours for contracting are in the right slot and the other stuff happens after hours.

The employer however, has a contracting business to run and develop. With an atmosphere of mutual ownership of the company's future and personal learning emphasis, it's easy to justify other projects on the side. As employee, you might do those with your free time, but from employer point of view, your free time generates profit or is investing into the future the company would hopefully make money of later.

The customer unaware of the level of things that happen on free time, expects your focused effort. And may even believe in 'sustainable pace' and limits of hours anyone should be encouraged to put in.

This all leads me to think that in contracting customer relationship, you need to manage the expectation of what your employees will do on their free time, just as you need to manage the expectation when you sell yourself as an employee. When the customer learns that the person fully allocated to you is now part of a new business of doing trainings, drawing the conclusion that this is the employee's free time used to run employers business feels like a stretch.

From the employee point of view, I support following your calling and taking side tasks that increase your energy. From employer point of view, there's a risk of being half there in the project that needs managing.

Losing trust is easy. To give back trust that was lost, I needed to talk about this in detail. I trust the tester to assess her ability to juggle many things, and I trust she will lower her hours somewhere if it's all too much. But I also deduct from my personal experiences that it takes a burnout to know what leads to it, and feel it's the responsibility of seniority to bring concerns for the younger bright mind to consider.

I still struggle with this, which is funny. I'm fine with myself doing long days for a long time, why is it that I'm not fine with the contractor's employee doing the same?