Lemons and Lemonade

Those that read my previous blog will be aware that the company I was working for decided to cease software development in Melbourne. That decision put me out of a job, unemployed for the first time in a little more than 30 years. I’d prefer to be employed, I miss working with smart and interesting people to solve important problems for clients. I genuinely love solving problems with people, learning from others and also helping colleagues find new ways to think about, or approach, things. Still the decision to close down was not mine, was out of my control, so I’m trying to just let all that stay in the past and control what I can. In case anybody is wondering, no, it doesn’t feel like a big holiday.

To fill in time I’ve been working on refactoring my CV (with some help from a consultant), applying for jobs and digging into something I’ve been wanting to do for a while. I’ve been learning Java. In the past I have learnt some visual basic and developed an understanding of some basic Ruby (to the point that I could write code). So why Java and not continue with Ruby? If I had a dollar for every time someone asked “why Java” I wouldn’t be learning Java, I’d be sunning it on a tropical beach, fishing rod in one hand and eyeing off a bucket of cold beers.

I decided on Java because it seemed like a good idea. A lot of articles pointed to learning Java as a good idea. Beyond that I wanted to get into writing some automation and the majority of resources I had an interest in used Java. The primary source of interest here was Alan Richardson’s Java For Testers. I loved the idea of a book that would teach just enough to get me started and allow me to write scripts. If I could skip past some stuff I didn’t really need to know, that would be cool. I should also mention that I am a fan of Alan’s work so it felt like a great starting place. So start I did.

I was about, maybe a third, maybe less, into Java For Testers when it occurred to me that I cared a lot about some of the things that were being skipped over. I wanted to know more about certain relationships (constructors and getters for example). I felt like if I put the book down and tried to write some basic Java, I’d be stuck. In no way is this a comment on the book, more about my learning style. I believe some of the answers I wanted appear later in the book, but I was a little uncomfortable and decided a change of direction might be useful.

Late last year I commenced a 12 month subscription to Pluralsight. I decided to do this for several things I wanted to study, Java was not one of those things. I decided to start on the Introduction to Java Course by John Sonmez. This course has been really helpful but it takes some effort (at least for me) to learn basic Java. Part 1 of the course contains 6 modules;

  • Introduction to Java
  • Variables and Operators
  • Classes
  • Control Statements
  • Inheritance and Composition
  • Generics

and the content runs just a tick over 4 hours. I can tell you it has taken me longer than that. Why? It’s easy to get lulled into a sense that you understand things when you are taking notes and writing code that is mimicking examples on the screen. So several times I have stopped and said to myself “right, go write code based on what has been covered to date”. This is how I very quickly find out what I have really taken on board and what I haven’t. It was this process that finally gave me an understanding of constructors, not just the “why” but also the how. It also clarified in my mind what an object is within code.

In the almost 2 months elapsed that I’ve been engaging with Java
(elapsed – I point this out because not every day is “I want to code Java day” and some days I need to focus on different things such as CV refactoring, job applications, meetings) I’ve had a ball, I’ve learnt a lot and I can now create working code in Java. I have a much better understanding of how complex coding is (thinking about the stuff I don’t yet understand – yikes). I’ve been exposed to, and know how to use, in useful ways, 2 IDEs, Eclipse and IntelliJ. I’ve been able to write buggy code (unintentionally) and use my testing skills to hunt down the problems (this bit doesn’t come with either book or on-line courses). Sometimes my code works first time which always results in me punching the air in triumph. I’ve learnt to hate curly brackets just a little bit (turns out, that’s not just me)

I’ll go back to Java For Testers when I finish the Pluralsight Introduction course. Once I complete the book I think I’ll dive back into Pluralsight or the Intermediate Java course by John Sonmez. I’d like to expand out my Java knowledge a little more. I mean, while I’m having fun, why not? Of course there might be other discoveries along the journey that change those choices in some way.

So how are my travels into Java going to help me? In no particular order, or with exhaustive thought, I want to be able to talk to Developers a little more in their language. I do feel that it might open up some more ideas around testing or prompt me to ask questions I might not have asked.
Will it help a lot, not sure, it hasn’t felt like an inhibitor to date. I guess all experiments start with an unanswered question. I want to learn how to write better code, become a competent coder, at least in ways that coding competence is important to me delivering value, and assist with automation. It would also be nice to be able to write a few small tools to help with testing. I guess I’ll firm up goals as I go. I do know at the moment I’m not really (at any level) thinking about a change of career into coding. I do enjoy the learning though and knowing that I have acquired technical knowledge that I didn’t have before, that my skill set continues to expand.

While I could do without the unemployment, the break has allowed me to dive into some new skills and at least feel productive in other ways than being in the office. If I’d gotten a week into this and decided it wasn’t for me, I would have been cool with that, I would have learnt something and then gone looking for something else (and that might have been another coding language). I’ve always enjoyed learning, that mindset has been something of a blessing during this break. I’m looking forward to more coding practice and learning from my plentiful mistakes. It’s also given me some new insights on coding and testing, I’ll need another blog for those.

Thanks for dropping by folks and, as always, happy to hear your thoughts via comments

Regards ……….. Paul

Retrospectively……..

It turns out that being made redundant changes your day, although I don’t plan to make this blog about that aspect. Maybe another blog but not this one. What I have found myself doing is reflecting somewhat more than usual. Reflection and introspection, looking for what went well, what could be done better, at a personal level, is something of a habit. I think it always has been but as I move through life I think I learn to be more realistic about reflection and how I deal with “not quite hitting the mark”. A little bit of disappointment is good, it’s motivating. Too much is depressing and a motivation damper. I’ve learnt to appreciate the learning that comes from misfires and the opportunity to improve.

This blog though is really about a retro I ran around 3 months ago. I was actually going to write about it, about 3 months ago. Stuff happens, the blog didn’t. It was the second retro I ran at Locomote and the first for the team I was working with. Part of writing about this is because I want to highlight that Testers do far more than test, at least the way I view testing. As a tester I want to be influential, I want to help people, I want them to know I am accessible, that I think widely and care a lot about who we are, what we do and how we do it. If you really want a quality product then it starts with quality people who really care about each other and are supported by a company that really cares about them. It aligns nicely, I think, with Obliquity (John Kay). Give people meaningful problems and let them solve those problems with enough support to enable collaboration and creativity.

About that retro

I said that I want to show that Testers can apply their skills to multiple disciplines, that is true. I also want to share this so if anyone else is interested they might give it a run, refine and share. I was told by others that they hadn’t seen this retro before. Given I’d come up with the concept 2 days earlier on a 45 minute train trip home, the observation wasn’t all that surprising. In short I wanted to run a retro where we revisited the past and forecast to the future. I felt it gave us a slightly different approach to retros we had been running. I like a bit of “different” in retros, different angles of thinking produce different ideas about not only possible improvements but ways in which we might experiment with, or implement, those improvements.

My rough sketch of the retro

It’s probably a bit misleading to say that the above is a “rough sketch”. It looked pretty similar on the big whiteboard, just more colorful and sans the explanation notes for me. I had a feeling that the concept might be a bit big for a single retro. Having introduced the idea and walked through each of the “mini themes” I proposed picking maybe 2 themes and then coming back to the others in a different retro. After a short silence, and a few questions, the team chose to cover the entire map.

So many sticky notes…….

I was genuinely surprised by the amount of ideas and observations that came out of this session. There was a little bit of initial questioning around the “categories” on the map. That was quickly dealt with (just write your thoughts and we can look after the rest). Some ideas didn’t neatly fit any of the categories, somebody decided to place those in the middle of the road (I thought that was super cool). One of the things that really interested me was that some of our experiments that had failed in the past, were added to the map as “proceed with caution” but also popped up in the things we need to do to get better in the “slow down” area. I thought it was really cool to see that level of reflection. I also thought it was interesting, and brave, for people to add some practices to the “Stop” part of the map, especially when we still had some as current practice (via outside influences). There was, for the greater part of my employment, a sense of safety at Locomote, that you could (and should) respectfully challenge the status quo. That atmosphere, in my opinion, turns “challenging” thinking from sarcasm to a genuine focus on real desires and perceived needs within retro sessions.

I was going to go deeper into some of the specific outcomes and the map points. I decided not to as it would make this a long blog, I’ve lost a few of the really specific details in the space between running the session and blogging AND the value for me, if you try my retro idea, is how you interpret and change it to your context. What I can say (as I look over the sticky notes – I kept them) is that there was a mighty focus on working with people, across teams, across time zones, pairing, sharing, collaborating. People solving problems that were meaningful to our clients. Those items figured prominently on our road to a better future “us”. I wasn’t surprised by that focus, it just reinforced the people focus I knew the team already possessed and their desire to make it even better.

Sadly I write this as an ex Locomote Travelport employee (that’s detailed in my previous blog post) so on-going actions and benefits are no longer anything I will be involved in. Hopefully my “between jobs” status is brief and I get the opportunity to run similar activities at my new employer.

If you have any questions or thoughts on the retro I’m happy to discuss them with you.

Thanks for dropping by.

Paul

End of this Journey

I knocked off work early today because, well, we were told we could. It seemed to make sense in the light of the Melbourne development office, of Travelport Locomote, being told it was going to be closed as a development shop. There will some ongoing functions in Melbourne but software development won’t be one of those functions. It feels a little weird to be writing this as I’ve not been unemployed for over 30 years. Come close of business Friday 14 December, that changes. Hopefully only briefly, but nevertheless, it changes.

When I started at Locomote (as it was then) just under 2 years ago (January 2nd, 2019 would have been my 2 year anniversary) it was a big move. I left a company where I had spent 18 years. That change was much needed, I needed a space where people were valued and treated as people with valuable ideas. A place where you could safely disagree and not be seen as treasonous for holding a different view to your Manager. I found that at Locomote.

When I started at Locomote it still had a start up feel, and I really enjoyed that. There was freshness and vibrancy that was really invigorating. It wasn’t all smooth sailing though, when you leave a workplace with a toxic culture it doesn’t just fall away, it clings for a while and you need to work through stuff and adjust. Fortunately, with help from supportive colleagues, I was able to work through that baggage.

Travelport became a more noticeable influence across the past 12 months. When I first arrived they were barely visible and Locomote was something of a “latchkey child” but as time progressed Travelport (“Mum and Dad”) were noticeably home and more influential. It was always going to go this way, they spent a considerable amount of money acquiring Locomote so bringing operations “into line” was inevitable. Having been through this shift before it was interesting to see staff morale. It declined, as it had in other places where I have worked and owner transformation had rolled in. What makes Locomote different is that the leadership group stood up, called everyone into a meeting and said (this isn’t verbatim) “we own Locomote culture, let’s make it something brilliant together”. I clearly remember that day as the day that things really picked up again. It’s a great memory to have and it was awesome to be part of the change.

As I write this I’m not sure if I feel numb, sad, relieved or a little of all. I’m certainly relieved that the decision was delivered quickly with humility, empathy and understanding. The Executive that delivered the message, in person, looked far worse delivering the news than most of those in the room receiving it. If it helps any, you did as good a job as you could have in the circumstances.

So for me it’s on to the next adventure. Hopefully that won’t be too far away. I was planning to take some leave in December so that has probably just grown a little in length. I suppose on the bright side it gives me some additional time to focus on the ‘Java for beginners” course I just started (and am really loving).

So as I move into the “winding down” phase I can’t help but reflect on the fun I had. There were some frustrations and disappointments, but, overwhelmingly it was fun. I was able to influence testing practices and align 2 teams with the principles and practices that resulted in the teams testing from the start to finish of a story (without once calling it “shifting left”). Practices that I had used covertly at my previous job were brought into the open and I learned a lot from being able to do that and discuss it openly with others. I worked with people at various levels in the organisation to help them understand what excellent testing looks like and why it matters. For what it’s worth, the first guild to be set up and running, when we decided we wanted guilds, was the Test guild (and we were the only guild for some time).

While I can talk about achievements they don’t mean a lot unless you are working with great people. I was fortunate enough to work with excellent people and in 2 super brilliant teams. In both teams I had a vision for testing and was able to share that, get buy in and commitment. Did that make it straightforward? Hell no, we failed regularly but we acknowledged those failures as a group and tried for better. I’ll miss working with these people.

So, as the metaphorical sun begins to set, and the landing gear touch down smoothly on the tarmac, I am now but a short taxi from disembarking
(forgive me, we built travel software, it seems appropriate). As I leave I will take great memories with me and the knowledge that I have learnt a lot. I leave a better tester and person than when I started at locomote and hope that I have also influenced others in positive ways.

Thanks for the ride, and the memories,  Locomote and Travelport. It was a relatively short partnership but we did some great stuff together. Perhaps, down the track, our paths will cross again. 

The Chance to Make a Difference

Way back, around mid 2016, I started talking to Lee Hawkins about putting together a venture that would help people gain employment through software testing skills.  I’ve written about the making, and history, of the EPIC TestAbility Academy (ETA) here and also here. If you go to here you can read Lee’s take on our journey. His latest blog  is particularly relevant to this current tale.

The reason I’m writing this blog is because today Travelport Locomote launched LocoStart. This is a program aimed at generating opportunity for people that may not otherwise have the choices, options and opportunities many of us take for granted.

LocoStart

LocoStart has come about because of people caring about others and wanting to help in meaningful ways. This was very much a team effort and it would be wrong of me not to acknowledge that. Kym (wearing the ID badge, closest to TV screen) works for EPIC Assist. Her work since coming on-board with ETA has been, well, epic. Kym has taken every opportunity and helped ETA grow in new and exciting ways. I honestly do not know how to put into words just how important Kym has been to the survival and growth of ETA. Next to Kym, is Ilana.  Ilana is our Communications Manager, Marketing. She has been very interested in ETA since I mentioned it not long after starting at, what was then, Locomote. From what I’ve seen, Ilana is incredibly driven when she focuses on an outcome. Her work championing this program and giving it life was simply incredible. Natalie is standing next to Ilana. Natalie is Delivery Lead in the team I work in. Natalie, like Ilana, has been very interested in ETA and very keen on establishing a placement program. Her input and support has been brilliant. I count myself as being incredibly fortunate to work with people that have a genuine social conscience.

So, after what is 2 years of planning and 2 ETA courses, the dream is starting to turn to reality. On Wednesday, Dom , a former student of ETA, begins a placement with Travelport Locomote. This will be his first professional engagement, his first job, since completing Year 12 at high school. Dom will be with us for 6 weeks and spending 2 days each week in our Melbourne office. Dom will be coming into the team I work in but will be exposed to all the business areas we have in our Melbourne office. He’ll be coming in to a warm and welcoming workplace with people that are keen to help him enjoy his time with us.

I’m really excited by this opportunity and the hope that this is the beginning of a brilliant program, one that will inspire many future blogs. I’m excited to work for a company that has taken a positive step towards understanding and promoting the value of  workplace diversity and is willing to learn and improve from actual experience. This is a great opportunity for all of us to learn a bit more about neurodiversity and promote workplace diversity through meaningful and positive anecdotes. LocoStart, in my mind, has a massive upside for our workplace. Beyond all of that we have opened the door for a young man to have his first experience in a professional IT environment, and hopefully, a career in IT as a tester.

Given, When, Then….Mental Indigestion

I have a love/hate relationship with acceptance criteria written with the “Given, When, Then” format . It’s not a recent feeling either, it has been something that has bugged me since I started working with teams that write user stories. I’m not “anti” this format but I am “anti” using it as the only format for stating ways in which software might be acceptable to clients.

I’ve mentioned in previous posts that I’m lucky to work with a team of people that are open to experimenting with ideas. They will happily try new ideas and provide honest feedback on how well they felt the experiment progressed, whether it provided value in their opinion. As a team we have learnt how to listen, experiment and respectfully challenge other views with the aim of improving what we do as a team. As the specialist tester on the team it would be fair to say I exploit this ethos, with only good intentions, of course.

Recently I attended CAST X18 in Melbourne and participated in Paul Hollands workshop – “Creativity, Imagination and Creating Better Test Ideas”. I don’t plan to describe the workshop other than to say it was a lot of fun (Paul has a great sense of humour) and I took away a few useful ideas. Among these was trying to develop test ideas, or test scenarios, before you develop any real depth of detail on a story. In short, detail can really strangle creativity.

Not long after the conference I was sitting in a grooming session. There was a lot of talk about the acceptance criteria, largely circling around rather than progressing forward. I asked the team if we could, instead of defining the acceptance criteria, capture test ideas that we would explore and other “knowns” we could check for regression. I suggested that if we could grab test ideas we could then circle back and think about acceptance criteria with a different perspective. It didn’t take a lot of chat to get this going and everyone chipped in with really good ideas. We never did circle back to the acceptance criteria. Everyone felt that we had captured what we needed with the test ideas.

The above story is not the first time that we have had problems with acceptance criteria or the first time we have chosen another path. I largely blame the language of the “Given, When, Then” format. Seems to me it is the “go to” option rather than a “possible” option. In my opinion that format is not representative of natural language (do you speak like that in everyday communication?) and it stifles creativity as people try to manipulate meaning into it. I’ve see plenty of instances where it seemed that producing something in “Given, When, Then” appeared to be the goal, an item to be ticked off as done, even if the end result was a bland statement that did not provide guidance on what a user values.

In previous stories where we have been unable to craft meaningful acceptance criteria we have resorted to bullet pointing criteria. In each instance that I can remember, moving away from the rigid “Given, When, Then” format has enabled the team to produce and capture useful statements about value in the story. Further, when we have done this our thinking has been wider and deeper (which anecdotally supports the lesson I mentioned earlier from Paul Holland’s workshop).

Recently I stumbled across an article by Mike Cohn about conditions of satisfaction


“….conditions of satisfaction are specific to a given product backlog item and define what must be true for that product backlog item to be considered done. For example, a user story such as, “As a user, I am required to login before using the site,” might include these conditions of satisfaction:

user is logged in only when proper credentials are provided

  • a “remember me” option is available
  • user can request a password reminder
  • user is locked out after three failed attempts

In my opinion, conditions of satisfaction, or a similar approach, represent a much simpler way of capturing the essence of acceptance and creating conversations about considerations beyond the acceptance. Should we not also gather thoughts on:

  • behaviour that would make the software entirely unacceptable
  • other areas impacted by this change

I guess there is an argument that details will fall out as we develop the story and discuss findings. I have a small problem here. It assumes that good conversations will take place and the people involved will recognise the problems as they go. That’s a mighty big assumption. If we have thoughts during grooming about ways the software might regress or become unacceptable, let’s capture those, in the moment, and take that knowledge into our subsequent development activities. Having this already captured frees up mental space for us to look for other problems during development, other deeper, more subtle ways in which the software might not be acceptable.

I dare say there are a bunch of people who have been involved in developing user stories for a long time and are doing the above, or even more. There are possibly also a lot of good practitioners that can manipulate every “Given, When, Then” into valuable statements. My personal experience however is that there are still a lot of people who hold fast to “Given, When, Then” as the only way to write acceptance criteria and find it problematic (it’s a reasonably frequent topic on LinkedIn). The user story exists as a vehicle for us to have conversations, and initiate actions, that enable delivery of software that allow our clients to meet their business goals. The we go about this should not be copy and paste but thoughtful and appropriate. My suggestion, abandon that thinking and experiment. Find good ways to capture information that supports the team delivering high quality software efficiently and use each as dictated by context.

 

 

 

 

 

 

Life’s a Team Game

When I first starting working as the dedicated tester in my current team it was a “waterfall” to testing operation. I called this out quite a few times, and, it was acknowledged we were doing this quite a lot. There is, however, a vast chasm between recognising a behaviour and changing that behaviour. As frustrating as that might be, it’s reality. People take time to change the way they operate.

The first thing that had me hoping change could happen was that the team acknowledged we could develop better habits around testing. That’s a really great thing. There are a bunch of Developers in the team and they could have easily decided that it was all too hard. They could have given lip service to idea and just ploughed on with no real intention to change.

Having said that we needed better habits around testing in the team, that didn’t exclude me. I needed to be come more alert to opportunities, ways to show the value of testing. If I was asking other to commit to change then I had to support that with a willingness to try things that might be different to ideas I had. I needed to be available to discuss ideas and I had to be very open to sharing my ideas on testing (stopping me talking about them is probably a bigger task). Not least, I needed to stay sharp during discussions of a more technical nature (that’s not something that comes naturally to me). I wanted to be able to add value in this space. I wanted to have the Developers value my input and not just ask me because it was expected they would ask.

There were four key points I wanted to occur for every story.

  • Kickoff
  • Collaboration
  • Walk through
  • Test review

When I say “occur” I really mean for them to be considered and discussed. In some contexts it might be perfectly fine to say “hey we can skip this” but let’s at least have the conversation and understand what not doing something might mean in terms of risk. These were also the things that I believed would help us make other touch points regular occurrences.

  1. Kickoff – a walk through of the story with the Developer, Business Analyst, Product Owner and Tester. Establishing our understanding of the story, any risks, things that we could investigate further, ambiguities not seen previously, possible impacts outside the immediate scope of the card. In short anything relevant to the story.
  2. Collaboration – this is reminder to us all to talk to each other during coding of the story. Talk about blockages, surprises, things we misunderstood at kickoff, coding implications, things that I might want to investigate to help the Developer, things I might want to look at or investigate to improve my understanding of what we were doing. This collaboration aspect extends to any stakeholder who has useful information or needs to be kept informed.
  3. Walk through – a demonstration, by the Developer, that the acceptance criteria (as a minimum) have been delivered. Generally attended by the story Tester and the Product Owner these can be quite deep sessions, even though duration is generally quite short. As a group we have rejected stories at walk through because we have seen problems in the way the story was expressed. This is a serious step in maintaining quality.
  4. Test review – When I’m testing I talk to people inside, and external to, our scrum team. I love to use peoples different knowledge levels and perspectives to create test ideas I might never develop on my own. This step is a reminder (to me more than anyone else) to have conversations about what I found when I think I might have tested enough. Are there other things worth probing based on my results? The context of the story determines how wide I go with chasing stakeholders.

The early sprints of moving into this new territory was hit and miss. Old habits die hard. Developers would take stories and the story kick off would be missed. The first feedback I would get was at the walk through prior to testing of code. As a team we were forgetting about the opportunities we wanted to create (to be fair there was more than just this change going on at the time). As individuals we were following old habits more than creating new ones. At times it seemed like a “path to nowhere”, but reflecting on how hard it is to change personal habits, let alone those of many people, reassured me that it was, given the quality of my team mates, just a matter of perseverance.

I was sitting, just thinking one day about the above 4 points and the “hit and miss” nature of the venture. I was as hit and miss as anyone else in the team so, even with expressed desire, the change was “slipping and sliding” more than driving forward. Maybe it was the number 4, I’m really not sure now, but the idea of creating a game and setting it on a baseball field came to mind. I whipped up a very basic outline and spoke to the team BA about the concept.

baseball_concept

The initial plan was to add some color, name the bases, print it out, put it up. It didn’t quite happen that way. Our team Delivery Lead asked if she could maybe “expand it a little”. Seemed like a good idea, turns out it was. Here’s what happened:

baseball_board_blog

Now we really did have a game board.

For the first couple of sprints or game was attached to a wall. Unfortunately the wall and our stand up were too far apart. We never really talked to the game board. Then we decided to take it off the wall and attach it to a piece of board. It is now portable and comes to stand up with the team.

We are really just getting used to using this as part of our tool set but it has produced some useful conversations. We are yet to set rules around this. When we do I’m sure they’ll increase the usefulness, fun and feeling of it being a game. One of the things we have discussed is our ability to change those bases to whatever points we feel the team needs to focus on to build better habits and outcomes.

I really like what has happened to get to this point. I had an idea that would not have had the end product appeal without other input. In reality it probably would have just withered and died. Multiple ideas from team mates made the idea into something I want to interact with, something far superior to my initial thinking. We have already seen some early signs of usefulness but, as a team, will develop the idea further (because that’s the nature of the team I work with).

I’m really hoping that in a few months I can blog again on this, our wins, our failures and how we tweaked the game to make it more useful. I also hope I can talk about how it was useful, what we learned from using the game. But then, maybe in a couple of months I’ll blog about how it wasn’t useful and why. Either way we will have learnt some really useful things about how we work as a team.

As always, thanks for dropping by. If you’ve done something similar please drop me a note and share your story.

Paul

The Standard you walk past…..

This is the last blog I’ll write that focuses on my previous employer. My last blog spoke about testing experiences with my current employer, Travelport Locomote. I plan for future blogs to build on that focus. I’ve been contemplating this blog for some time, vacillating between writing it and walking away, leaving it unsaid. Ultimately, as you can see, I decided to write. This blog owes much to Nat Dudley and her blog Recovering from a toxic job. I shared this article with others and found out just how widespread this issue really is.


“And I need everyone of you to support me in achieving this. The standard you walk past, is the standard you accept. That goes for all of us, but especially those, who by their rank, have a leadership role.” – Lieutenant General David Lindsay Morrison AOAddress at the International Women’s Day Conference (2013)


Some background:

I worked for at my last employer for a little over 18 years. The first stay was a little over 13 years. I joined a consultancy as a Senior Test Consultant, a stay that lasted 6 months. The consultancy company was a soulless and cold place. It was about bodies and resources, not people. I left the consultancy and effectively went back to my old job. They had yet to find a suitable candidate and the move back came with a pay rise. Maybe that was an early omen. To be honest, at that point in time, the company had some issues but I wouldn’t classify toxic culture as one of them.

Fast forward three years. The part of the company I worked for had a change of owner. Three months later, our new owners, on a cost cutting drive (margin is king, apparently) slashed a bit more than 30% of staff globally. We lost a lot of good people in Melbourne. We also had a change in leadership. Initially I had high hopes as I thought the new leadership would back our recent journey to agility. The feeling amongst most people on the development floor was that we were slowly moving to better WRONG.

At this time, I was the most senior amongst the test group, officially “Principal QA” (a title that I would have changed to include Tester).  Staff changes through resignation and redundancy meant I was now reporting directly to the new Manager, who was “running the show” in Melbourne. Let’s call him “Mr X” The first six months of this relationship was, well, odd. I was asked to be an agile evangelist. I was cool with this, I was doing it anyway. In our weekly catch ups it was clear that what I was being asked to do was at odds with X’s desired path and his preferred mode of management (which includes the word micro). We had a bunch of chats where he was clearly not across what moving to agility really meant for our operations. Xs’ manager was, if anything, even less understanding (he wanted to “cherry pick” from the manifesto principles).

Let’s leap forward six months. At our weekly catch up I got the comment (command) “you need to be more pragmatic. Stop talking about this agile stuff and upsetting people”. Say what? I blogged previously on this episode (here). I should have taken the hint and rapidly sought an exit. I didn’t, my bad. Here’s a few highlights across the remaining time up to my resignation.

  • I was excluded from any leadership group meetings. The testing group, as a whole, lost representation at meetings
  • A demand that the team I was in working provide 70 days of free labour to make up for unpaid work delivered to a client. Management had approved the work but backed off when they realised it came at a cost of 70 days. It then became an “unauthorised promise” made by the team.
  • A new tester into the company was to spend some time with me “learning the ropes”. He was moved well away from me. I had been branded with having a bad attitude for not simply agreeing, without question, with every management decision (I have inserted an extract of my e-mail response)
  • The company spent money on a pool table for staff. It did more to boost morale than anything else that had been tried (not that much had been tried). X complained that “my request for software gets declined but they buy that table”
  • Responsibility for creating testing opportunities and initiatives was placed in the hands of a Developer in Bangkok, while this work was specifically part of my role. However it enabled X to impose his will on test direction. It enabled him to silently deliver directives.
  • An e-mail was issued to the wider test group. “Tell us about your three pain points”. I responded to the group with one ” We continue to approach improving testing in a superficial and disjointed way.”. That response earned a strong censure from X via e-mail (See below). A follow up ambush meeting followed where X and his Manager issued a formal “friendly warning” that next time it would be an official HR performance warning. Turns out the real problem here was responding back to the audience (that bit got mentioned a few times) rather than keeping it secret. Yikes!!

e-mail_extract

That is but a small sample I could cite more but I’m sure you get the idea. That last meeting lifted my motivation to get out to new highs. I moved from tepid attempts to having a red hot go. I could not operate in such a poisonous environment that held no promise of improvement. I was often asked by colleagues why I still cared, while no one else on the floor did (maybe I’m just stubborn, maybe caring is important). My “care factor” was given a new assignment. Within 4 weeks of the “friendly warning” I had signed a contract with a new employer. I was ecstatic.

The first few weeks at my new job were great. People were friendly and welcoming. I felt at home, like I belonged – even in the first few hours of my first day. At lunch on my first day I sent a text to my Wife – “So happy, this is where I belong” My enthusiasm was back. I had freedom, people wanted to know my thoughts, how I could help. People trusted me and there was zero micromanagement. It was just everything I wanted, and then it wasn’t. A few ideas met a little resistance and that triggered old habits and feelings from my previous job. I didn’t realise this was a “toxic hangover”. I started to wonder if I could do the job I was hired to do. I thought I worked well with people, maybe I didn’t. My confidence plummeted and I briefly considered moving on from the best job and workplace I have ever been a part of. I even considered moving away from testing as a career. I was languishing, doing stuff but not leading, not being “me” in the way I wanted to, and knew, I could be “me”. This is where being in a supportive and caring environment matters.

Our agile coach invited me to chat over coffee. There were some direct questions, there were answers. There was plenty of empathy and understanding from the coach. Then it was pointed out that I was making a choice and my choice seemed to be to focus on blockers rather than moving forwards. “You’re making a choice” resonated with me. It has ever since Michael Bolton spoke about this at a training session I attended. I realised I was letting the past crush me. It didn’t have to be about blockers and being beaten down. I could just as easily choose to do something else, so I did. This was what we agreed to call “a gentle ass kicking” but it was done for all the right reasons and with great care. When I left that meeting it felt like a weight had been lifted off my shoulders, my head was much clearer, my mood brighter.

Not long after that coaching session, I read Nat’s blog. It helped, a lot. I followed up a little later by having a chat with our People and Culture leader. That helped me understand the whole “toxic hangover” concept a little more. Nat’s description of the post toxic culture impact is very accurate based on my experience and stories from some of my colleagues.

Pink Floyd sings about being “Comfortably Numb”.


Now I’ve got that feeling once again
I can’t explain you would not understand
This is not how I am
I have become comfortably numb


I think survival for any length of time in toxic work environments requires you to become “Uncomfortably Numb”. You know that story about putting a frog in a pot of water and slowly heating the water. The frog gets used to the rising heat until it’s too late and it’s dead. That’s a toxic work culture. Another way I have thought about this is in terms of a behavioral science concept – learned helplessness. Get pounded enough and you just accept it and stop reacting, you become uncaring about the abuse. It leaves scars.

Now, finally, the place that I thought was everything I wanted, is that place. It wasn’t an overnight transformation, it took work and there were a few “wobbly” moments, but change happened. Not because it has changed but because the people there have helped me change. Genuine care and respect, amongst all people that I work with, will do that I guess. That veneer of toxic varnish that inevitably covers you, an unconscious form of protection that you build, has cracked and peeled away. I have been feeling energised, imaginative and involved. I’m back to loving what I’m doing and helping the people I work with understand what I do and how we can help each other. This is what a workplace should be.

 

The Illusion of Quality Assurance

When I first started testing my role description was Tester. In the numerous years that have rolled by since stumbling into the most satisfying phase of my career, I have been both Tester and QA. My previous role had me labelled Principal QA Analyst, my current role Senior Test Engineer. In official communication I will always use my current role title. Outside of that I’ll introduce my self as a tester. I’m proud of that title and what it means to me. I have, for a long time, rejected the QA title as being somewhat silly. Annoyingly it seems to be growing in popularity. More annoyingly it seems to me that those that are representing themselves as “QA” are also representing QA as more than, or superior to, testing. My problem is that when they describe “QA” they are describing what I model as credible, competent testing.

Is this representation of tester as QA now being driven by Agile? I don’t really have an answer to that question. I don’t think Agile was at the genesis of “QA mis-assignment” but based on what I heard at some testing based talks at LAST Conference, Agile is certainly fuelling the conflation of roles. I wont attribute the following to specific speakers but here’s a flavour of the commentary:


  • If you wait to test it’s too late to shift left
  • Testers are a gatekeeper of quality because of their mindset.
  • We are QAs, testers don’t do what we do. We make sure things are right.

The idea of a specific quality gatekeeper is completely contrary to the idea that the team is responsible for quality. In one session a question was written on a whiteboard “How would you test this?” Ten minutes later test was struck out and replaced with QA and the pronouncement “we do more than test, we QA”. In both presentations I questioned the QA over testing claim, how they assure quality. In neither case could the presenters actually explain it. The same hankering for QA is very evident on Linked in as well.

I work in a scrum team. My primary identified role is tester. Here’s an example of how things role in my world for a given story:

I attend grooming sessions. I question assumptions, I ask about how we can improve testability, I help get a focus on what mght be a risk, what we might not know. I work with my team mates to find potential problems as soon as possible. We make notes about things we might want to discuss or explore that are relevant to a story. So far no assurance but we do have a quality focus.

A developer picks up a story from the sprint backlog, a kick off is held. We discuss the story, do we have a common understanding of why we are doing this? Has anyone learnt anything between grooming and now that impacts our previous understanding? Do we need to investgate some uncertainties, are there previously missed ambiguities, do we know of recent system changes that might impact us? We go through a bunch of things, I’m not going to write about them all. Again, I’m involved, there is a quality focus, I’m not assuring a single thing.

The developer is coding while I check out some associated functionality. We became aware of a possible problem during kick off. Together we look for potential crossovers and impacts. We regather after a short while and discuss our findings. There is indeed a possible problem. We examine the nature of the problem and likelyhood. We decide the effort and risk of fixing outweighs the likelihood of it being encountered. If encountered we can actually deal with it pretty easily and the impact on a client is low. We have found a limitation, we can accept this and explain it to clients. This is good outcome. Lots of quality focus here, where’s the assurance. I’m not doing anything assurance role specfic.

The developer wants  to add some unti tests to our build checks. We discuss what would be useful and what wouldn’t. I suggest a scenario he had not considered, that gets added. That scenario suggests another, I raise the idea. We discuss. It appears that we have that covered by a couple of others. We decide the risk we were concerned about has been mitigated. As far as I can tell I’ve done quite a bit of testing on this story, no code yet. How can that be? If you’re a tester, and not a QA, then by the time you start testing it’s too late to shift left.  Are the QA believers selling a fallacy?

During the above process I’ve been thinking about how I might test the changes. I recently spent a few dollars an a whiteboard for my desk. Here’s my strategy:

test_strategy

The above represents discussions, things I’ve learnt playing with the software, possibilities based on observations, and, a little after I took this photo, I rejected some test ideas based on my discovery that a specific parameter setting meant the problem we were adressing could never happen within those test ideas. Of course that did kick off some other thinking that produced a couple of other ideas to consider. I shared the above photo with my team and the Support Manager who had a specific interest in this story. I was looking for someone to find a hole or two, feedback that would add more substance and bite. Equally they can respond with “looks good” or similar. I like the extra eyes and different ways of thinking engaging with my work. I feel like I’m testing. As a QA I’m probably doing a terrible job. What am I assuring here?

We execute the walkthrough. The developer demonstrates the changes. The Product Owner is cool with it and I can see that the acceptance criteria has been met. More to the point I can see that it has been met in one way,  one scenario. I have one more chat to the Developer. We spoke a lot about these changes, just looking for anything that might be important we haven’t discussed. Seems like we covered anything that sticks out as important. The developer is happy with my ideas around testing, thinks that it will give us a good chance of finding any important problems.

It’s now time to execute some testing of the code. In the perfect world I’d report our conversations and examination of the software were so good that it was bug free. In reality my first test highlighted a circumstance where the reported problem still existed. It was luck that I found it first test, it could have been a few tests in. I just happened to select the combination of inputs that would trigger finding the problem. The important thing is that collaboration and exploration created a level of information and an approach that meant this issue was destined to be found and then fixed. I also reflect on how we might have identified this earlier. I feel like that is testing,  pretty sure QA is sadly lacking from me.

I test, I am a tester. In doing my job, hopefully well, I get involved early. I challenge assumptions, I look for possible ommissions, uncertainties and the like. I don’t own this process, I am a part of it. I bring a certain set of skills, but then, so do the other people I work with. I work with people to help produce the best quality we can, not at the end, but throughout the cycle. I try to educate people on testing and have a genuine interest in learning what they do and how we can learn from each other. What I don’t do is assurance. I don’t guarantee anything. I don’t audit others, I don’t enforce or mandate specific practices, I’m not a gatekeeper. I suggest, I learn, I collaborate. Above all I work with people and we all contribute to building in quality as part of our professional commitment and accountability. I’m Quality Aware, I’m a Quality Advocate, I’m a Quality Assistant. I’m a tester, this is what I do.

 

A Moment for Reflection

On the 29th and 30th of June I attended LAST (Lean Agile Systems Thinking) Conference. The reason for my attendance was my first conference presentation. With Lee Hawkins (@therockertester) we presented our experiences of setting up the EPIC Testability Academy (ETA), running the classes and things we have learnt (aka, things we can do better). ETA is a software testing training course for people with autism.  I have written about this in an earlier blog https://beaglesays.wordpress.com/2016/12/22/change-this-is-going-to-be-epic/. Lee has also blogged https://therockertester.wordpress.com/2017/01/08/a-new-year-and-a-new-challenge-the-epic-testability-academy/. You can also find more details at EPIC Recruit Assist http://epicassist.org/au/epic-testability-academy/ and http://epicassist.org/au/epichub/eta/.

Public speaking, at conferences, has not been a real focus of mine. The opportunity to co-present with Lee (who has a long history of conference speaking) and getting the spotlight onto EPIC Assist was an opportunity I was not going to let pass by. Preparing the talk and delivering it was a lot of fun. I guess it’s not that hard to tell the story if it is your experience. We have 2 requests to deliver this talk again and we are waiting to hear about a third.

IMG_0920

There was something else that happened while I was at LAST, I clocked up 6 months with my new employer, Travelport Locomote. I mention this because ETA has a story attached that highlights the difference between my former employer and my current one. I’m not going to mention the name of my previous employer. If you’re curious you can find it on my LinkedIn profile, it’s not exactly secret. Regardless, it was toxic, made so by poor and indifferent management. This is a company that talks about assigning resources rather than people. A complete lack of trust by management towards their resources (with the exception of a chosen few), and a “carrot and stick” approach where the stick was much more prevalent. Management liked to point fingers, lay blame and seek retribution (I’ve got some incredible stories) Management formed meeting groups that included only those that echoed back what they wanted to hear. These were “group think” meetings. I didn’t get invited to many, I tend not to “echo back”. I prefer to challenge and suggest ways things could be better. In such an environment it’s not a survival strategy. In another blog I’ll talk about how learning to cope in such a high level of toxicity impacts you, even when you leave. It’s not pleasant and it’s more widespread than it should be. I know more than a few people that have gone through similar.

About 6 months before resigning from my former employer the EPIC Testability Academy became “a thing”. Funding had been approved, we had a vision, we had a name and the name had been registered. I was really happy that we had got this far. As things had been going along and building I’d been talking to friends and colleagues about the progress. There was a lot of interest and I had been asked by a lot of them if I could talk on it for 5 or 10 minutes at a monthly meeting that everyone attended. It sounded cool, I was up for sharing the story and answering questions.

The workplace was very much “chain of command”. I mailed my manager with the idea of speaking (because it had to be formally raised). He forwarded the idea to his manager for approval. “His” manager was the Development manager and owner of the monthly meeting. A response came back with astounding speed. “No, it isn’t a charity we support. You can’t present on it”. Not withstanding he hadn’t asked (EPIC is a not for profit organisation, not a charity) and that we had previously raised money for a charity we didn’t officially support. So it was bit of authority assertion, a power play.  It felt pretty personal and it felt very petty. The response from colleagues when they found out was very supportive (and in some instances somewhat aggressive towards management thinking).

Let’s fast forward about 9 months. I’m at Travelport Locomote.  Many of my colleagues know that I am part of ETA. They have asked questions, chatted about what we do, been genuinely supportive. I mention that I will be presenting at LAST Conference. The interest and enthusiasm is enormous. I”m provided with 2 days to attend the conference. No need to hit my annual leave. Our Sales people get me a new Travelport Locomote T-shirt (proud to wear it). I’m asked if I can provide some photos from the presentation. When I do the photos are:

  • Tweeted out under our corporate twitter account
  • Put up on LinkedIn under our corporate account
  • Circulated internally with some really supportive comments and responses from workmates

Later this month Lee and I will be delivering our talk at my office. I’m really looking forward to this. It will be a thank you for the support from a great group of people that form an incredible and supportive company.

When I resigned from my previous employer I hoped, and really believed, I was going to somewhere much better. Six months on and the proof could not be clearer. I’m yet to see any sign of a stick and there is lots of support and encouragement from Management. It hasn’t been without struggles but I worked through those with company support. Toxic relationships linger, in damaging and near invisible ways. That’s a story for my next blog.

Cheers

Paul

 

 

Diversity – How important is it to you?

Diversity is a thing, at least I think it’s a thing. I spend a bunch of hours each week teaching people on the autism spectrum how to test software. I like to think of that as a way I help to contribute to diversity within the software testing community. I like that some sections of the test community (the IT industry in general really) are working hard to increase the number of women participating in conferences and to raise the recognition of what women bring to software development. Keep in mind that both examples are dimensions of diversity not diversity in its entirety.

When we talk about diversity I think we are probably talking about diversity and inclusion. Should we change the reference to be more specific? I mean, we really want participation as well, right? The primary goal, in my opinion, is not increasing the diversity of the crowd attending. The primary goal is to increase the diversity of those presenting at conferences. Providing opportunities for people to tell stories from many different perspectives.

When I said “diversity is a thing” I meant that in a good way. There are people aware of its importance, how it can reach out to new, otherwise excluded, or marginalised, groups of people and give them a voice and recognition. In this way, we build communities that radiate positive energy and a multitude of perspectives when it comes to problem solving and creative thinking. An analogy here is to look at basic animal behaviour. In-breeding causes a narrowing of the available gene pool. Keep the pool tight enough for long enough and once strong, healthy animals become endangered. The limited gene pool, given some time, will begin to amplify genetic imperfections. I see diversity and inclusion as one way we are able to keep the “genetic thought pool” vibrant and healthy. A way we actively guard against group think and nodding acceptance of ideas that should be challenged.

Out of a drive for greater awareness we have concepts such as the diversity charter at http://diversitycharter.org/. I’m neither anti nor pro initiatives such as these. It calls out that we should think about diversity, that’s a good thing. The charter itself is necessarily broad. You can sign the charter, display the logo on your website. Theoretically, all good stuff. Hold that thought for a moment.

“Diversity is a thing” can also be a negative. Encouraging diversity and participation takes work. It requires thinking, active decision making and being able to justify your actions. Making decisions and justifying them when questioned really shouldn’t be an issue when testers are involved. Heck we do this every day. I’d argue that within the CDT community there is an intense focus on this aspect. CDT wears critical thinking and accountability as badges of honour.

Recently, on LinkedIn I saw a statement that “we take diversity seriously”. It was above a link to Smita Mishra’s talk on diversity at the Quality Software Australia conference. No other “poster” I saw for the QSA conference mentioned the importance of diversity. I found no diversity statement on the website (although I did eventually find a link to diversitycharter.org hidden amongst the media partners). I suppose at this point I could drop in a snapshot of the LinkedIn post to the Australian Testers LinkedIn page. Instead here’s a quick summary:

My initial query was to ask what diversity actually means to the organisers of the conference. It was hard not to notice that of 21 conference speakers, only 5 were female. There were no females running any of the workshops. Diversity is wider than just male/female ratios, no argument from me on that, but when you feature that statement above a female speaker……

Two days passed, no response so I posted a follow up to LinkedIn. Of particular interest to me was that I could easily find pages of legal documents protecting the conference’s rights and interests. It was not so easy to find anything about why “we take diversity seriously”.

Mike Lyle, one of the speakers at the conference, responded to me. Thanks Mike. I appreciate you took the time but you didn’t address my questions. Actually, you couldn’t because I wanted to understand in what ways diversity is important to the conference organisers. You can’t answer the question because, as far as I’m aware, you’re not an organiser of the conference.

As a final shot at getting a response I noticed that @AussieTesters had tweeted “we take diversity seriously” (@AussieTesters has direct links to organisation of the conference). So I responded to the tweet asking if I could get an answer to my question. This resulted in me:

  • being blocked from Australian Testers LinkedIn page
  • blocked from @AussieTesters twitter
  • blocked from Rajesh Mathur’s personal Twitter account (Raj is one of the conference organisers. It’s an account I wasn’t actually following).

I find this reaction somewhat strange. I can guess at why the response took the form it did due to some history, but this should not have been the reaction to the question I asked. It is a fair question. It should have been easy to answer as well. Diversity can be modelled in so many ways that a thoughtful response should be pretty simple. If the conference, through its organisers, really believe that “diversity is important to us” then stating why should be pretty matter of fact. In fact the chance to get your views out there should be a welcome opportunity. A chance to show that you thought about the issues, how you feel about them and talk about how you incorporated this into the conference program. Being unable or unwilling to do this gives me the impression that diversity might not be as important to this conference as they are suggesting.

Beyond this though, the reaction to block a fair and reasonable question, to simply dodge it in the simplest way possible, smacks of double standards.

In 2016 a couple of Melbourne based testers started up a test conference called Tconf. The conference stood out mostly because it was incredibly affordable and had a decent number of tracks. The tracks being offered were only of passing interest to me at the time. I let it roll in favour of spending my dollars on other things. I didn’t think much more of it until a blog post written by Colin Cherry (https://itesting.com.au/2016/10/21/diversity-still-a-dream-in-software-testing/). Colin wrote about Tconf having no women speakers and the lack of consideration about the importance of diversity. It was a pretty “full on” blog. I agree with the diversity message, not so much with the way it was delivered. It is what it is. Colins blog received a number of comments, some supporting, some questioning. There was one particular response supporting Colin, which now stands out as particularly interesting. Note that the bolding is mine. I have bolded the sections which Raj picked out of a response to Colin’s blog. The non-bold text are Raj’s responses.

 


Not sure I understand the point you’re trying to prove with your boycott.

– Nick, I just spoke to Colin to understand his viewpoint. The point that he is trying to prove with his boycott is that he cares about diversity and that he is disturbed with the fact that the event in question has completely ignored this important aspect.

The event does seem a little lean on the diversity side, at least in terms of the speakers, but I hadn’t even noticed until you mentioned it. Maybe I’m a bad person.

– A little lean? Sure?

Perhaps the talks put forward by these males were of such high quality they couldn’t turn any of them down.

– Perhaps most of the speakers ‘are’ the organisers and mates. If that is the case then who is going to really make a call about the quality of talks?

Perhaps there was a shortage and the organizers simply went with the speakers they had available at their disposal.

– Perhaps there was never a call for papers and the organisers decided to deliver talks without even considering the diversity aspects of the programme.

Can’t we just live and let live here?
– Absolutely. We would love to do so. In order to live we do have to care about others’ living as well. Like talking about abolishing poverty doesn’t abolish it, ignoring or hiding behind ignorance about diversity doesn’t help in improving diversity.
Neither Colin nor I have anything against the individuals who are speaking at this event. I have met many of them and they are all good people. I would want to give benefit of doubt to people who have organised this event but we should know that they are not new to organising events. Colin has raised an important point here and has reminded all of us about something we forget about or don’t care about. We must be thankful to him.



There’s much in the above response that interests me now. Especially, and I quote from above

“……..ignoring or hiding behind ignorance about diversity doesn’t help in improving diversity.”

That statement has a very hollow ring to it in the light of recent actions from QSA. I think if you are willing to question others then you should also be prepared to be questioned. If you make statements about the importance of something, be prepared to answer questions. Claims without evidence don’t count. If, as a community we are serious about diversity we need to be accountable for demonstrating our commitment to it. Linking to a broad charter about diversity is not diversity, it’s just a link to someone else’s words about their desires.

I believe in the value of diversity. As I noted at the start of this blog, I spend quite a bit of time (all of it unpaid) to help support neurodiversity within testing. I value what diversity, in its many forms, can contribute to the testing community. I’m glad that I know a lot of people that also share a genuine interest in growing diversity in testing and more broadly in IT. This is a subject that deserves thought and careful consideration. Linking to a charter is nice but a charter is a guide, it is not a set of actions. Much in the same way that businesses hitch themselves to the “Agile” tag. That doesn’t make you Agile, your actions are what matters. Diversity is the same. A link to a charter without being able to explain how you implement the sentiments of the charter makes diversity a throwaway concept. Diversity is far too important to allow this to happen to it. If you are serious about diversity then make it clear the ways in which you support it, what is it that your conference (or business) does that meets dimensions of diversity. Walking away from a conversation does nothing to strengthen diversity.

%d bloggers like this: