Monday, August 31, 2015

Selenium on my mind

Selenium Webdriver has been the theme of my week - a theme that would appear to continue because I choose to continue. I’m struggling with my feelings about this, as I find working on the test automation the most boring part of my work I could volunteer on. But I volunteer to investigate deeper how I think while testing this way (working with tests as artifact focus) and how I think while testing the usual way (working with improvisation on the application with tests as performance). I have a working theory that I’m seeking evidence against: that I find more complicated yet relevant bugs when exploring without the form of artifacts keeping me on a leash. As a sort of corollary, I’m investigating a claim that I don’t enjoy test automation because I’m not fluent in it, through becoming more fluent before dumping the activity - unless I change my mind on what I want to spend my life on.

In the last week, I’ve done pretty much all-Selenium activities. Mobbing Selenium tests with my whole team. Pairing with a summer intern on creating more Selenium tests. Group/pair activities have been helpful as they both fulfill my need of being social at work, but also keep me honest and progressing on task that really isn’t one of my favorites.

I seem to find some of my motivation from playing with the dynamics. While last week we focused our efforts into automating scenarios for existing features that should be monitored, today we experimented with focusing on a completely new feature I’ve never tested manually before.

I was navigating (fixed pairing style since last session and was much happier with the work) and while I had many scenarios on my mind, I chose first one that I’d like to see included in the tests. It was almost the simplest one, but with a twist: a theory of error, a hunch I find so common on what would be likely wrong.

The feature was tiny. We have a dialog that lists packages, where we have previously hidden all packages considered “ready” for a particular user role. We now needed to extend it to show the ready packages. To test this, we need to play with two different user roles to create different states of the packages that then should or should not be visible.

My first hunch was that if something was wrong, one thing that would be wrong is that there’s two types of “ready” packages, ones that are made visible for the other role and others that are not. And that’s what I chose as our first scenario. We clicked through it manually to note that there’s a bug. We laughed at my ability to guess priorities and decided to try out something a developer from outside our organization once suggested me: reporting a bug with a failing test. The little framing difference created just enough variance for me to get out of my general Selenium boredom that I fight, and we were progressing very nicely on automating. There was all the usual obstacles we see with finding the right things to wait on so that the test would run reliably, but those felt more of a thing we just keep seeing on the route.

When the test was done and we run it, it passed. We were expecting a fail with the last thing we were checking. The bug was not visible, although both of us knew it was there. So we started looking into steps of our test where we reused existing pieces and isolating the exact conditions that would cause this bug. We learned that the bug would show only if there was exactly one user of the other role to handle the package, and extended our page elements and test data to include differences in the scenario.

Looking back, we used about 5 times the effort on isolating the bug and reporting it this way over the usual “Jira issues” way. But we did not do this to save time, but to try our how it would feel.

As we finished the test, the developer whose implementation we were testing walked by and got excited about the failing test. He suggested pairing to fix the problem. I was just leaving with other things scheduled, but our summer intern - my pair of the day, volunteered to pair on with the fix. He seemed really happy with getting to work on the application instead of just the tests. Sad that it had to happen for the first time on his last day at work.

Friday, August 28, 2015

Traditional pairing on adding some Selenium tests

Since my team isn't big on pairing, when I get them to pair, I tend to let things happen as they happen without insisting on mechanisms. Strong-style pairing does not happen naturally.

Today I paired with our summer intern, who's been spending some of his summer getting around our Selenium Webdriver -tests. Pairing meant joining him on his work of today with whatever I could bring into it. And the reason we paired is that I'm an expert in what features there are and how we might know if they work, and he was "out of scenarios to automate".

His computer, his tools and technology, and I was sitting by him fighting sleep. He was very helpful speaking about what he was doing, which is something I've learned not to take for granted. Even though I'm familiar enough with our structure, keeping myself up to date on where he clicked and where he ended up, reading the filenames from the tabs and interrupting him whenever things did not make sense was hard. I was continuously feeling it was too exhausting, that I was not learning as much as I'd like and that I was there just to remind of the scenario we were automating. This was very much traditional style pairing. I could review whatever he was doing. I could contribute and did. I fixed typos and corrected the test naming. I required concepts relevant to the test to be visible in the test and not hidden in the underlying structures to improve readability of the test. I observed the application to realize which wait from our utilities would be appropriate. And I was in control of the test scenario, what happens first and what verifications should be in place. I wasn't useless, but I wasn't as engaged as I tend to be when driving / navigating in the Strong-style.

This however left me thinking: if a non-coder pairs up with a developer, it's easy to imagine they might at first prefer this style. Even if they are asleep most of the time on the details, they are not challenged to actually get into the code. If they drive in strong-style, they will learn to code little by little. The work proceeds slower, as there's more learning going on. If they navigate in strong-style, there's a bit of a confusion on what part is navigating on an abstract level and what part is sharing the navigation with the driver.

So there might be a balancing thing here: how much time are you willing to invest in knowledge transfer in the pairing? Strong-style transfers more knowledge. Traditional style allows two experts of very different fields co-exists and collaborate.

I had enough time to let my mind wonder: for a test that I do manually in 20 seconds, we spent 1,5 hours building the test. And most of the stuff we used was pre-implemented. A big chunk went into finding out what to wait on to avoid Sleeps. I wonder if I will ever see this work worthy of my time within my interests. It bears little to no resemblance to what I know as testing.

Hmm, the smell in traditional pairing might be: "I did not have to put in much of my effort and this was not a good use of my time".  

Thursday, August 27, 2015

Illustration of traditional vs. strong-style pairing

I'm reading a sample chapter of the book "Pair Programming Illuminated" by Laurie Williams and Robert R. Kessler and on the first example of the sample chapter 13, I pause as I want to share something. Here's the first example from the chapter.

This is an example of Expert-Average pairing. The Expert is the navigator, getting very anxious about the Average guy pondering what to do when driving and speaking out loud. 

This is an example of traditional style pairing. It's described as "One partner, the driver, controls the pencil, mouse, or keyboard and writes the code. The other partner continuously and actively observes the driver's work, watching for defects, thinking of alternatives, looking up resources, and considering strategic implications". 

In this case, the navigator actively observing was also collecting quite a bit of frustration. The given consideration is for the Expert to drive and the Average to learn to ask questions to learn from the Expert. 

This whole scenario would look very different in strong-style pairing in which "from an idea to go from your head into the computer it must go through someone else's hands." The driver is the one reviewing while writing. The navigator is the one setting the direction. 

In strong-style, the above scenario could go like this, if the Expert had the answer all along. 

Donna (an expert, navigating): sum input1 and add it to the average of input1 and divide the average by two. 
Skip (an average programmer, driving): Great, what next? 

If the Expert is in the process of coming up with the answer while the work is going on, the discussion in Strong-style could go like this: 

Donna (an expert, navigating): ...Then we need to do the munge. Input1.munge().
Skip (an average programmer, driving): How do I do that?
Donna (navigating): result = input1.sum() + input1.munge()/2; 
Skip (driving): That seems like it's the general average? 
Donna (navigating): Oh yeah, that's a better name for it. 

The whole discussion above in traditional pairing shows a frustration growing between the pair. The whole dynamics in Strong-style pairing makes the frustration different. You might still be frustrated about not having the answers. You might be frustrated not knowing where your navigator will be taking you. But you are not frustrated looking at the less experienced one dabble for a direction that is right now available in your head. 

I find it fascinating that even the basic practices like pair programming still have fine-tuning to do to make them more effective. And that the fine-tuning isn't at all that obvious.  

Imagine replacing "average programmer" with "brilliant tester who does not code so much". That relationship without strong-style pairing is all about frustration. 

Wednesday, August 26, 2015

Encouraging for observations in training sessions

Among my many identities, I'm a speaker and an organizer. Being an organizer gives me chances of watching a wide variety of other speakers in action, and has proved to be invaluable source of ideas of things I want to improve on myself. As an organizer, I'm also often invited into the dialogue of what I thought of the session, further deepening my understanding of what and why goes on when someone speaks.

Yesterday I organized two sessions and co-presented one of them. The sessions were ones in the series of many similar ones, but every delivery is unique in some way. For me, yesterday's sessions were special as to noticing that over repetition, I've learned to really appreciate the way Llewellyn Falco primes his audience for observations - to share what you learn, both ideas in your head and things you think you're seeing. And because some of you may not have had a chance to experience and observe that, I decided to share it in writing.

What the audience is observing could be anything where something is going on. Collecting everyone's input seems to be particularly good for sessions where some are active volunteers in mob doing something while others watch. But it's equally valuable to get the voices and ideas heard in a team that just all collaborated focusing on getting something done and would benefit from sharing things around the doing.

The three messages to encourage observation

Llewellyn uses three points to encourage observation.
  1. On obvious things, half of us miss the obvious. 
  2. We see and hear things that are not there.
  3. We need everyone's perspective to build a fuller picture.
Each of the points comes with a video and an explanation. Watch the video and read then the commentary.

The first video is about inattentional blindness. Llewellyn let's the audience watch the video with the sounds, stopping the video just before the number of passes is show to check with how many passes people saw (just asking the number) and who saw the animal. With this video, he deliver the point:
Many things happen during the session we observe, and none of them is as obvious as the gorilla on the video. And yet, half of people miss even that. 
 He encourages everyone to share what they observed. Anything. It could be something the session leads you to think about, something internal. It could be about anything going on in the session. Every observation is valuable.

The second video Llewellyn starts off at about 30 seconds into it.  He lets people get into the faa/baa difference with the video to then deliver his point.

Some of the things you experienced might be things others did not experience as they were not there for others. Your observations are uniquely colored by your experiences.
 You see things that weren't there for others, unless you share them with others.

The third video is about forced perspective and how easily people can be fooled. Again Llewellyn delivers a point:
One person has forced perspective, but as a group, our different perspectives draw a fuller picture that is more realistic.
My thoughts on this

For some reason, I was comparing my observations on the audience reactions yesterday. The audiences would appear to respond better when primed with the encouragement, and the videos leave people on a good mood.

In work settings, showing the videos once might make a good impact, but practice improves things more. Feedback regularly teaches us to observe what we're doing.

I find these little tricks people do absolutely fascinating. Every speaker needs to find their own voice and style, but I wanted to share this as one example of a great style to break the ice. With post-it notes from everyone, it's at least a great cultural fit for Finland.

Monday, August 24, 2015

Pains of learning mob programming

Treat one another with kindness, consideration and respect takes a bit of practice. Or better expressed, practicing it makes me exhausted.

Me and my team did our first session of Mob Programming today without an external facilitator. With troublesome teams, a facilitator is great to have. But this time we were amongst ourselves.  Trying to figure out what goes on in something you haven't done before code-wise and helping the process, it's kind of a handful. Especially when not everyone agrees on the idea of mob programming in the first place, even for training purposes. 

Why are we trying Mob Programming?

Let's take a step back. Some people in my team of 9 developers and me really have strong dislikes for group work. When I first suggested pairing/mobbing, that was treated as the biggest insult one could imagine with a particularly genderised attack on me. When I later brought in someone to refactor with us in a mob, I was told that group work is a waste of time but after the experience, occasional pairing (if not with me) could be an option. When I asked my team to mob so that I could fulfil my social needs of happiness at work and learn stuff, others agreed to give in a little but one keeps disliking anything that is "intended to destroy the introverts and bring in these stupid collaboration ideas".

I've been looking at how we do, and we're not very good. We can release to production daily, but only because the throughput times are ridiculously long and we throttle what goes through depending on the skills of an individual developer. Individual differences of quality from a developer are significant. And quality is not just "bugs" I see. It's also code that others want to touch. 

Courses and training haven't really helped. People fall asleep on courses. You need to learn at job. You need to get better every day. So I work very hard to help people find time to learn, mechanisms to learn. Every day is an opportunity to be just a little better. That's how I test. That's how I want to help developers turn ideas into code. 

We need to learn from each other. So pairing and mobbing are the things to do. We’ve identified several team challenges we feel this will help us with.

  • Asking for help
    We often get stuck in development and ask Google, where we should ask one another.  As an end result, we have more cleanup work later. We could avoid cleanup by having more brains on the work. 
  • Reuse and rework
    We could learn to use our technical assets (reuse existing code) in addition to working actively against adding technical debt. We have technical assets we don't use, but recreate as information of what there is isn't shared. 
  • Continuous learningWe could learn from one another and have the learning show up right away in what we’re delivering. In particular, we could even out our individual skill differences in technical excellence we’ve already been working on. No course teaches how to work with our code and application specifically, we need to share examples by doing things together.
  • Teamwork
    We could get away from feeling alone and isolated. There’s very few other practical ways than pairing or mobbing to expose the practical level knowledge from developer to developer. It’s in the doing we learn.
  • Focus
    We could be more focused on an item we’re delivering, making the throughput times shorter without having to consider merge conflicts or additional work in splitting up into something manageable for several people. We could reduce procrastination and waiting, making think time explicit instead of hiding it into tasks. We still control our own use of time, just as always.
  • Skills outside the "developer" boxWhen working with requirements, we still often take what was asked and deliver that without questioning it enough. User interfaces in particular can be very dodgy. Exploratory testing that actually find bugs happens only when I do it or I sit quietly next to a developer testing and pretending I'm a totem or a mascot holding space for testing thoughts to happen. There's a lot of siloing to tear down on what a developer can / should do. 
Mob Programming to train use of Selenium Webdriver

I believe very strongly that mob programming would be a constructive way to tackle some of our team challenges. So I've been on the lookout for chances to try it out. Being where we are now just isn't good enough, because we have potential to so much more. If nothing else, less time at office doing the same work much faster. 

Last week our summer intern needed something to do, and the developers came up with having him work on adding some Selenium Webdriver tests. I was aware we had one developer who had been adding them and being kind of keen on using them to drive his development, but the skills and habits related to doing tests were isolated to him. The summer intern changed the power dynamic and I went to read through what we had now.

I learned we had 3284 lines of code in the Selenium test project. I reminded myself that we started working on this stuff with me creating opportunities to try it out and create things already two years ago. And whatever was created, had emerged in the last six months. The one developer who had taken the given chance to focus on learning to do stuff with Selenium had used what was given and created quite a nice page-object - utils - tests structure. It was time to get that to the rest of the team. So we agreed to mob with two learning goals.
  1. Everyone would learn to run tests / subset of tests / analyse the results when tests fail to make them a team asset
  2. Everyone would learn to create new tests
I find it hard to see that any other mechanism would have lead to the point where we were 2 hours 15 minutes later, where every one of us had not only seen how to write a test, but also written (stumbling  on their way but improving every round of rotation) a part of the scenario we were testing. And we had added test for a relevant scenario that will now run every night. A test I will not focus on while exploring, since I know it exists without deciphering, backtracking and monitoring what is going on with checkins. 

The experience was good but also painful. We were really bad at sticking to the roles of Strong-Style pairing. And every time we dropped the roles, the next one up as the driver did not know quite where we were, as you just cannot keep up with reading code while someone silently writes it. One of us was continuously pointing out that this was a waste of seven people's time, while everyone else felt they were learning a lot, in a hands-on way. 

During the session we got from one capable navigator in Selenium to three people navigating quite happily. We decided to work on navigation skills sharing next time, and have a designated navigator so that everyone will take turns in trying that out too. And we decided to do a better job in creating a common understanding of the scenario we're automating - this time I knew the test and that there would be problems on  the way, but the problems took everyone else by surprise. A Jira-ticket of a problem is nothing compared to experiencing the problem yourself. 

I was really proud of pointing out how nicely our summer intern had reviewed code while working in the mob, fixing things we would have seen when running the test - which was slower feedback that a smart person pointing things out. 

But I was also exhausted on the continuous negativity towards trying out something new. I got to hear that "I'm not paid to do this, this socialising is too much work" and "You just want us to play and not do real work, all this stuff is like being in kindergarten" and "I could just be a manager and sit around not doing anything, just suggest these idiotic things that waste time". I was keeping myself as calm as I can, working to dismiss the stuff, trying to believe that more of this will change the dynamics in the team.

I noticed three things I can put my finger on that we caught in the team within the session:
  • Keyboard shortcuts. People learned to use the IDE a lot faster over just short practice. It's just more efficient telling people shortcuts and then telling on a higher level with things happening faster when you don't search around with mouse. And surprising shortcuts were missing from people who do this stuff daily. 
  • Resharper. We've had it for ages. And many in the team did not use it. Renaming manually to three places becames visible and something we can help with changing when it is visible. And it's error prone. 
  • Consume-first programming. It was interesting to notice that only some were comfortable with the idea of faking what you wanted to code to have in the test, before implementing it. Most people were first navigating with the idea that you build each piece and put them together in the end. Example was very powerful in that, and I was particularly pleased on how smoothly it came in developer collaboration.
I try to focus on the positive. Others will want to mob again in two weeks on sharing knowledge of TypeScript, and then week later, more on Selenium as the team is back in full composition. 

I show very uncharacteristic patience in changing the team. A little every day. And we'll get there, eventually. 

Friday, August 21, 2015

Being a navigator in Strong-style Pairing

...this post continues where I left off with describing the Driver role in Strong-style pairing.

A step back: who should drive and who should navigate? 

You have a pair of people. You are different people, with different ideas and experiences. The two of you are stronger together because you build on each other, and also because each of you have unique qualities. Sometimes the qualities are more of a foundational or long-lasting kind, like experience that does not build up over night or transfer in a few days of pairing. Sometimes the qualities are more of temporary, like one having a rough day just today. 

One of you will take the role of the Driver - the intelligent input device. One of you will be the Navigator, working out the direction you're about to head to together. Which of the two of you should be which?

The first rule on being the navigator would be that whoever has the idea to get on the computer, should navigate. Remember: for an idea to get on the computer, it must go through someone else's hands in Strong-style pairing. This brings quickly the idea that perhaps the more experienced one should navigate. At least first. At least until it's time to switch. You learn very different things in being a driver and being a navigator. 

The dynamic of newcomer and a seasoned professional is interesting. Having the newcomer just drive is already a relevant service for the navigator, freeing you from typing to think on a bit higher level. The information for the newcomer sticks in a completely different way from doing it, hands on the keyboard, than watching what someone else is doing. 

Here's a story that stuck with me about powers of pairing with newcomers from Agile 2015. Someone was teaching his daughter to code by having her pair with him with one rule: ask "is there a test for that?". The daughter would sit and ask that every now and then would ask the question at the right time. Looking at what's going on, information catches on and the questions expand. This style is more of the traditional pairing. Having the newcomer type for you gives a whole other level of learning in strong-style pairing. 

Whoever had the idea of what to do will navigate. When I started pairing on exploratory testing with a developer, I was the Navigator. When I started pairing on unit tests with a developer, I was the Driver. Over time with both tasks, I will take both roles. And I will grow towards navigating so that the first idea that I have that I could navigate us through, I volunteer to do. 

There's three trigger options on change of roles:
  • On time: you can just change roles on a regular interval. Start with shorter times and grow the time as you grow to work as a pair.
  • On task: you can change roles when some task is completed. Like a typical ping-pong style pairing, you change so that one creates a unit test and other implements, and both get to do both types of tasks. 
  • On idea: you just change when the driver feels there's a direction he'd like to navigate to. It's like saying "hey, I have an idea, you take the keyboard now".
Regardless of the role you're in, the pair of you should remember to take breaks. Pairing can be very intensive work and outside getting the work done in a pair, you're also responsible for building forward your pairing experience. And that usually works best by inviting for feedback, like taking a small walk around and retrospecting your most recent pairing experience together. 

Navigator: Things to Do

As navigator, you are in responsible for caring for your driver. If the driver is the intelligent input device, for her to operate properly, you need to care for the conditions of work. Being the navigator, you need to pay attention to your driver, to constantly know where she is going. And you need to enable her to go as fast as possible.

As a navigator, you have three main tasks you're paying attention to:

  • Feed driver the next thing to do. You're creating the driver the box she works in on as high abstraction level as your driver can handle. We'll talk about abstraction level a little more later. 
  • Mine the to-do-list. Create an idea on where to go next. You might be just one step ahead, but being that one step ahead is important. Where to go to get your thing done? 
  • Observe your driver. See where she is and where she is going, and correct if the direction does not match what you had in mind. Pay attention on how she is doing, and help her whenever she needs it. 
Three main tasks might sound simple, but there's a bundle of advice to do them slightly better. 

Programming style matters

The style of programming matters. Pair programming would seem to work a lot more fluently if the programming style is consume-first. With this the idea is that you start with an end result at first and then one by one build the things you wish you had in order to have the end result. Consume-first enables the navigator to go immediately, coming up with things to do while figuring things out herself. And the end result and it's division keep a visible checklist of what there is to do to get to the end result. 

Some navigators prefer to work with bottom-up programming style. They build the image of the end result in their head, and feed the smallest possible pieces to the driver, one at a time. In this style, the navigator has a lot more of the information about what we're trying to achieve, leaving the driver to interpret more of why the navigator is having her do things. 

The third style is hardest, when there's no ability to work in small pieces. If the navigator has to figure out the whole thing before feeding driver work, most of the time the driver is paused or participating in design discussions over taking the implementation forward. As a navigator, you're supposed to care for your driver, not just having her type for you. Keeping driver waiting while navigator figures things out by herself isn't exactly the optimal way of caring. Working with partial information is essential.

The abstraction level dilemma

As the navigator feeding the driver the next thing to do, finding the right abstraction level to communicate with her is relevant, even key to making progress. For driver to go forward, you need to find the right level on which to talk. If you are using an abstraction level too high, you will see puzzled expressions and nothing happening at the keyboard. If you are using an abstraction level too low, you're not harnessing the powers of your driver by keeping her on too short a leash.

I was particularly puzzled with the idea of using highest abstraction level possible, until I realised finding the level is really a listening and observation exercise. If you give instructions and following them is hard, you're probably working on a too high abstraction level. Drilling down can be instant, just be more specific. If you're not noticing the need to change level, you're perhaps risking an experience of failing with tasks that lowers motivation in pairing, so it's good to keep your eyes and ears open. If you start from a very low abstraction level, the driver can always correct you by telling you the level she is comfortable with. But if she has not yet learned how to, she might get a feeling of being talked down. And I found I am particularly sensitive to that, being the only woman and paying attention to being treated differently.

Mining the to-do-list

There needs to be an idea of where we're heading. But the road ahead might be only clear for the next few steps, instead of all the way. An important thing for a driver is keeping track of the work ahead. There's three main things to consider on this:

  • Timing: Find the right time to use an item on the list. What should be done first, what would make a coherent shared story in your pairing. What choices would enable you as the navigator to care for your driver in the best possible way? 
  • Backlog: what is there on the list of things to do? Your backlog is best if it can somehow be part of the code and become a shared view - with consume-first style. But you can also make notes by scribbling on a piece of paper of a whiteboard. Whatever you need to keep track of things. Notes are disposable, code (including test code) is what remains when you're done. 
  • Prioritisation: Deciding what comes next and in what order to do things. It's not just about the right time in long term, but the right thing right now. And it keeps changing as you learn. 

Express a in-a-nutshell idea of what you're doing

As a navigator in strong-style, you are not supposed to have to justify all your chosen actions to your driver. Sometimes the driver has little clue on where you're about to be heading, and a great practice in these cases seems to have been to invite temporary trust saying you'd like to just go to this direction for like 10 minutes, and if she is still unsure about doing this, you can change then. The argument of what is right thing to do takes easily more time than that. And nothing stops the pair of you implementing both of your ideas and then deciding that a third, completely different option is what you should go for. With programming in particular, there's a lot of uncertainty that unfolds only through implementation and experimentation.

If you need to express what you're doing, you should learn to express that in a very concise format. Instead of all the rationale, pick only the part of the message that is absolutely relevant to care for your driver.

Immediate feedback

When you navigate, keep an eye on your driver. Double-check with questions what the driver does. And if the driver does something you consider a problem, help her correct it right away. Feedback belongs with the action the feedback relates to.

Recognizing time to switch

Either one in the pair can suggest a switch of roles. But as a navigator, you are usually in a controlling position, so your position gives you a bit of extra responsibility to pay attention to when the driver would have ideas that she should navigate on. You want, in the long term, to build a pair where both can contribute. Switching pairs gives a chance to try out the other role, and only practice helps you get better.

Step back and think about what you're doing

Sometimes you may feel you get bogged down into the details of implementation, and you might want to take a step back and think if you are spending your efforts in the right area. You may not notice without intentional step back to look at the bigger picture, because you're going fast with support of your pair (and usually a nice bunch of unit tests too).


Looking at your collaboration and how the two of you feel about it on regular intervals is also necessary. Not just looking at what you implemented and stepping back on that, but talking about what you learned and what you like and dislike about your collaboration, in a constructive tone.

Ending this with a word of warning

I've started to really enjoy looking into the dynamics of this style of pairing. But there's a story I learned, that I also find very specific to this style.

Two programmers were pairing in strong-style and had the time of their life. There was a lot of talk, as all ideas must go verbally for two people to share. Sometimes the discussions were very enthusiastic and to an outsider they might have appeared even heated.

While the pair was enjoying, the environment that did not recognise the different pairing style was betting on which one of the two in the pair would quit first.

Don't care just for your pair, care also for your environment. Verbalising your thoughts makes them available for more people than just the two of you. Take it as an opportunity to build relationships outside your immediate pair. 

Friday, August 14, 2015

Where do Testers Go With Agile

Last week at Agile 2015, I participate in a Stalwarts session with Elisabeth Hendrickson. Stalwarts is a fishbowl discussion, and one of the topics was to talk a bit about the visions of where current testers go with agile, in particular in the context of how things are set up at Pivotal Cloud Foundry.

Elisabeth described the ratios at Pivotal being 3 explorers amongst 150 developers. But in the session she did not address what she talked about after, that a lot of the traditional testers have actually found their niche in being great product owners prepping up the stories for the teams to develop, and there's quite a number of people in those roles.

Throughout the session, I was sketching a little picture to think about where do testers go with agile. Here's how I see it.

Some of us that have been testers before agile and in atypical agile teams (not quite there yet on e.g. teaming up and collaborating, but already releasing much more often that ever before) don't program. What we don't do today isn't saying we can't start doing it tomorrow, if that is the route we find interest in. It looks like we might have four directions, and none of them is called "tester" in this picture.

Some of us go away
Let's start with the hard part. Some of us will no longer be working with software. This portion is more about attitudes and wants, and inability to find the right ecological box to fit in. People ending up here might be people pushing for traditional manual scripted test cases - commodity testing. While building up e.g. automation and developer attitudes in agile-aspiring teams, there might be an appearance of need for a lot of this, but as the team learns and reflects, this is the work that I'm hoping that will go away. If this is the only thing you deliver, you will end up finding other line of work. Perhaps in support. Perhaps elsewhere in organisations. Or a different line of work that does not require you to think for yourself as much as creating software in any roles around it does.

Many of us will become programmers
I believe many of us will become programmers. Some of us are that already in addition to testing.

If we're new to testing, the risk is with focusing the attention. I believe it takes years and years to learn to be good at testing. It takes just as long to learn to be good at programming. And while there's some shared microskills, the two skillsets have a very different focus on what to learn and how to think about the system we're building.

If we've been around a while and are keen on shaping up our skills on the programming side, the door is wide open. We may be senior testers, but we start of as junior programmers. When might first focus only on using programming as a tool to automate things in the testing domain, becoming software development engineers in test. And eventually I believe that those choosing this track will not stop growing but should actively build on their skills to become full-blown developers, handling both the domain of test but also domain of the application. There's so much power in not splitting the work as soon as our skills allow for that. Test automation is coding. Get good at it. But why stop there?

I believe this is a majority route. This is the safe route. But only if you intend to become good. You do not need to be great today, but every day you learn through reflection on individual and team levels. A piece at a time. But only if you find this interesting and motivating. There's no reason you shouldn't, the great programmers excel in testing and expressing their intent, and transforming that to code and it's a fun thing to do. Especially when you add the pair / mob programming aspects where you're never alone with your attempts to learn more.

Becoming a programmer does not mean testing skill isn't relevant. It is. But it means learning to see testing problems as insights you can harness for automation as much as possible.

Few of us will become explorers
The world of deep exploratory testing is needed, but it's a specialty skill helping others in these types of tasks instead of doing it for them. It's more of a deep skill with idea of continuous work to transfer it.

Explorers will also learn to automate. First they perhaps learn to automate with a developer, pairing up. But for working closely with technical teams, a level of technical understanding will be required. It might manifest as writing particular kinds of scripts to support exploration, or being able to come up with ideas of that others can pick up and run with - with you.

There won't be as many explorers as there are traditional testers.

Many of us will become product owners
There's a lot of skills a traditional tester may have built that will be invaluable in the role of a product owner. With splitting responsibilities scrum-like, a team will need someone available for them full time, so there would be one of these for a team of two pizza boxes.

The testers who will not code or work with technical details are more likely to end up as product owners. Product owners prep the user stories, work out how the product is supposed to be with the technical team and customer representatives. Many testers who build ideas about products will excel in this role.

Product owners don't only define, but they heavily participate in learning through use. Product owners are business-oriented explorers.

My tester identity, where's that?

Personally I don't feel very excited with the idea of not identifying as a tester anymore. I'm still working on how I would feel about the idea of being a programmer. Tester identity for me means that I'm fast at learning new products and features, putting different abstraction layers of information together to see what works and what doesn't. It also means I can find other people with similar interests.

It just might be that to network, I would no longer seek testers, but people enthusiastic about testing. Whatever changes will take time. And probably I too will end up being one of the frogs who with slow change don't actually even notice which new skills I've been picking up and which old ones I've been deepening to help my teams do a better job.

Thursday, August 13, 2015

A Little Lesson on Paired Work

Being the only tester in a group of sometimes not-so-forward-thinking developers can try my patience. With a few more postponing excuses for our autumn-time mob programming, we're still doing solo work. And I'm still feeling the need of connection.

When my developers won't pair with me, I'm lucky to find another developer who will - to learn more about pairing in practice. We spent an hour pairing together in strong-style, with me navigating us testing a new feature of our product. This gives him an opportunity see what I actually do as an exploratory tester and potentially put insights from testing together with ideas of programming to suggest ways to do things better together.

This session was not one of the days on when we'd find stuff to automate. This session was about unbelievable amount of problems at the point when I got my hands on it, and the perceived insanity of not working together better to shorten the feedback loop with my developers.

There was one very small thing that happened during the pairing session.
Paradigm of pairing pushed me to discover more on a tool I had become complacent about. 
We needed to take screenshots of the first of the various problems, and he was about to get to Windows Start-menu to find the snipping tool when I stopped him and navigated elsewhere. I told him to just press print screen -button and could see the argument building up on having to cut pieces of the image later, but he extended the trust to do what I told without explanation - exhibiting wonderful driver behaviour. As he pressed the button, Greenshot on my test machine kicked into play and we could narrow down the screenshot.

Some of the screenshots were just situational pictures without need of explanation, and we could quickly save them to my default location. But others needed information to be added, and we opened them in the editor that comes with the tool for annotation. When we've done our texts and boxes to mark the spots, we needed to save. I insisted on saving through File-menu with the option that saves to default location. And as we opened the menu, his minor hesitance made me pay attention to the keyboard shortcut for that option, which was the usual one for the primary save (ctrl+s).

I've been using the tool for years, but had not stopped to notice a detail that was eating very small bits of my time over and over again, and that there was a better way. He did not know to teach me that, he had never seen the tool before. He did not even directly point it out, but I wouldn't have noticed without him as I wasn't paying attention. Paradigm of pairing pushed me to discover more on a tool I had become complacent about.

This is a great lesson on pairing. There's all these little things that happen in paired work that makes us better. If every day of the year brings one of these insights, we have quite a number after pairing up over time. There's so many chances of learning when working in close collaboration with others, and strong-style pairing feels to be creating a connection enabling this.  

Wednesday, August 12, 2015

Me Teaching Testing (Brighton in October, wink wink)

For quite many years, I've had absolutely wonderful places to work in. I made an active choice of not being a consultant or contractor, and thus I've had the privilege to learn my craft (pretty good testing if I may say so) in context of product companies. Wonderful in the sense that they're flexible and let me train on the side of normal work as a tester / test manager.

Back in the days pre-dating context-driven testing, I founded my learning to Cem Kaner's Testing Computer Software. For a single career-defining moment, reading that book would be my top item. I learned there were companies that considered opportunity cost and optimised their testing to be smart. And that those companies typically in the first front were product companies.

Over the years, I've given numerous positive remarks about things that surprised me positively, changed business models with my feedback, contributed to many great features that work and logged my fair share of bug reports. The mindset I work from I would refer to as exploratory testing. It allows me to test appropriately and dig in deep when I need to, learn a layer by layer challenging my knowledge to find out things about the product I'm testing.

I've also been teaching quite a while. I started doing that in 2001. For quite a while, I taught courses on testing folklore. Things I'd experienced. Little exercises to wake you up to think. Tips and hints on how to navigate the testing corporate jungle. Over time, I became 'a testing dictionary' for the Finnish local community, someone you could ask pointers on just about anything in testing.

At some point having coached enough testers as part of my work, I realised the courses need to change. That I need to move from focus on folklore to focus on doing. My Exploratory Testing Work Course is the course package on the theme I've been delivering the most, and put most love and dedication on. And this course now sees the first public outside Finland delivery, with Ministry of Testing in Brighton Thursday Oct 22. Will I see you there?

I've built my course around the need to learn to self-manage the work we do while testing, to dig in deeper for more information. I've built my way of teaching how I think and keep myself on track, and  build on those ideas leading my students to test real software with me. Learning from me, but also learning from peers on the class. A safe place to try things out and to get feedback.

If you are like me, you would have already been to many other courses and you'd still learn a lot. If you haven't been as lucky on receiving training, this course could give you a framework to deepen your skills while testing in day-to-day work.

If Brighton is far away and the times just don't match with your other plans, I'm hoping to keep in touch otherwise. I always love a good, constructive discussion about the wonders of testing and developing software. If you feel like getting in touch, my email is in my twitter profile - for a reason.

Tuesday, August 11, 2015

Being a Driver in Strong-Style pairing

...this post continues where I left of with my previous post.

Driver: Things to Do

You are the intelligent input device. What is expected of you except for typing as you're told?

  • Push back. Express that you need to modify the way the navigator is navigating you. You may want to change the box in which you work, make it bigger to give you more freedom or make it smaller to be clearer on what to do. You may realise you need to try something else, and express that in questions. Key is to be active even when driving. 
  • Improvise. The navigator gives you a box within which you operate. You have choices on how you can do things. You choose what you believe to be nest for context at hand, and driver gives you more detail if she disagrees with your choices. Improvising is about adding your intelligence to the collaboration. 
  • Switch level of abstraction. If you feel the abstraction level of navigating could be higher or lower, talk back to the navigator. If the navigator is using too low level, you can give them the higher level. "You can just tell me to run it", when navigator is telling you shortcut in keystrokes. If the navigator is using too high level, you can ask "Tell me what to type?" or "Where's that located?". Change the level of abstraction and enable a common experience of learning to work together better. 
  • Ask questions. If you feel something isn't right, ask about it. You can simply go for "Are you sure?" to stop the navigator to think about what is going on. Keep your questions specific so that the answers can be short. You can try validating questions to clarify what is going on right now, "It seems we're using zip-add-object to regulate temperatures, is that correct?". You can check if the thing you did was correct against your understanding: "I thought the database only accepted one connection at a time. Why did we do two?". You can suggest where to go, without deciding for the navigator: "Shouldn't we do this first?". Avoid general why-questions and work to prevent long explanations.
  • Initiate role switch on an idea. When you realise what should be done and think you could navigate this task better, initiate a role switch. You can switch roles on idea, without waiting for the timer. Or you could never use a timer and switch on tasks. 
It's good to remember that you as the driver are helping the navigator to navigate. Sometimes navigators will try a general avoidance technique of declaring tasks mundane, and great driver will volunteer to be around even for that task. Sometimes you are just literally trying to go against the excuse. Sometimes the two of you just need to get through the bad stuff together to get to the fun stuff together, to build the long-term relationship. 

Underneath what we actually do as driver, there's a bunch of attitudes to consider:
  • Trust your navigator. Stay in the moment. Be ready to work with partial knowledge. Your navigator is probably only one step ahead of you. 
  • Just try it. You can always do it both ways and end up with a third that builds on top of both. Learn by doing. Learning while doing is just as important as getting the end result out of the process. 
  • Constant self-reflection. Investigate what is going through you. Focus on learning. When following your navigator, you're reverse-engineering. Navigator keeps telling you stuff. You get a very thin, narrow view into the system. You can start putting things together a lot and this gives you a chance to reflect on what you're learning individually as driver with your pair. 
  • Patience. Give the relationship time. It's good on  both sides, but it's extra useful on the driver side who works with incomplete knowledge. 
There's two main pitfalls to being a driver. 
  • Thinking. You think within the box or change the box. Thinking too far as the driver takes the navigator's focus on bringing you back to the task at hand. 
  • Silence. It's not an open box to do anything you think of. If you want to take the lead, switch roles, but try not to run your own way with the silence. 

The pairing experience: foundations

Back in the days when testing dojos were new, I tried some of them. We would pair up in front of a computer to test, rotate on clock so that everyone around the round table got their share of the computer.

I never particularly liked it. I found that people were really bad at explaining what they were doing and that is the key thing I'd want to learn from - ideas that drive them. The roles of driver and navigator split so that the driver tests and talks out loud, the navigator observes, makes notes and adds stuff felt it was not very engaging. Everyone in the room would have a different idea of what was going on at the computer, deciphering most information from actions as people tend to be bad at talking while testing without significant practice.

As I was teaching testing, I adopted free-form pairing into my courses. I'd have people work in pairs, without assigning them roles and see what comes out. Most often I saw one of the people in the pair be active and the other one trying to contribute something, often quietly watching unless there was a specific discussion on what to do.

Then I learned about strong-style pair programming. With strong-style pair programming, the core is that any ideas from one person's head must go through the other person's hands. It relies on the roles of driver and navigator, but changes what each of them is expected to do. Driver is the one who listens and types. Navigator is the one who tells what to do.

In classroom settings, particularly when working in mob (group) format, this style works wonders. You can place the navigator as far as possible from the driver at the keyboard, and everyone can hear what the driver hears. And it guides you to vocalise the core of what we're doing, leaving everyone same experience of navigation as the driver gets.

On way home from Agile 2015,  I collected our ideas about communication in a strong-style pair, in particular as a reaction to many of the issues we see in teaching settings. I've come to realize this isn't programming or testing specific, but it's more about how people work together.

The Story that Triggers This Post

In Agile 2015, I participated a session about unit testing and group learning. The session started with asking for volunteers to join a mob in front of the room, and I was the first to raise my hand as I had promised to model that women could join. Success, we had 50/50 split of genders.

The session was set up with strong-style pairing, with telling driver and navigator their roles. The lady driving first expressed happiness in her role of typist, "I can do that!" and navigator told her what to do word by word, and soon the test was passing. She had just written her first lines of code in her life. With that, the first driver became the second navigator and was soon explaining what the lines of code she was working on would do, just by reading what the English said.

I was third in the queue to become a driver. The third navigator had already been through this before, and he was a programmer, he had already been helping the earlier navigator while he was driving. And when he navigated me, he went to keystrokes telling me what to do. I would have been fine with higher level information, especially since this was not the first time I've seen these Koans.

When I then navigated, I was focused on what level to navigate on, to get the job ("fill in the blanks" as we were doing unit test koans) done fast, as I was feeling slightly annoyed with the idea that I was assumed to need the keystrokes when I was driving.

So the question kept puzzling me: is it better to start your navigation with low-level or high-level? You can say "create a class" or " write 'MyClass VariableName = new MyClass();'". You can say "Copy the text from the file" or go into details of explaining how that happens. And as a woman, I felt particularly sensitive for a level that would be too low. Expressing that idea, I learned I would have been equally uncomfortable with navigation that was too high-level, failing to do what was asked and at worst multiple times in search of the right level.

This and two other posts are about what we learned about Driver-Navigator communication from that trigger.

Driver-Navigator Pairing in Strong-Style

For the pair to work well, both parties in the pair need to work well in their roles, and there's specific skills and techniques you can learn to work better from get-go with a new pair in either one of the roles. Techniques, however, are just ideas until you apply them in practice. Only through doing you can learn to pick up the small hints on what would be right thing to do, as you both are equally responsible for your mutual success.

We may think of the driver as an intelligent input device. Intelligence means that while the driver takes orders on what to do and where to go, the driver can also guide to get on the right abstraction level or improvise within the box the navigator gives her.

The navigator is responsible for mining the to-do list and passing the next things to do with instructions on the highest possible abstraction level.

This all builds on trust. The navigator may be just one step ahead of you, and thus unable to give you a clear overview of what you're about to do. The direction the navigator is going to is where the driver goes. When the driver has an idea, the roles can be switched keeping the basic rule in mind: for an idea to get on the computer, it must go through someone else's hands.

Next post up: Things to do as the Driver. 

Sunday, August 9, 2015

Away from Fear: Kindness-driven dialogue-oriented testing community

I don't want to be afraid. And even more, I don't want people around me being afraid. Fear is all too common in the world of testing I live in. Fear of dismissal. Fear of bullying. Fear of being put to one's place. Fear of not being right with limited experiences.

I've stayed off some agile stages with the fear of being put to my place about my views on automation.  I've built specific styles of presenting experiences to feel safe with the context-driven testing thought leaders. But the fear goes outside stages. It's fed on social media.

Let me give you a specific example. Last week, I saw this tweet.
It's clearly an ad. Ad amongst all the other tool adds I have a tendency of dismissing. I dismissed this one too. Until a reply got into my tweet stream. I started looking at it more. I saw comments like "Hacked?" and "You must be kidding, right?". I continued looking into STC discussion forums and found more examples unkind approaches.

It's amazing how many people start a conversation with me as I identify as a context-driven tester by apologising that they have an ISTQB certificate because they have been trained to believe they don't "belong" if they admit to having it. Liking it is even worse. I too format my two ISTQB certificates as "I have them but find them useless". I would perhaps offer my views on its usefulness, but it hardly defines the person I'm talking with.

To feel you belong in context-driven testing community, there's more no-no's than ISTQB. There's test cases. There's vocabulary that calls automated tests checks. These are strong beliefs, that I too hold, but that I wouldn't want to get in the way of collaboration and communication.

Context-driven testing with its rules of what is appropriate is a cause of fear. I've started to observe this fear in myself. It manifests in me second-guessing things I said without a proper reference (everything could have a reference, there's hardly anything original in this world). It makes me overreact to facial expressions of certain experts during my talks when they are in the audience. I'm afraid, clearly.

I see the same fear in others as almost compulsive-obsessive mentioning of the key names like a mantra, so that their talks are really about other people and their own great messages get diluted.

Recently, I've heard the same fear cited as a reason for stopping great people from getting up on that stage in the first place. This one makes me particularly sad.

Kindness is the key

On a day I was particularly frustrated with agilists telling me that my tester job should not exist anymore, I posted my new guideline on twitter.

We don't have to agree. But we have to take the other as a person that deserves to be treated kindly, regardless of our differences of opinion. Telling me personally I should go away from software isn't kind. The discussion could be about unlabeling what I do and finding out if there's still value with a specific mix of things I contribute.

Dialogue culture

Context-driven testing builds on the notion of "debate" and scientific principles. Without kindness, debates turn into argument and not actual dialogue. Peter Senge in his book 5th Discipline distinguishes between dialogue and discussion. The first aims at mutual learning. The latter is about finding the best viewpoint in a group and enforcing that on all participants. Dialogue requires suspending own views in search of the truth, and listening deeply to each other.

Let me give you an example of what makes our debates discussions and arguments. People I respect come out of those discussions with a message that they "don't belong to the context-driven community", and are blocked from participating in discussion forums identified as context-driven. There's an impression that people recite in conferences that context-driven testing is an elitist circle that controls opinions of it's members and is quick to kick you out, should you disagree. The context-driven school has become a label of bad behaviour some of us need to avoid.

I've been reading a book 'Argument Culture' by Deborah Tannen. The key takeaway for me from it is that I do not want to be in war against the people who have opposing views. I want to have a constructive dialogue. We can agree to disagree, and still treat one another with kindness. We should encourage people having differences of opinion, instead of telling which opinions are not good enough. Argument has an implied meaning of one being right and the other being wrong, and only a mild undercurrent of changing one's mind if the opponent comes up with good enough arguments.

People shouldn't have to keep their experiences to themselves for the fear of having a disagreement. We should be kinder in our disagreements and treat people with respect.

I'm still a context-driven tester. I look at the practicalities of where I am, and adopt my testing to it. Saying ISTQB has been good in some contexts I've been in does not make me any less of context-driven. I've chosen that label, it has not been assigned to me. So, the CDT leaders cannot take it away from me. Right now I'm thinking that label has more bad than good, but I will let that thought build up some more before deciding on taking action.

I belong to the kindness-driven dialogue-oriented testing community. If that is different from context-driven, let it be.

Tuesday, August 4, 2015

It's not a women's shirt if you just call it women's

Up until a year ago, I would not have written this post. I had been to dozens of conferences handing out t-shirts, and used them as cleaning rags or passed them on to my friends and family. I thought I did not care for t-shirts.

Then I lost weight. And I started to like my body. And I started to like t-shirts that look good on my body. Started to realise that there were t-shirts that would have looked good on my body also without the weight loss. There's such a thing as women's model.

Because I care, I made a new friend through twitter, who cares too. And a few more who are like me before, taking the shirts home to clean up the house with them.
April was unlucky to arrive just before the conference started, so she got a men's shirt. The word was there were women's shirts, they were just out. But really, there weren't.

I met April over lunch and we compared my "women's" and her "men's" shirt. Can you spot the difference?

There's three distinctive differences.
1. The size is a little smaller
2. The sleeve cut is a bit different
3. The label in the neckline says which one it is

But really, the women's shirt isn't women's. It's branded as women's, but it's not fitted for the female body. There is a difference. Look at this example for an Agile open space conference that gets it.

If you think the branding makes it a women's shirt, you could consider going back to your feelings after watching the fun scene of Joe from Friends with his new bag.

YouTube is great for other purposes too. Like finding out how to tune your t-shirt with just scissors available to be a feminine one. There's a lot of different styles, but I settled for the one that fixed the main problem: female shirts are fitted, not straight around the waist. Cut out the pieces from sides, conveniently modeling on another conference t-shirt from someone who gets it.
Agile 2015 conference was kind enough to give two women's by label shirts, so I cut the other one to become the string to put my craftwork back together. And here's a picture of me with the finished shirt.

It lived just one use, as I was not careful with my scissors, cutting too close to seams. So if sponsors in the back would have hoped for visibility, my solution was a short-lived one. Giving me a female fitted shirt would have worked. I hope it will next year. In agile, a year for iteration is a long time, so crafting is a great option of shortening the cycle. Conferences should stop wasting the $5 on shirts without creating value, and give women cool agile conference shirts we can wear. 

Monday, August 3, 2015

Power and Delusion of Stories

Thinking back to Agile Coach Camp USA and things I picked up there, there is a story that stuck with me. I want to share that with you, and discuss a bit about ethical questions I keep pondering with.

Mob Programming is a Game 7-year old wants to play

In a session about Mob Programming, Woody Zuill and Aaron Griffith from the original Hunter Mob, were sharing a story about a 7-year old girl. In one of the conferences or training sessions about two years ago, Aaron's daughter was around. As for mobbing in general with the inclusive principle, the girl was invited to join. She refused.

As the mob programming started on a doing a kata, the girl watched the adults programming. And after a few rounds of rotation, she voiced out that she would after all want to join.

She aced it, without any programming experience. She was navigating in her turn, following the "rules of the game" she had picked up watching, being very oriented to the TDD-process where you draw on board to describe intent, write the English as comments and then turn that to code.

She thought this all was a fun game she wanted to join as soon as she saw that.

I picture would be more powerful than words, and I was shown one from a mobile phone. The little girl amongst all the adult men, looking comfortable was moving to an extent that I will share this story on to illustrate why I've grown so fond of mob programming. I asked for the picture to share it with you.

* facts to check: was she 7? Or is my memory failing me on the story :)

On Ethics of Making Up Stories that Are Memorable

I feel quite confident saying the story of the little girl is true. I heard it from people I respect, and from more than one person. One of those people was the girl's father. And there was a picture. Stories are powerful, they appeal to emotions and make the message more memorable.

I remember a particular story from EuroSTAR over a decade ago. The story back then was by James Whittaker. That story was not backed up by evidence. And I did not question the reality of that story until recently.

In a conference this spring, I listened to a great presentation that shared stories. Memorable stories that were well told. As we were discussing the stories in afterparty, I was telling the stories on. And the presenter pointed out that the stories were not real to the facts. The message of the story was true and real experience. But the events themselves were exaggerated to portray the main character of the story in more positive light to create empathy. And that while some of the things had happened, they had happened in a completely different context and were just all put together in the context of this story.

I realised then that this is how some of our software industry folklore is born. People tell stories that are made up and catchy, and they live on. All of this is fine, if we know this is how the game goes. I did not know. I thought the rule is that when you get up on a conference stage and tell a story about a personal experience, that story should be your perspective of the truth. Not a creation of imagination to illustrate your point.

There's a story I've told many times to illustrate the point of exploratory testing.
A few years back, my sister went to driving school to get her drivers licence, at an adult age. She wasn't really paying attention in theory lessons as it seemed irrelevant. When the time of her first driving lesson came, the teacher went through all the individual pieces of how to operate the car in a parking lot. To her surprise, after a moment of looking into that at the parking lot, the teacher told my sister to drive out of the lot, amongst traffic.
She came home, in panic and excitement. She just drove amongst traffic! But she needed help from our brother so that he would show her around the individual pieces and remind her which one was clutch. She could remember only two things from the lesson: the traffic experience and that the teacher was kind of hot.
In Finland, when you get your driver's licence, it's considered permission to practice amongst traffic. The new driver will still have just the individual tricks in her sleeve, and things like change of gear and turning the wheel at the same time are impossible. But as you practice, the individual things become second nature, and you don't even realise what you did to operate the car on a scenic route and can focus on experiencing the world around you or within your head.
Exploratory testing is the same. You can and need to learn the individual controls. But there's so many layers to learn, that after 20 years of testing, I'm still an enthusiastic student becoming better at operation and observation.  New people can't handle all the layers at first. But every day at work is a learning experience that makes us better. Fluency grows over time.

So not hot, unattractive. I got my facts wrong. Should I not have told that story because it was untrue in a fact? It's more powerful with the positive memory of the teacher than with the negative. I felt like I wanted to apologise everyone I've mislead and I'm puzzled on how I will tell this story tomorrow with my talk on Agile 2015.

To me, learning that stories are fake was a big deal. I no longer trust people on stage, I do more fact checking. I'm more careful telling on stories and more focused on what their potentially made up stories trigger in my own experiences and memories.

I can't help but wonder: was I really the only one this naive? Do we go to tech conference to learn things that will stick with us and change us to help us react to things for future, or to learn about authentic past?

Sunday, August 2, 2015

On being and becoming a speaker at conferences

People and conversations drive the themes I think about, and this weekend people at Agile Coach Camp USA drove my thoughts to being and becoming a speaker at conferences.

This is my year of international conferences, and during this year a goal that I've working towards has become clear to me: I want to do what it takes to deliver keynotes at relevant international testing conferences. So I'm always on a bit of a lookout for ideas and tips on that process.

For the track of keynoting, I learned one relevant piece of information. I talked to a lady who is also doing her first keynotes this year. We talked and saw similarity in where we are: I too do a few keynotes, but there's higher-status conferences to work towards to still. She gave me a datapoint on something I suspected based on earlier discussions: to  become a keynote, you need to put yourself out there. Volunteer, make yourself available, help the organisers know you. Don't just wait for them to find you.

Most of the points that I picked up today are about working up your way to the speakers track. I wanted to share a few points on that which really resonated with me.

So, you want to be a speaker. What should you do?

Do local talks and get a video of what you do
Practice speaking. Best practice for speaking is speaking. Deliver the same talk. Deliver different talks. Invite feedback from your smaller audiences to help  you grow. When you're ready for bigger arenas, make sure to get a video of your signature talk - the best of what you are and do. The big conferences look for great speakers with great stories, but they cannot know you. You need to show who you are in addition to writing a great abstract.

Do lightning talks. 
Agile 2015 (and Agile Testing Days 2015) takes submissions for lightning talks, but there's often room for emergent talks. Just go talk to the track chair and see if you could squeeze in your five minutes. Share something you are excited about and listen to the feedback. Build from there.

Prepare to be rejected
When you suggest your talk, there will be rejections. Your relevant title does not guarantee a speaking spot in the big competed conferences. Nor does a good solid proposal. Sometimes what you had is just not right for that time. But if you submit to many places, there's a variety of needs.

Find a unique angle to present on
Conferences often get a bunch of talk suggestion on the most popular topics. For you to stand out in the crowd, choose something that is relevant but not the clearest mainstream. Work with your niche. What makes you unique to learn from? Do a few different suggestions if you are comfortable with very different topics. My advise as conference organiser and regular reviewer is though to submit at most three and to make sure the three are not the same message in different packages. That just lowers the odds of being selected.

Write a blog and let smaller conferences find you
Keep yourself visible by blogging, and write about stuff you are passionate about. Some people had experiences on being invited to talk on user groups and conferences based on interesting stuff they were sharing in their blogs.

Get help in reviewing your abstracts
Ask your friends to read your abstract and tell you what your message is. Improve so that they get the right message. Iterate to a next friend.
Also, find one of the services that help you find a mentor for getting your abstract in shape. If you are new to speaking and in the area of testing, go for Speak Easy. The mentors there are free and brilliant. And I am one of them.

When accepted, ask why
On your track of becoming a regular speaker, you will get accepted. When that happens, contact the organisers and ask why. That is a powerful way of learning for future. The answers on acceptance are more direct and honest than ones on rejections.

The three stages of being a speaker

Speaking has been my route to learn so much. I still feel that while I teach and share, I do all of this to learn, to find my community and peers. My inspiration and power to deliver great results at work is in my peers - people with interests similar enough to engage in interesting conversations that energise me.

The advise above is particularly good is you are new to speaking for the audiences you are targeting. I find that there are (at least) three stages on the speaker track.

Stage 1: Being a speaker
You've tried it. You've deliver talk. You are a speaker. Your audience may vary. Your audience may be limited. But you are doing it.

I feel I stayed in this stage for years. I delivered my first public talk in local conference in 2001. Since then, I've delivered probably about a hundred talks (or more). I talked in conferences in Finland, and in companies around Finland. My first international conference was 2005, EuroSTAR. First ever I submitted to, and first ever I got accepted for. So my personal experience is not to prepare for rejections. I've had only a few rejections, mostly because I have not submitted. I've waited to be invited.

Stage 2: Being a speaker growing your influence
You deliver talks and enough people know you so that you get accepted more easily. You do track talks mostly. Deliver consistently. Your have found the audiences that know you just enough to prefer you.

I feel this is the stage I'm in now. I submitted more talks in the last year than I have done in my previous career. And I got accepted to all but one I submitted to, EuroSTAR 2014. For most conferences I submitted to, I would give two-three options, knowing that there's usually perspectives to complement the program to a balanced whole.

Stage 3: Being a default speaker
You are the person often invited. So often you get to look at your calendar and say you cannot be there since someone else booked you first. You're one of the names that come up when thinking of keynotes.

This is where I want to be. But I'm not in a rush. I thoroughly enjoy speaking and meeting people through speaking. To get here, I feel I should write a book. So, better get to writing the book in process: a paired book on pair programming. I'll practice with that.