How do you do, Head of Testing? vol. 3

Quite OK, thanks for asking. I feel like this writing exercise helps me clear my head a bit.

Many have learned by now that “all models are wrong but some are useful” – a saying attributed to the statistician George Box. In my quest for trying to understand an organization and its dynamics, I’ve come across a few models that help me in various ways. At the end of my last blog post I said I will cover “change and a context model for affecting behavior” next. That was a bit premature as I developed another idea of what to show you before I talk about a specific model. Sorry about that but I’m sure you can wait for that one.

I have created an “inspiration board” that contains images, drawings, and schemas that relate to change one way or another. I am fascinated about the nature of change, how difficult it can be and yet how transformative, how mind boggling can be its effect yet how inspiring its results. I am fascinated by how some people seem to be good at nurturing change for others while some struggle with changing their lives for themselves. We cope and struggle with change in very different ways. I believe a great manager is sensitive to this and develops empathy towards a variety of reactions to change. Because after all, managing nurturing change is the managers’ business.

20160825_141422_HDR.jpg

The title of the board reads “Restart heals all wounds” – written by a colleague who handles our Atlassian stack. The drawings at the bottom and the PFUDOR are not related to the inspiration board.

Satir’s change model

satir change model

Satir’s change model is a classic, I think. I find the model helpful when discussing the perception of the same situation. Once during a team retrospective, I asked people to mark  on the model where they thought we were: in late status quo, in deep chaos or in our way up. It was a way to bring awareness of each others perspective: some felt we were in the middle of chaotic change and were not approaching the end of the tunnel while others felt like it was no big deal and things were stable. That will lead to discussing how your team members react to the same events differently.

When I look at Satir change model, it reminds me to ask myself where I think I am in the process and where others are. Maybe we should have a chat about this? Also, the model reminds me that it may be hard to know when the chaos will come to an end, and that may strain me and others if we pile more change on top of what we’re already going through.

However, I think there’s something that this specific representation of change biases us towards: when you look at it, it hints at the outcome of the change to be “higher” and “better” than what was there before. It may be so. It may not be so. Sometimes people can’t stand to go through the process and quit, there’s a lot of resistance, or the change really hurts the people and the system, so you may end up with lower productivity, satisfaction, what not.

Managing complex change

complex change

This table reminds me to think of components of change. Sure, there could be more added to the list. But conceptually, it helps me analyze what pieces I have already thought of, and which I’ve forgotten about. I can say that I have personally experienced many of the emotions or effects and can very much relate to this matrix. For instance, I remember in great detail how I felt when I was trying to “make testing happen” at my previous job. I had the vision, incentives for myself, and some kind of a plan but I felt anxious because I knew I didn’t have much skills or knowledge about testing. I also had very little resources, so I felt like David taking on Goliath. At the same time, there were many who were to be influenced by the change of bringing testing into the organization and they lacked the incentives to seriously give it a try. Hence the resistance and belief in the “good old ways”.

And of course, I’ve had my share of false starts when I haven’t considered putting together a useful plan.

When I look at this model, I also think of the extra stuff in each box that is not spelled out but is there. For example, a vision in my head or on a page is not enough. It needs to be communicated, stories need to be told, discussions need to take place. Skills are not simple matter either: awareness of skills is a big step, teaching and learning new skills is a whole big process on its own.

Interestingly, the matrix is from a book about climate change. Inspiration can be found anywhere!

Process improvement

processimprovementõ

It’s curious that the top right-hand picture looks similar to Satir change model. They both have the same bias in common, though: that once change is carried through, things will be better.

I realize that the pictures about process change are really simplified. However, I think they illustrate many people’s experience well, even if using anecdotal graphs. When I look at these graphs, they remind me to ask the question “why”. Why have the previous attempts failed? What did the people do and how they approached change? Why did they approach it this way?

I’ve observed that some unwanted effects of change are blamed on the “object of the change” (i.e. the new technology that was introduced “sucked” and wasn’t the right one) while nobody seems to ask if the people introducing the change were skilled at helping to make it happen, nurturing it, and supporting the process.

Through a few more or less painful lessons (and thanks to PSL), I’ve come to understand that just knowing how some new stuff is supposed to be like is not enough. You need to understand process, how to facilitate it, how to support the process to successfully change something. So these graphs also remind me to focus on the process and not “abandon” it.

Just to add another twist, it also reminds me to consider when it might be the time to let go and not be the victim of sunk cost bias.

***

So there ya go. I will cover more pieces of this board in later posts.

What do you use to help you be aware of different aspects of change?

 

How do you do, Head of Testing? Vol. 2

Thanks for asking. Still tired but I made some good progress on a project I’ve been working on for about 6 months. I actually slept better after finishing this draft. But that’s not today’s topic…

Today I want to reflect on jam and systems. Jam systems. Jammed systems. Systemed jam. Systems of jam. I need to stop before I can no longer say “jam” and still understand what it means.

***

I really like raspberry jam. Even if the seeds get stuck in my teeth, it tastes like summer. If you are a manager and have not heard of the Law of Raspberry Jam, I’m sure you have felt it. Jerry Weinberg writes about the Law of Raspberry Jam in his book The Secrets of Consulting: the more you spread it, the thinner it gets. I learned this as a team lead at my previous job where I tried to build up testing and fix everything and anything that was wrong with quality.

As a competence head, I’ve now learned that the higher you go vertically, the more you are in danger in spreading yourself too thin. It’s an asymmetry that probably can’t be helped and that C-level executives probably know better than I do: the higher you go, the more there are people who place demands on your time so that your time becomes extremely fractured. It’s just there’s still one (jar) of you (to spread across those demands).

Managing one’s energy is important to be able to work on and achieve stuff continuously and in sustainable manner. Managing your energy well also means you know your priorities as you will spend it only on important things. If only it was easy to identify priorities when all opinions are different and contradicting… But there’s always something you can observe that can tell you what’s important to achieve and whom to get support from to succeed.

Being a manager, I’ve found systems thinking to become increasingly important for uncovering organizational dynamics. Combined with sketching it allows to visualize the system and its parts which is a great exercise for clarifying your own thinking. So after a couple of months, I was able to sketch the organizational dynamics that I considered detrimental to its strategy and goals (and to my goals), and the visualizations helped me discuss it with others. Making changes to the organization at this level was not in my scope or under my influence but at least I could express my concerns, and point at potential obstacles.

There was a downside. Once I understood (or thought I understood) how the organizational dynamics worked, I also saw how all the things I thought of trying to bring about change would fail. It’s entirely possible that someone with a different mindset would have only seen opportunities not obstacles.

I see opportunities too. I’m simply pessimistic about overcoming some of them. Especially those that get perpetuated in the organizational structure and behaviors. This is quite abstract but here are a few heuristics to use:

  • what gets talked about in all-hands-on-deck meetings held by C-level management
  • how managers handle requests for collaboration coming to their team or going out of their team
  • how much awareness and knowledge there is in one team about what kind of practices are used in other teams
  • how much slack people have to attend trainings (either internal or external)
  • how much energy and time are people willing to spend on internal educational or social activities
  • how much time do people spend talking about each other’s work (and in what tone) at the coffee machine
  • what kind of objectives are managers driven by primarily
  • how many spontaneous initiatives you see popping up without having to use a stick to get someone do something

The list could go on. Some of these observations can be made within a couple of weeks if you’re new to the organization. Some of them may take longer. Eventually, by observing these behaviors and then investigating the sources of them, you start getting the hang of the system.

For example, if you keep hearing how people “don’t have time” for this or that, then in addition to listening their stories (and justifications), it’s worthwhile looking at how the system structures the use of time, what kind of actions control it, and what kind of other behaviors are related to it. I find that “lack of time” mostly comes down to priorities and preference, hence, it’s informative to learn what drives those.

In systems thinking language:

  • where are the flows and what is their direction;
  • where are the stocks and what’s their relation to each other and the flows
  • what are the feedback loops like in terms of strength
  • and so on

In case you’re new to systems thinking, check out Thinking in Systems: A Primer by Donna H. Meadows. I think it’s a wonderful introduction to systems thinking.

I had an understanding of how the structure of a system affects the behavior of the system and its parts. I mean.. .isn’t it obvious when you observe any kind of system, especially one that contains humans? Reading Meadows and getting more into systems thinking in general, has helped to make my thinking clearer and has helped me understood the system within which I am operating.

As Meadows has elegantly put it, “System structure is the source of system behavior. System behavior reveals itself as a series of events over time.

This sums up quite well why I think it’s essential for managers to be skilled systems thinkers. Surely you can affect the behavior of some humans in the system who may then help you change the system (maybe you end up being a bunch of revolutionaries on the chopping block, who knows). However, without understanding the system, it will be hard to direct your efforts. Remember the spread jam? Exactly.

I see my work mostly to be about affecting the system and some of its structures so as to help change in behaviors to emerge that would improve the system, and that would make it sustainable and resilient. (It could also be that I attempt to remove jam from systems or get them “un-jammed”).

But how to do that? I don’t have a magic bullet but I’ve tried and failed and tried, so that is what I’ll cover in my next post: change and a context model for affecting behavior.

***

Now where’s my raspberry jam…

 

How do you do, Head of Testing? vol. 1

Thanks for asking. To be honest, the answer depends on the type of day I’m having. Downward spiraling direction can be found in my days more often than not recently. Ah, I should finally take the lesson from Benjamin Zander about those spirals and ditch them. And also remember rule #6.

A bit more than a year ago I started out with the goal to help testers in the company do a great job. It looks broad and sounds idealistic but it was as good as any mission to take as a starting point. I believed I could find a way to rally people behind initiatives, ignite their belief in change, and help them engage and drive testing and its development. At the same time, I had to figure out what the role of a competence head means…

I couldn’t be everywhere and put my hands into and onto everything, I knew as much. Some groundwork needed to be done or so I thought. Understanding the people and the system, its influences and boundaries was my first goal. So I set out to have long discussions with almost all testers in the company. I didn’t believe in picking and choosing just a few because, naive as I am, I believe all people matter and play some sort of role. So I did that, spent quite a lot of energy and didn’t get much of it back.

I gathered a lot of information in notes, impressions, memories, stories by doing so but then trying to analyze and systematize it ended up being a painful and somewhat confusing process. So I learned that sometimes there can be too many different answers to a limited set of questions. Some patterns may emerge but it may only be your own biases that make you see what is not there. But interpretations you make are very real in your mind. Piecing the information together to describe a big picture of the status of testing in the company through the eyes of testers took me a lot of energy and didn’t give much back.

It also made me think of how I chose the questions. I tried to cover a vast spectrum: understand the person’s history in testing, their knowledge and habits in testing, evolution of testing in this company through their eyes, problems and issues they see, changes they hope for, etc. Looking back, I’d still talk to every single person but be more careful and selective in the questions. I could easily come up with a convincing rationalization why I needed each and every one of those questions, what kind of information they would yield and why I deed this information… My mind is really great at such things. However, excess of stories will make the load heavier than it needs to be. This takes energy and it’s difficult to get it back.

As a systems thinker, I’d been noticing signs of barriers between people. Detecting barriers in an invisible system of people in an organization and off the org chart goes like this: you run face first into something, scream in pain, curse and cuss, and try to determine the culprit. It’s just that you can’t see it but can trace your fingers across air and lightly touch… something. Imagine navigating a glass labyrinth where there are people almost within your reach, only to brush your fingertips against the glass. Some cold drafts sweep past you. Eventually you determine that the actual office layout has an uncanny similarity to the labyrinth. Why, both have glass walls through which you can see people but not interact with them very well. So you turn your back to others and mind your own business with the people next to you. Observing this is emotionally taxing and takes energy that I can’t get back.

So I sketched the organization on paper to visualize issues, and discussed it with some people. In addition to all the other things on my plate, I started trying different things to see what could increases osmosis…

More on that in the future. I’m starting to ramble and wax lyrical about glass walls. That ain’t gonna give me the energy back.

 

Takeaways from a Pitching Masterclass

Pitching is 95% practice and 5% inspiration. -Annette Kramer

A couple of weeks ago I attended a pitching masterclass by Annette Kramer. It’s part of this strange habit I’ve developed that I watch masterclasses on Youtube to pick up ideas for my own coaching sessions. Now I decided to watch a live one. But more on that in some other blog post…

I learned things about conducting a live masterclass including interaction with the audience. In addition, I also picked up a few ideas that I believe would be useful for testers. Communication skills are among the core skills of testers and I’d say pitching is a subset that could be useful to have in your toolkit.

Format

This masterclass focused on the 3-5 minute pitch format which, according to Annette, is the hardest pitch to do. This is because talking for longer is easier – you have time to expand on your points (though you may water down the content this way…). The masterclass was mostly targeted at different business representatives who need to do pitching to investors or potential business partners. We had a good mix of people: from a startup pitch to looking for partners for school software to a showroom rep. Therefore, it was great to see exampels of pitches for different audiences.

Annette live-coached the pitch makers starting from how they walked to take their spot, to how they stood, how they expressed themselves, and she also re-engineered the flow of their pitch on the fly while also including the audience in giving feedback. It was inspiring to look at how she worked with people.

Selective Hearing: Lessons in Communication

Annette says that when an investor listens to a pitch, they hear “blah blah blah will I make any money on this blah blah blah when will I earn money back blah blah”. When a potential business partner listens to a pitch, they hear “blah blah blah will this make me look good blah blah will I make/lose money with this blah blah”.

How does your audience listen and what is important to them?

Do you focus more on what you want to say or what they want to hear?

During the past year I’ve dealt with C-level and other directors and managers more than I previously have, so this one hits home and is a good reminder. I know I frequently fall into the trap of thinking more about what I want to say and what I hope the effect to be, rather than doing more listening to be able to target the message better. And understand the people I work with better.

From observing a number of testers over the past year, I think there is an important takeaway/reminder here: when talking to your manager (or some other stakeholder/decision maker) about testing, don’t focus so much on your specific testing problem but on the impact of the problem. When focusing on the impact of the problem, you can think of what that manager/stakeholder sees and what they’d like to hear. I bet it won’t be some testing-specific talk about the issue you want to address or the idea you want to introduce. I bet it would help you if they heard “blah blah solving this will make us look good blah blah blah solving this will mitigate the risk of not fulfilling financial goals that  a director somewhere set me blah blah blah”.

That being said, I really liked and I agree with Annette’s proposition that you can’t sell or push ideas on people – it’s much more liberating to think of pitching as a way to offer people an opportunity. So this is why you need to know what your audience cares about and is interested in.

I don’t do pitching on the stage to my managers but I treat some hallway conversations or situations at meetings as micro-pitching opportunities. I have a lot of ideas and I keep looking for ways to get buy-in or traction to take the ideas further. I don’t always know which ones get better traction which means I need to pitch them several times to different people. Which takes me to the next takeaway…

Process. Process Everywhere.

Annette emphasized that it’s useful to think of pitching as a step in the process, and to keep the process in mind (not the result). The goal of the pitch isn’t to close the deal because hey, that hardly happens so easily (or right after a pitch).

The goal of the pitch is to get people asking questions, to keep the conversation going. When I later talked to Annette about it, she said that we do this outside work all the time. And I said, “Oh, this is why we have friends… because we keep the conversation going and this is a process”.

When trying to approach a decision maker with an idea (which probably will take up time (=money) and money, so there are considerations in their mind you may not know about), don’t think of it as a “make or break” situation at the first try. I find myself sometimes doing this exact thing and then getting frustrated. Well, that’s not helpful, is it? And it’s not helpful because if I focus too much on the result, I forget about the process of getting the result. Introducing new ideas in organizations can be difficult, so focusing on the process, focusing on starting and keeping the conversation going is helpful.

Mean It. Clearly.

It was fascinating to watch Annette pick up the difference between when the speaker really meant and believed in what they said and when they didn’t because they focused on what to say (or remembering what to say…). I observed a significant difference in this person’s body language and facial expressions in the pitch after Annette had made some adjustments and asked them some questions to help them discover what they actually meant.

And I mean if I could pick it up, so can you. And other people will pick it up about you. Here’s another takeaway: don’t be abstract, be specific. It will be hard for you to say it like you mean it if the concepts you use are too abstract (and it will be hard to grasp).

Annette did a great job helping people to be specific and get the real meaning out from behind the words. I think this is also a process: you start with an idea, and through practicing a pitch for it, you peel away layers and arrive at the core that will be specific and clear.

We also addressed the issue of using jargon and how this makes attempts at being specific revert to being abstract (“What do you mean by [this thing]?”). I’ve also observed in testers that they tend to use testing jargon when talking to stakeholders who don’t know anything about testing (or don’t care about it…). It’s a similar point to that above: think about the audience you have and what they can understand and want to hear (probably not jargon). Focus on the problem that they feel related to. Annette pointed out why TED talks are so great: among other things, the speakers avoid jargon (so that everyone can understand what they’re talking about).

And don’t talk on autopilot!

Autopilot leads to not really putting yourself in the words you’re saying and you end up “just talking” not delivering a message.

Annette had a great tip for this: remember why you care about what you do/say BEFORE you say it.

***

I’ll blog a bit more on the pitch structure and other takeaways in another post.

A Hot Pink, Feathery, Blistering TestBash

IMG_3751_Fotor.jpg

When walking down the street in a bright blue Ministry of Testing T-shirt, hot pink feather boa, and grey Crocs in Kemp Town in Brighton on a Friday night, you blend right in. Nothing to worry about.

TestBash is one of the events that feels more like a community gathering or even a family get-together than a conference. Of course, this really depends on what your definition of a conference is… Having just got back from my second TestBash as a volunteer, I’m happy to report that TestBash stands for everything a good testing conference is about for me – passionate professionals, curious newcomers welcomed to the community, meetups, family vibe, top-notch talks and workshops, high energy, a little bit of cool and flair and craziness, great humor, fountains of inspiration…

However, the beginning of TestBash was worryingly blistering for me. Quite literally, I arrived in Brighton only to limp to the hotel in pain.  Newish shoes caused serious damage to my left heel. Never have I ever seen such a big broken blister on myself. I was sitting in my hotel room thinking I had to stay there for the whole time… But then it’s all about problem solving and reaching out to people, right? So I cleaned and patched it up, took a taxi to the pub where the pre-pre-TestBash meetup was supposed to take place, and was so happy to hug Rosie that I cried.

And then I got to talk to some friends in the pub and things were looking up. The next day Rosie brought me a pair of Crocs as I couldn’t wear my own shoes. And I was good to go running around in Crocs to facilitate the two workshops, make sure things run smoothly, problems get solved, and workshop leads can focus on their work.

The Workshop Day

First happening of the morning – taxi tried to take me to some other location than that of the workshops.

Ash Winter’s workshop on system architecture and testing the bigger picture contained lots of group work and exercises that layered models through learning cycles. Ash asked participants to visualize a system architecture through some analogy. For example, authentication got visualized using the analogy of a party – who’s allowed to get in and who’s not, and how this system works. There were quite a few others. Even though this analogy is yet another model and does not represent technically what authentication does, it helps to familiarize the concept and some elements of the system. As someone who still needs to learn the ropes of such things more deeply, I find this exercise helpful.

Then it was time to build a model of the architecture based on snippets of information from different sources. Then we learned about FIBLOTS by Scott Barber to layer it on top of the model. And then the heuristics of testability by James Bach were used to identify places in the architecture where testability could be improved. Overall a great workshop by Ash, so if he happens to run it elsewhere, surely check it out!

The second workshop of the day that I facilitated was by Alexandra Casapu and it was focused on examining testing skills. I attended this workshop at Let’s Test 2015 and found it to be an excellent balance between individual reflection and reflecting in a group – all focused on understanding skills. There are exercises that direct you to dig in the past and exercises to observe and discuss skills in an actual problem solving situation. I recommend you attend this workshop when you have the opportunity. Meanwhile, you can work on mapping your skills on the website Alexandra created: testing skills map repo.

In the evening we went to Brighton beach and had some beers, had some fun, talked about stuff, got tattooed, too. Radomir Sebek spent some time on the pen challenge with his colleague from Berlin. I had some great conversations with folks. As a result, I’m looking forward to a blog post from Kim Knup about the “5 minute feature pitches” they do at Songkick and, hopefully, a talk by Beren Van Daele at a conference (through Speak Easy) who accepted the challenge. He already completed another challenge: he did a 99 second talk at TestBash! Also had a very nice chat with Phil Harper. And Danny Dainton. And… oh, you know the meetup stuff🙂

TestBash Day

I woke up bright and early and it was going to be a beautiful day. I enjoyed a rose&pistacchio mocha, then waited at the Brighton Dome’s backstage door while observing a pair of seagulls sharing the remains of a pear (it looked like it), and watched an unassuming squirrel go about its stuff.

Once Rosie and other volunteers and helpers arrived, we got signed in, got our backstage passes, and we made our way to the sweet spot. Emma and me did some prep for the Lean Coffee session we were going to host. It would’ve been more work for us but there were some experienced “lean baristas” at the tables who knew the process and could help folks for whom it was the first encounter with such format. I already figured a cool visual guide would help in this case as it wasn’t a space where you could yell instructions, and people were spilling in continuously for a while. The list of topics collected from the post-it notes is available on GitHub.

wordcloud

As far as the conference talks were concerned, I found the content of talks to be consistently strong throughout the day. The videos will be posted at the Dojo site later and I recommend to watch them all. Probably the most emotionally moving talk for me was Nicola Sedgwick’s about thick skin and caring about what you do which somehow makes everything much more stressful. Since I was on mic duty, I was trying to maintain dry eyes.

Bill Matthews made us feel a little discomfortable as he shared the challenges of testing smart algorithms. Lisa and Emma had packed a lot of wisdom and practical advice into the talk about building the right thing. Michael “Wanz” Wansley masterfully delivered a somewhat controversial talk about gatekeeping, and we could get a wiff of Grammy dust along with it. A totally non-grumpy Patrick Prill talked about ignorance, knowledge, and the Mount Stupid (and it was his first conference talk!). John Stevenson broke out some techno to remind us of model fatigue, encouraging us to be more creative with models we use. Katrina and Nicola made sure the Kiwi front was strong by talking about a pairing experiment, and being the sole tester in the team respectively. The lovely Dan Billing discussed the importance and necessity of security testing. Anna and Andrew discussed how “testers doing the coding” is the least of your problems when trying to move to test automation.

Sometime during the day I contracted a hot pink feather boa. You know, just to make sure everyone knows I’m a volunteer not some normal person attending the conference. Others were seen toting tutus around different body parts.

CdcfHu8W4AEse91

Photo: courtesy of Jokin Aspiazu, my favourite Spanish tester (from left to right: Guna, Huib, me, Pekka).

I’m sure there was something for everyone to take away. The crowd was supportive and emotional, there was a great vibe throughout the whole conference.

As the final event, there was a gathering at another pub, and also a poetry slam to which I arrived somewhat late (sorry, I was having a convo downstairs). But I delivered my post-apocalyptic stream-of-consciousness poem anyway. Well, at least Mark was blown away😀 And then I had other good conversations (some brief, some longer) with Noah, Rhian, Mike

It was also incredibly great to meet my PSL buddies Chris, Lim and Ioana again. Gotta say – “PSL buddy hugs” are of a special kind!

Then I took a stroll in my aforementioned outfit, got a bit of sleep and headed to train station through foggy Brighton.

All the love to Rosie for having me (and for the Crocs!). All the love for the community that came together. All the love to Brighton for being wonderful.

I hope to be back.

TestBash Poetry. Post-apocalyptic Stream-of-consciousness: A Project Wasteland

By Mark Tomlinson’s request, here’s the poem I wrote for the post-TestBash meetup’s poetry slam.

Recommended soundtrack: Pendulum – Another Planet

Curiosity crawls across

the craquelure wasteland

crows peck at the empty casks of bugs

hollow echoes report

passes in passing

failing at failures

nitpickety checking machines

trawling and harvesting ungrown

premature fetuses of bugs

a scrum master was seen

scrambling to escape the

creepy crack in craqueluresque surface

of the planet known as The Pisshole

he was never to be seen, we lost the visual

herders cajoling lines of code

snappy whips and contraptions

squeezing petrified lambs of code

faster harder

towards the horizon of deadline always

always too close

fearfully frightened of falling

into darkness

sliding over the edge of the known land

finding solace in the abyss of failed  projects

curiosity turns into dust

fat rolls of dust

waves of dust in an ocean of boredom

and certainty

silence slithers hand in hand with hopelessness

nothing new, nothing arousing

appears until a barometric change

rolls across

swish! swirl!

feathering swarthy faces and ghostly white eyes

’tis coming! ’tis coming!

lo and behold! dark and full cloud

in need of emptying rumbling

over the dry forgotten land

trickling, tinkering, letting go

torrents of inspiration

penetrating the craquelure

transforming, filling up

impegrating immortality

thunder approaches, voices distinguished

and nurtured by desert ears

tickling neurons, zapping grey matter

praise the voice of the community

we might be out of the woods

***

I’ve been writing stuff – short stories and poems – since I can remember myself. When I was 11 years old, I stumbled across Sylvia Plath’s poems (The Colossus and Other Poems in English with Estonian translations) and these changed how I wrote poetry and how I perceived what’s possible in poetry. Sylvia’s poems liberated me from trying to rhyme and showed me the power of imagery and word play, contrasts and emotions.

2015: A Bipolar Year

I mostly write this review of 2015 for myself because I’m good at forgetting the good stuff. There shall be personal stuff in the post, so you’ve been warned it’s not only about testing.

The Darkness

2015 was a weird year. There were some great things that happened in my (testing) life and career but also some things that really stretched my capacity for grief, that ended some traditions, that ended my family as I’ve known it for a long time. I woke up in New York in the middle of the night after TestBash to learn that I have no more grandmas left. I lost both of them within less than a year. And cancer ate up a close family member. He was a couple of years younger than me. It’s one thing to lose someone suddenly, it’s entirely different to see your loved ones suffer and turn into people you don’t know, to see them in this state and realize their life is over very soon, or hear “there is nothing we can do anymore” from a doctor. I’ve been to many funerals in my life. You’d think it gets easier but it’s tougher in a way because you know exactly how you will feel and you still have to go through it. The nice charts of stages of grief are a load of bullcrap anyway…

The Highlights

There were some great highlights for me in 2015 beside the darkness (which is why I call 2015 a bipolar year).

Work

I started my job as Head of Testing in February 2015. That was a step in a different direction for me as I’ve previously worked as a team lead. So now I’m the competence lead for testing in a 600 people organization.

Conferences

I spoke at Copenhagen Context and TestBash New York.

You can listen to the podcast where I discussed my talk with Mark and you can listen to my talk here: https://dojo.ministryoftesting.com/lessons/the-story-of-a-strange-seed-helena-jeret-mae

I was the program chair for Nordic Testing Days. Technically, I put the program together already in 2014 but I was involved in marketing and different kind of activities behind the scenes up until the conference (and then ran around frantically while my testing friends tried to tell me to calm down). I was a nervous wreck for the fact that quite a few speakers had to be replaced during the months leading up to the conference as they dropped out for one reason or another, and one of them dropped out the night before… I was extremely grateful for having three presenters immediately offer to do a talk, and great kudos go to Katrina Clokie who ended up doing one. In the end I was satisfied with how the program turned out because my goal was to help create a conference that I would like to go to. The theme “Agents of Change” was close to my heart and it looks like it touched other people, too.

Erik and me got accepted to Let’s Test 2016 and we’ll be doing a workshop there!

I attended Let’s Test 2015 which was awesome. After that I visited Erik’s class of future testers in Örebro.

I was invited to TITANconf by Kristoffer Nordström and spent a couple of wonderful days in Karlskrona discussing leadership and testing in the company of a bunch of great testers across Europe. I mean we had a dedicated conference beer! What could be better…

I also attended the fifth PEST (Peers of Estonian Software Testing) where we enjoyed the workshop Kristjan Uba had set up for us. We were trying to figure out if testing craft was social or technical.

Problem Solving Leadership

A very important highlight not only because I met Jerry Weinberg and ravaged the bookshelves in his house (twice!) but because I learned a lot of useful stuff that I keep going back to (this must be the PSL-ers’ mantra). I definitely don’t look at the world the same way after learning from Esther and Jerry.

It’s also no less important that I could attend PSL with my friend Erik. I’m pretty sure we doubled the ROI between the two of us by having discussions and analysis sessions during the workshop. In any case, he’s one of the people who kept me sane last year.

Learning

I learned about how to figure out what my job is supposed to be (a surprisingly unobvious thing that I hope to blog about). I learned that doing research and collecting data can be useful but also incredibly frustrating if you can’t make sense of it, and can’t find a good way to make sense of it. I also learned how it feels to be somewhat afraid of your research results

I learned about designing and carrying out workshops and retrospectives. I ran a couple of workshops alone in the offices where I travelled to. In collaboration with my colleague Siim Sutrop we designed and carried out a workshop for tutors who would be teaching a batch of newbie programmers. We also designed special retrospectives for the tutors and the newbies separately to gather their feedback. And now we are on to designing and testing a framework for helping the tutors to learn to tutor. Since Siim has been experimenting with retrospectives in his team, I got to sponge on his experiences.

I learned how to run a Lean Coffee. I’ve run the events internally and also facilitated the first public Lean Coffee in Tartu.

I learned about change management and change patterns. Some of it I knew, some of it was new. I want to drive some changes, so I need to know how this works. Luckily, I have a new colleague now who is the change management manager and I can learn from hear (trust me, I’m like a sponge now) and we make a great team, too.

I learned to look at testing and testing problems in a 600 people organization spread across 6 countries. I love systems thinking because without it I’d still have blinders on (or maybe I still do, who know…). I’m not sure I advanced my knowledge very much about testing topics this year but I did learn a lot about how testing looks like to a wide variety of people on different places in the hierarchy.

I learned about understanding my skills from Alexandra Casapu in her wonderful workshop at Let’s Test. I had some discussions with her afterwards and shared my thoughts on the workshop. She also created a prototype webpage for building your skills map. I’m planning on creating a similar workshop for testers in my organization.

I learned about career development and job descriptions. It’s difficult. Really difficult. I will have to write about this at some point to explain. When it comes to the seniority levels, my instict says “RUN!” because people are different and “cookie-cuttering” them doesn’t make sense. I don’t personally care for the junior/senior distinction because I’m looking at the content of my work and the value it delivers (and I look the same way at others’ and I don’t care that much about seniority). But it looked like these things are important for other people, so I tried to document the skills and knowledge for each level so that it still makes sense to me. There’s still work to be done.

I learned to hate the word “guidelines”.

I learned about how HR works as I supported them throughout the year.

I learned that (internally) consulting a project that was messy is hard. I need to go back to Weinberg’s “Secrets of Consulting”. I guess the good thing was I was able to identify someone to take the lead in testing matters and help her enough so that she succeeded and is still going strong.

I learned that joining sketchnoting skills and systems thinking can be nifty. I sketched the organization from different angles to explain to C-level where and why I saw problems that they could help to solve.

I learned that I really like to work with people to help them grow. But hey, I actually knew this before🙂

I observed that if I keep thinking and sharing my thoughts, chances are I will hear them repeated at some point. Not sure what I would learn from this but hey…

I learned… probably many other things but these have already been incorporated with my existing body of knowledge.

Travelling

I travelled to 3 new countries for work purposes (Lithuania, Serbia (2x), Romania (2x)). In Romania I had the pleasure of having some beers with some folks from Tabara de Testare. In Belgrade, I managed to meet Predrag and talk testing next to some great Serbian food. And I guess we’ll have some great Estonian food and beer in Tallinn as Predrag will be speaking at Nordic Testing Days in June.

I travelled to the US twice (for TestBash and for PSL). I also travelled to Denmark and Sweden (Copenhagen Context, TITANconf).

I travelled to 3 new countries for vacation purposes (Slovakia, Austria, Hungary).

And in the process I had layovers in Finland, Germany and Latvia. That makes 12 countries visited… Yes, at some point people asked if I was still working or only flying around because it looked like I was departing somewhere every few weeks. Last autumn it was somewhat true…

Testing Stuff

I signed up with Testlio to do some hands-on mobile testing and to understand how their platform works. That was fun and also allowed me to polish my self-organization skills because one has to be efficient to get the most testing time out of the 1 or 2-hour slot.

Other than that I did very little hands-on testing. Which is why I this part of my brain gets itchy and I need to find some way to scratch the itch this year (and also to not let my skills atrophy too much). Helping other people to solve their testing problems is one thing but I don’t feel like it would keep me very fresh.

I guess that’s it. Sorry for another mammoth post but that’s the way I roll.

Here’s to 2016! I know you will be awesome.