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?

 

Advertisements

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…

 

Taking My New Job By The Balls, Part 1

In April 2014 I accepted an offer and in June I left the company I’d been with for the past 6.5 years (4 years as tester/team lead), and started my new job as a senior testing specialist at another company. These notes/remarks/observations in the upcoming series of blog posts are based on my first 2.5 weeks on the new job. Orderly notes and thoughts are not guaranteed. Also, a lot of the things here may seem very obvious to you (they already start looking very obvious to myself as well…) but that’s OK. I mostly want to share my journey and I want to have at least semi-digested notes for my future self because I have come to appreciate the value of introspection more and more, and the valuable learning I get out of it. And… I’m also seeking the comments and remarks of other testers who recognize the questions I’m trying to answer and the problems I’m trying to tackle.

Some background

Since I’ll be writing a few blog posts about the balls of my new job, I expect most of the details of context and background to emerge from several posts instead of one lengthy intro. However, for the sake of a little clarity, here are some notable details:

  • then: used to test a product 30+ years on the market, 2000+ customers; now: beginning stages of a software project for a single customer
  • then: built a team of testers, 2 of them coached and trained by me as newbies; now: 2 testers plus me on the project team, both have previous experience but have been “lone testers” on projects up until now
  • then: no specs, no business analysts, various people partially filling that role (including testers); now: business analysts and specs and all that jazz
  • then: different in-house teams of programmers specialized in a domain; now: testers, programmers, BAs on one team focusing on the same thing together
  • then: cowboy development; now: planned and organized sprints
  • then: geographically distributed teams across 3 continents; now: everybody’s in the same country but there a few different companies developing parts of the software for the customer

I think this could give some idea about the change I was about to undergo… Add to it the fact that now I’ll be testing a web app which I’ve never done before and you’ll get the picture.

Getting into the zone

So… I step into the office on my first day not sure what is going to happen next. Oh, was I nervous… What really happened was that I got to learn a lot of new stuff. And this. Is. Awesome. I did know something about the project context from the time I was first approached by the company. However, a couple of months had passed, so I figured I wasn’t up-to-date anymore. Well, that hunch got confirmed on the first day.

I had been preparing myself mentally for the context where I was going to do a lot of learning. I’m not very sure how to describe it… I kept having internal monologues about focusing on learning, jumping right in and tackling whatever got thrown at me. I was recycling the learning and thoughts from Rikard Edgren’s tutorial on Test Strategy that I attended at Nordic Testing Days. Somehow it made me feel like I had solid ground under my feet.

I also had quite a few internal conversations/introspections about what I had learned at my previous job, the mistakes I’d made and how I thought about them; what kind of things I’d learned and why I’d learned them (I don’t think all potential lessons stick… or that I’d notice every lesson I could learn); what were my personal goals on the new job; what were the things I’d wanted to try but couldn’t at my old job. I went over the reasons I’d accepted the offer: to learn new things, to push myself out of the comfort zone once again, challenge myself. There were moments were some part of me was thinking “oh shit… how am I going to do this… will I fail?…” but that’s when I told myself this: “Helena, remember what happened the last time you plunged in head first into the unknown 4 years ago? You had no fucking clue what you were going to do but remember the trust you had in your ability to figure things out. If it’s the potential discomfort that makes you edgy, then just lean into it as you have done before. Push through the discomfort as you’ve done before: you know well enough that discomfort is exactly what will make you think of a solution. After all, nothing changes if you’re comfortable. And didn’t you want to purposefully make yourself uncomfortable so that you’d learn new things?”. Or something like this…

Maybe I’m slightly crazy for preparing mentally like this. Maybe. For me it seemed necessary to get really focused, keep my head straight, and “sharpen” my mental state. In hindsight I believe it paid off (and surprised some of my new colleagues :)).

I used to play volleyball as competitive sport back in the day. What I was doing back then before a game and what I was doing recently felt quite similar. You collect your thoughts. You try to identify and tune out the noise (or silence certain damning internal monologues). You try to will your feet move quickly. You observe how the other team warms up, start figuring out strategies… You get ready to do your best!

When I started as tester/team lead 4 years ago, I did no such thing. But then I really had no idea of what was in store for me. Now I had an inkling and I used that as an heuristic to do something differently this time.

The Vast Opportunities for Learning. Great! But…

I believe I’ve been able to establish that I was going to do a lot of learning of different kinds (technical, managerial), on different levels (personal, project-related, professional…). During the first couple of days I observed a few key questions/issues surface. Or rather, these questions had a floodlight pointed at them for me…

Firstly, how to best deal with information in general? How to deal with the information I was given on a daily basis (meetings, discussions, briefs, documents, specs…) or that just landed on my plate? Getting hosed down with a lot of different things from different sources  – how not to lose my head?

Secondly and more specifically, what to learn now and what to learn later? E.g. what kind of information to actively seek myself, what to delegate, what to disregard.

Thirdly, what kind of action to take now and what to postpone?

While untangling the questions from each other and clarifying my thinking, I had these brief deja vu moments. These came about in the form of “oh, this line of thoughts sounds familiar” and “I think I’ve read about/discussed this several times but that’s just been theory so far”. Funnily enough, even though I’ve never been on such a project before and I’ve never had hands on initiating a whole new software project, I almost felt as if I had. There were thoughts and ideas gushing out from the back of my head about how to start tackling these questions. I know I was applying heuristics that I’d “accumulated” over the past years but this library needs to get more organized. To be honest, it was more like a flurry of ideas… which is exactly why I’m now putting myself through the paces and going through the exercise of identifying and thinking about the heuristics I already used during the first days to do the things I did.

The questions I highlighted have formed the trinity I’ve kept revisiting and that I will look at more closely in the following blog posts.