Step back from roles, methods and definitions - the answer to how is yes

The role-discussion, and in particularly the style of rhetorics around it bother me. I've resulted in active walking out from twitter several times this week, just to keep myself from commenting and ending up in the discussion that I see as not going anywhere. Neither side hears the other, and both use strong expressions to change the others mind. I try to accept that I really don't need to change the other side. But I need to to, every now and then, express why I choose not to debate. It's not an act of not caring or being afraid, it's a choice of good use of time for things I believe to take things forward.

As of now, I'm reading a book called "The Answer to How is Yes" from Peter Block. I'm only getting started, but the messages resonate. It talks about us getting entangled with "what works" over "what matters", and seeking out our answers in the how-space where things should be "Not our way, not one way, but the right way" even if there's actually many ways of doing this. Sounds like core to context-driven.

A quote that lead me to start reading the book is this one - one that Woody Zuill uses to explain that he shares his experiences, not a method when he speaks of Mob Programming.

Some 10 years ago, I remember a discussion with James Bach, face to face, where he told me that the peer workshops focus experience reports because whenever we would try to talk theory, we would just argue. Our experiences differ, but each experience is true. Each theory, method and definition that tries to generalize the world might not match all of our experiences.

I believe the roles discussion is one where we should step back and talk about experiences, and respect that fact that is already obvious: our experiences on what makes a good tester (role) differ. And each of us can explain things from our experiences, instead of trying to argue for an absolute truth of how in a world where one might not exist. 

Software maintenance and why is that even needed?

There's a big change coming up with my product, cutting down the investment into development down by a third. With that decision, the big discussion that puzzled me is around software maintenance:

What do you mean you need 2 people just to keep it running without adding anything to it?

There's a big group of people who look at software as if it is something to build that after it was built can just be used without any maintenance. They feel puzzled on the whole concept of maintenance. What is maintenance anyway? It works now, why would it not work later on? You don't change it, how could it break?

I found myself telling a story yesterday that resonated well.

Imagine you bought a brand new car, straight out of the factory. It's all shiny, and just sits there in the parking lot looking beautiful. You don't need to drive it (you can), and none of the use really does much harm to it that you could see.

It sits there, throughout the year, open to weather conditions and people passing by with the bikes just barely too close to scratch your car. First it looks just dirty. Later, some rust creeps in. And rust is devious, because if you don't take it out, it will spread more rapidly.

Before rust, you will experience the winter conditions. You don't shovel out the snow, you won't even get into the car. The car is still there, but not quite as accessible as you would like.

You need to maintain that car, why would you think you don't need to maintain software? None of the things you invest in stays the same over periods of time. And the weather conditions in the case of software are particularly heavy, accruing maintenance ends up with expensive one-time maintenance. Some people would say that at that point you're likely to be in the point of rather just buying a new car.

Whom do I serve?

Someone I respect said in a private group discussion:

“And we serve the business stakeholders, not the programmers."

It left me thinking of whom do I serve? I too serve the business stakeholders. I collect and prioritize information to drive change from business stakeholders perspective. I drive the change through programmers, but I don't really serve the programmers. We both serve the business stakeholders. Together. With different skill sets for more complete service delivery.

There's a thought experiment that a friend walks me through occasionally:

• What is the value of a tester if you have no programmers? 
• What is the value of a tester if you have the perfect programmers? 
• What is the value of a tester if the programmer never reacts to any of the feedback? 

Let's look at this from another angle:

• What is the value of a programmer who writes programs that no one wants?
• What is the value of a programmer who writes programs that don't work?
• What is the value of a programmer who writes programs that cannot be fixed or extended?

The programmer value is less without feedback. It's not one serving the other, it's us being better together in serving the business stakeholders. 

At work we had a team day with business stakeholders today. It was great to hear how they praised the product we've created for them (one we still regularly bash for not being perfect). I felt the praise was equally for all of us. The devs wouldn't be where we are without me. I wouldn't be where we are without them. It's a symbiosis. 

A No Jira Experiment

I'm a tester and I like finding bugs. I like finding things I can praise too, but there is still something almost magical in the power of touching a software, bringing all our illusions of how well it works crumbling down, only to raise again stronger having addressed the problems.

Early 2014, I was trying to figure out how I could find a job in San Diego and one of the activities I did was to update my CV. I completely changed it from a list of jobs I've had to emphasize my achievements, and one achievement in particular left me thinking:

Personally reporting and getting fixed 2261 issues over a period of 2,5 years on Granlund projects.

That's 2,5 bugs a day. Every day of the year. Even weekends. Even holidays. Even days when I'm out of office at conferences. Even days when I do other stuff than hunt for bugs.

I could also talk about the type of the problems, but let me emphasize: I calculated bugs that got fixed, not ones I found. I worked like crazy to find better ways of targeting the information I would deliver, just the right time so that it would get fixed and cause least amount of damage.

You could look at the numbers and say that our software must be buggy. It was when I joined. It has transformed since, and some of that transformation is already visible in the number being only 2,5 bugs per day.

When I looked at the number, I quickly did the math. 2261 issues written down. That is 47,10 of my full working days (with 10 minutes time to write a report) used into just writing one-time documentation. 10 minutes is little, I've probably used on bug report writing a lot more time.

You know, I was trained as a tester. There was an amazing theme from Cem Kaner (my big testing idol) starting from his book Testing Computer Software (still the best testing book out there, Elisabeth's Explore IT comes close) called bug advocacy. It emphasized good reporting. Reports are our signature. So I've learned to write some pretty good bug reports. And often thinking of a neutral wording, the most representative example of the problem and clear steps to reproduce easy and complicated problems just takes time. This is time I often spent alone. Shared time with developer started when the report was done.

I decided to try an experiment. I would give up on knowing how amazingly good a tester I am, through numbers. I would stop writing my bug reports in Jira. I would scribble on post-it notes. I would use the time I often use in isolation in collaboration, dragging a developer to look at the bug (and fix it under my eyes, but these bugs were already getting fixed before). I would, when working remotely, favor personal messages or screenshots on the team channel when I saw bugs over writing a task. I would do everything in my power to use the time on bug reporting as time with developers.

You probably guess what happened: I started having to find less bugs. The developers started to be more amazing. I started to feel less alone and different.

If there was a manager looking at how I'm doing, they'd say that she finds, logs and gets fixed less bugs now. But the true interpretation is that now I'm not creating bug reports, but the end result is better.

None of us misses the dead documentation that holds us down. That energy, into keeping Jira true to facts, can be used elsewhere. Another lesson from Cem Kaner: Opportunity cost. It's not just what the accounting cost is, but also, what you don't get to do with the time you used here. Let's try to make good choices. 

Boxing the tester

I write this post out of slight frustration, to clear out stuff in my head. The frustration is related to discussions that keep coming up in my tweet stream. There's a few themes there:

• Are we or are we not preventing bugs? (I don't care, except for the part about early and continuous involvement of perspectives for full picture)
• Are we or are we not making decisions on releasing as testers? (I am, and it seems to be working well for me. I have friends in testing who are not because they feel risk-averse. It's not a role thing)
• Are we called quality assurance since we don't assure anything? (I don't care, I prefer being a tester but would hardly want to focus my energy on just a term without relevant practical implications)

I love the products and making them great and valuable. Testing is a means to that end. Testing for me is something I'm really good at (and not so humble about), and I love working with people who are good on the programming bit because together, we're magical for the products. The longer I am in this industry, the more I break out of the boxes of the "tester role". I code. Not test automation, but just regular production code. I work on technical designs and architectures. I make decisions on those, just as much as people in my team. 

Today was a great example of me driving through a collaborative decision-making process where we'd hear from every team member before I eventually summed up what we decided. Consensus is something the Swedes do well, and Finns struggle with, but we seem to be a lot better at that culturally than e.g. Americans who seem to assume hierarchy to extents I never experience. (Sorry for the boxes, I realize they are incorrect and stereotyping but I can't resist using them anyway) Most decisions work well with consensus decision making, except for e.g. firing. Release decisions are typical consensus decisions for my agile team. We've been delegated the full decision power. 

So, I'm all around the roles. I identify as tester. Sometimes I identify as a programmer. Sometimes I'm a UX person or a product owner. Sometimes I'm a manager talking to managers outside my team's scope. Sometimes I'm a facilitator and a catalyst for improvement. 

I used to care a lot about the identity of a tester, I wanted to be called a tester. The more of the "defining tester" arguments I see, the less I care to identify with that straightjacket. But I wanted to talk about why I think the boxing is useful.

The software industry doubles every five years. This means that half of us have less than five years of experience. I think this idea comes from Uncle Bob, even if it reached me through other people in the programming community. When we have less experience, we need a clearer box to learn to cover first, before breaking through the box and finding a bigger habitat. 

I've worked with newbie testers, who were made developers just as any others, and as newbies, they would seek their colleagues for models of what to do. They did not have senior tester colleagues, and within a year, they became programmers who don't question the customer requirements and who can't identify that the software isn't working or delivering as much value as it could. When they sought training, they took same kinds of training as the rest of the team. When they looked for idols, they never found the testing idols. They never became testers. 

I started off with a strong tester identity. I learned from Cem Kaner, James Lyndsay, Elisabeth Hendrickson, James Bach, Michael Bolton - people my programmer colleagues have never heard of. It became important to be a tester, because with that label I found hundreds of people to learn from. The tester communities are powerful. The oppressed are coming together and helping each other. Together we're strong. My programmer colleagues have never experienced the level of community I've lived through in the last 10 years. 

The community has negative aspects. I don't like the fact that we bash programmers, but the communities are often places where we let out steam to find constructive solutions to hard problems we're facing at work. That don't always feel safe for programmers to join and I'd love that to change. I'm all for diversity, testing over testers. I don't like that we're so strong in defining the right words and thoughts, but I try to dismiss that to work on something more productive - failing regularly. And some general behaviors leave people feeling unsafe, even with the tester role. 

I believe the labels are important when we start. The labels help us find our peers and communities to learn from. They bring us together. But as we grow, we need to actively break out of our boxes. 

But you do realize there is, easily, a full 20 years (and more) of intensive study on just to do great testing? It's not a thing you get in a few years. If you are everywhere with your skills, you are nowhere yet. Less than 5 years of experience for half of us - we should start from different corners, and just work together to bring the knowledge to paint a fuller picture as a group than any of us have individually.

Bags of Tricks

When you give an idea a name, you start a process of figuring out what it includes. In an Agile Coaching Circle in Helsinki, the instructor introduced their bag of tricks: things he often does as an agile coach, materials and activities of all sorts that sort of are his fingerprint - this you can expect of me.

On my way home from a meetup in a different city (3,5 hours train ride away) today I started to think about my bag of tricks and what it includes and does not:

What I have in my active bag of tricks - stuff that comes out without effort:

• Presentation karaoke. I often bring out a "battledeck" and get people doing a friendly version of  this. There's no battle, other than within yourself. Random topics collected from the group, 5 random slides from a collection, with control over the timing and GO. 
• Software to test. I have different apps I often whip up for a session of testing. And applicable documentation to test some parts of those. This piece seems to be one that is growing most in my tricks. 
• Group learning activities. Getting people to mob or pair on tasks, or work on ideas to put them together in some sort of synthesis.  Running a retrospective in a few formats. Running Lean Coffee discussions. 
• Games. I have a few I use on the games front, like playing 20 questions and learning strong-style pairing with a phone exercise.  
• Stories.  There's stories I seem to be telling again and again. There's others that get forgotten. I need to make my stories a better part of my bag of tricks. 
• Cheat sheets and summary sheets. I often notice myself going for Elisabeth Hendrickson et al's Cheat Sheet or Bach/Bolton's Exploratory Testing Dynamics or Michael Hunter's You Are Not Done Yet -checklist or Cem Kaner's Taxonomy of issues from his Testing Computer Software -book. These are distilled ideas over explanations. 
• Common testing answers. There's things I say with autopilot, like responses to claims like "Everyone can test", "No user would do that" and questions like "Why didn't you find that bug?" and "Do testers need to be also programmers?"
• Recruiting new speakers. This is my go-to topic whenever I'm struggling with social anxiety or feel the need of getting to know people. From finding out their topic to finding a place to share the topic in, it's an area of tricks. 

What I don't have in my active bag of tricks - ideas for extending:

• Videos.
  Well, I have videos. I show one specific video often. But mostly I don't like showing videos. I'm too impatient to watch videos. Videos exist so that you can watch them without company. So I have my hangups on videos and thus I don't carry them around in my bag of tricks.  
• Jokes.
  I feel I suck at telling jokes. Even worse than telling a joke is the idea of telling the joke again. 
• Agile games.
  There's a whole bunch of games and exercises I've experienced that are useful ways of showing things. I notice myself often thinking I should activate (facilitate some myself) the knowledge of other people's simulations. 
• Testing games.
  These are mostly things I've learned from James Bach and Michael Bolton. I find it uncomfortable for me to run these. Like getting people to play the Beer game (I just talk about it existing), or getting people to play the dice game. 
• Article references.
  I rarely give people articles to read more on the topics on. I more often reference a book than an article. 

What kind of things are in your bag of tricks? How could we share more of this stuff? 

Risk-based testing in the agile ways of working

I'm inspired to think about risk based testing. I've been working with a lady from Finland with 15 years of deep experience (she's brilliant) who is about to do her public speaking debut in a few weeks and I can't, for the life of me, understand why she's kept to herself so long. She's about to do a great session on her experiences on risk based testing, growing from the telecom world to the safety-critical devices.

With all the good advice she had to give in delivering a trial version of the talk, something left me thinking. And the something is that it is so clear and evident that we live in different worlds, and I don't miss her world one bit. The difference is agile.

Many of her experiences talked about not having enough time and thus needing to prioritize based on risk. Her later experiences talked about safety-critical making time for testing all risks classified serious. And her later experiences resembled my world a lot more.

With agile and continuous delivery, I have all the time I need, with risk-based assessment of where time is useful in testing, to test against whatever information I feel I could or should provide. The natural fall-offs tend to be types of testing that require special skills (performance & security in particular) and there I feel we don't do all we could/should. But if they were just tasks over major learning efforts, they'd be included.

Risk-based testing is no longer a technique for me, it's an overarching principle. Find information that matters - that's risks. Find first information that matters for schedules. Find then information that matters for all kinds of stakeholders, with less schedule impact. Big impact on development first.

It's like playing a game of nightmare headlines. Writing all the bug reports (in my head mostly) that I never want to write in real life.

I struggle much more with my risk blind spots. The need of giving myself chances of learning that all my brilliantly crafted lists of ideas to do and things to test are still incomplete. And that new things that emerge may actually be higher in priorities with the idea of minimizing the late impacts.

Then again, with agile, the impact profile is so different. I remember Vasco Duarte talking about this, so I went and googled what he's repeated for the years I've known him work on agile.

Agile = the best risk management *strategy* currently known for Software development #agile #scrum #kanban

— Vasco Duarte (@duarte_vasco) April 18, 2016

Agile is a game changer. I wonder why we write so little nowadays of risk-based testing - did agile change it so that it needs a relevantly different way to describe it? Or is it just that we understand that risk, just as exploratory, is just a word that describes any good and skilled testing?