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
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:
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.
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.
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.
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.
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:
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.
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 AO, Address at the International Women’s Day Conference (2013)
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.
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.
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:
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:
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.
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.
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:
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.
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:
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.
As we move from 2016 to 2017 there are a couple of things that really excite me about 2017.
I start a new job with Travelport Locomote. This company produces software for corporate travel management. It’s a new domain for me, and that’s interesting. More than that, this is a company that believes that people matter, and acts that way. I’m looking forward to working with a new group of Testers and Developers. I’m excited about being given a role that will enable me to really utilise my teaching, coaching and mentoring skills. There’s a lot for me to learn, that’s really cool because I have a high degree of confidence that the people I’ll be working with will support that learning. We’ll help improve each other’s ability to produce a quality experience for our customers.
Across 2016 I have been working with Lee Hawkins (@therockertester) and EPIC Assist (http://epicassist.org/au/) to produce an introduction to software testing. This training will be aimed at helping people that have Aspergers Syndrome. Together we are hoping to get people sufficiently skilled to find employment. Lee and I will be developing and delivering the course with, to steal from the Beatles, “a little help from our friends”. EPIC Assist are helping identify people to attend the training and are also seeking out employment opportunities. They are also funding costs such as a training room, training materials, snacks, etc.
In 2017 this work will come to life as the EPIC Testability Academy (ETA). I’ve had this idea bouncing around in my head for a while but needed to wait until I had bandwidth and a group to support the idea. EPIC Assist is the group and Lee is the bloke that put his hand up before I finished outlining the idea to him. Working with Lee, in my experience, is incredibly easy. He is a very positive guy, humble and people focused. He’s also got a lot fo testing experience. William Elliott and Zach Zaborny, from EPIC, have been brilliant to work with, they are so positive and supportive. As a team we “clicked” from our first meeting.
Zach is an author. I highly recommend his book – Education of An Aspie: College Through My Eyes
For Lee and myself this is a “giving back to the community” initiative. We are providing all our time for free. While we make zero dollars through this initiative we expect we will learn plenty and have a lot of fun. Well-worn as this term might be, for us, it really is about community building. The people that come along to ETA will not have any previous exposure to software testing (although they more than likely test without knowing it). Initially we want to build some confidence and engagement. Finding bugs that are not too hard to detect would be useful. Of course, this needs to taper because “easy bugs” are one thing but reality is another and so we need to progressively ramp up the challenge and engage the type of thinking we want our students to embrace.
This is where we seek assistance. It would be an enormous help if you, or your friends, the people that make the testing community what it is, could contribute ideas around software that would be suitable for ETA. It can be alpha, beta, web based, hosted, local instal, anything really. If you would like to be part of ETA, even though you might be on the other side of the world, or this continent, the “welcome mat” is awaiting, the door open. You can contact me through the blog site message function with any ideas you might have. Anything you can provide will be really appreciated.
So that’s it folks. 2016 is rapidly drawing to a close. It’s been a year of some incredible highs (I’ve a learnt a lot and have developed some very strong friendships) and sad lows (deaths in the family). As always time marches on. 2017 is looking exciting for me, I hope it brings the same sense of excitement to you.
Many, many years ago I went to college and graduated as a teacher. I was going to say “became a teacher” but that would be wrong. College gives you a level of preparation to become a teacher but you don’t actually become one until you spend time in the classroom developing the requisite skills and flexibility.
Reasonably recently my wife completed a teaching degree. It was interesting to see how little the ideas and theories have advanced. I had the occasional giggle when my wife would talk about a new theory in teaching. I’d ask questions, discuss it a bit and then offer “I learnt that stuff, it’s just got a different name now”. Not that this phenomena is limited to the education industry.
I struggled remaining interested in much of my time at college. Teaching is an exciting career. Every day, every child, different challenges. College focused too much on theory for mine. The psychology was fascinating, not much else was. I’ve long held a view that an apprenticeship approach would be better for teachers. Learn by doing and experiencing. I suspect this approach would also retain those that really want to, and can, teach. For as long as I can remember getting your first teaching job has been more about academic achievement than desire to do a great job and a love of the profession. I know too many Teachers that “fell into” a teaching job and have just stayed on, not a lot of passion. I also know Teachers that are brimming with passion and desire to “do right” by their students. Again, this is not something that is restricted to the education industry.
The reason I’m writing this blog is not to reminisce about a former job and studies of old. Rather it is to talk about something a lecturer said that has never left me. Moreover it has been an enormous help and guided me when working with others. I honestly wish I could remember the name of the lecturer so I could attribute, but I don’t. Maybe he borrowed it from someone else in the same way.
“When you teach, bridge from the known to the unknown”
Having set this up I guess I need to explain why this is meaningful to me. Across my years in IT I have been a learner and a teacher. Often at the same time. I don’t “fly my own flag” very often, I prefer to let people make their own judgements based on what they have seen me do. Having said that I’m pretty capable when it comes to teaching, coaching and mentoring people (I see each of these three as different activities). I know when to be more and less directive. I know how to guide people to discovery and get an enormous buzz out of people suddenly “getting it”. Back in my days as a primary school teacher we called them “magic moments”. Those moments when you can “see the light bulb illuminate”. I don’t have a lot of formal certification (beyond graduating college) but I have a lot of skill built up by doing, driven by a passion to help people get better at what they are doing.
When I work with people, and they are new to what I am going to work on with them, the first thing I do is gain an understanding of what they know that is relevant to the task at hand. Sometimes you need to dig deep, sometimes not, but this is important. The first thing I get here is trust then engagement (and I think that is the order in which it occurs) . I’m not dumping stuff on them and expecting them to keep up. I’m building an understanding and, usually along the way, increasing their feelings of safety. So in finding the “known” I also find their comfort zone. The comfort zone is important. People feel safe there, they understand the territory, it’s demands and how to react. The “known” side of the bridge is the comfort zone.
It’s important to know where someone “is at” if you want to take them somewhere and have them enjoy the journey. If they know very little that is relevant, or to put it another way, their comfort zone is small, that’s an important detail if you want to avoid over stressing your student.Once you know what to link to you can start constructing the bridge that will lead to new understandings, new skills, new capabilities. Every session I run with people starts with establishing where they “are at”. This is really important to establish what might not have been clearly understood in a previous session or sessions. Always offer “revisit” options.
So you’ve made a link, you’ve got initial buy in and enthusiasm, the journey starts. Think about how great bridges are built. Slowly, carefully, “one plank at a time”. All those little planks build spans. Eventually the spans join up and we have a bridge. Don’t rush, allow time to develop understanding, practice, failure and learning, deep learning when appropriate. Rushing through the building phase may leave you with a bridge that is shoddy, useful only for a short time, if it all, and one that is prone to crack and fall apart with minimal pressure. That’s just wasted effort and setting people up for failure and misery.
I hope I haven’t made teaching and coaching sound easy, that would be wrong. You need to make decisions about where to start, how fast you can build that bridge. There are ways to do that but none are foolproof. Ultimately, as the teacher or coach, you need to make decisions and revise those decisions based on feedback.
In my experience I have met many people that claim they can teach and coach. Maybe they can. I know for sure though that I have heard many more people make these claims than I have seen “build a bridge”.
I drafted this blog a little while back. It has been sitting around waiting for me to come back and complete it. During my “muddling around” phase the following appeared in my twitter feed
A graphic was included with this tweet I have inserted a copy below. The timing of this was incredible and I love that it is based on the same analogy as my blog.
Thanks for dropping by.
I often hear how testing is part of life. I even use that, or related references, myself. Over the past few days I’ve been able to observe life and testing intersecting in a setting that is not part of my “everyday life”. This story starts at 12:30am, Saturday morning. My Wife wakes me up complaining of pain that is radiating into her chest. It is a heavy pain. We have a local service where we can phone a doctor for an after hours visit. This is proposed, I decide not.
Heuristic – this could be a heart attack. I can’t guess here. Criticality is high, the consequences of a bad call could be extreme. Therefore an unknown wait time for a doctor is pushed to one side.
I place a call, an ambulance is dispatched. Now I’m being coached by the dispatcher. Suddenly I’m part of a team. I’m being asked questions, I’m providing responses. Then I’m rummaging through our drugs cabinet looking for asprin. It strikes me that I’m suddenly part of a new team, we are, for all intents and purposes, pair testing. We are not sitting in the same location but we are working together, looking for signs that might give specific clues about what is going on.
Models – the dispatcher is building a model through our convesation, looking for certain key attributes of a problem. There were some indicators that this was not a heart attack but, at no time, was it dismissed. The possibility remained until proven otherwise through evidence.
The Paramedics that came to our place were incredible. One immediately went to my wife, the other stayed slightly distant. The one that went to my wife worked patiently and methodically through a list of questions. Blood pressure taken, pads attached and heart monitor engaged. Drugs for pain relief. Thinking back on this the Paramedics teamwork reminded me of airline pilots. One flying the aircraft, the other controlling communications but always as a team. When you are asking questions, hooking up machines you can’t really observe, but your buddy standing off a little can. This is important information that can be shared to benefit your patient. This reminded me of the notion of critical distance and its importance.
My wife and I received a “report” from the Paramedics. “We don’t think this is a heart attack but we can’t be completely sure. We suggest we take you to a hospital with a cardiac unit”
Through all this I failed to observe any detailed lists (Paramedic “test cases”) but I did observe lots of discussion, cross checking of ideas, checklists and medical attention. Each question was an experiment designed to reveal new information and a better understanding. We also got useful, easy to understand feedback (we could think of this as a test report) that gave us information upon which we could make choices. Risk assessment activities and risk mitigation options were quite evident.
The decision to go to hospital wasn’t a difficult one. What followed was a night in a major hospitals emergency department and a battery of tests. The handover in this situation, from Paramedics to Hospital, is interesting. Short, sharp, focussed, clear. The essential facts. History of the situation and what treatment has been given. It’s clear this has been done before but it is also clear that this process is about passing important information quickly so the patient can be given high quality care quickly. This process is lean.
The tests managed to rule out a heart attack but they were unable to identify the specific source of pain . I’m sure they had theories but access to tests that would assist diagnosis were not available at the time. We were issued with a letter to enable the other tests to be run two days later. We left the hospital knowing there was an undetected “bug” but, with a belief that the issue was not life threatening.
Lots of tests and checks were run during our 8 hours in Emergency. It’s a good reminder that tests can be quite specific to highlighting specific problems. While heart problems were ruled out those same tests could not determine the actual problem. Determining the best tests for the context is critical to success. Makes me think about the execution of test cases “because we always run them” or similar reasons.
Let’s skip forward about 36 hours. We have another large hospital within 10 minutes of our house. We are sitting in its Emergency Department. The pain my wife has been suffering has escalated significantly. The yet to be diagnosed “bug” has made its presence known and its severity has increased. The Triage Nurse goes through a series of checks, establishes history. We are pushed through to a treatment room in no time at all. It’s familiar territory, questions from doctors and nurses, establishing vital statistics, ECG, blood tests.
Even though the previous trip to hospital ruled out heart problems the searing, intense pain pushing into the chest, has doctors re-exploring this as primary concern. Given the really serious nature of a heart attack, reconfirming that a heart attack is not in progress, makes sense. Let’s not anchor to previous results when things might have changed and there are indications to support having another look. In a busy, stressful environment it could be easy to bias your investigations.
After a while the possibility of heart attack is again ruled out. That’s a relief bit there is clearly something amiss. Inspite of a massive dose of painkillers (including morphine) the pain remains extreme. The focus now moves to a gastrointestinal related issue. The tests change accordingly. A CT scan is organised, and there it is, the gall bladder is in a mess. The doctors want further details, confirmation and a basis on which they can figure out the best way to attack the problem. An ultra sound provides more evidence, further details about the specifics of the problem.
Now that testing has revealed the “bug” the process switches to an evidence gathering phase. What information can we gather to give us the best means of solving the problem? What other issues might there be? What do we need to prepare for? How will we know when we have been successful? How quickly do we need to move to optimise outcomes for the patient?
It turns out that good practice in this context is gall bladder removal using “key hole” surgery. The real interesting bit is that the surgeons felt it would be a good idea to have a look around while operating just to make sure there were no other issues that might not have shown up in the scans (or perhaps were hinted but not highlighted). I know about exploratory surgery as an approach, I’ve just never thought about it when the “bug” has been identified. As it turned out they found an umbilical hernia and repaired that as well.
Keeping your mind open to possibilities, drawing on past experience, heuristics, models, talking to colleagues can lead to the discovery of “off script surprises”. We didn’t expect this approach but getting that hernia fixed delighted us and represents a lot of value.
I have no doubt that as I reflect more on what has happened that I will discover more parallels and even find ideas to experiment with in my work. I cannot help but see the benefits of teamwork and open, clear communication. There were no signs of panic or rush. There was a lot of questioning, critical thinking, exploring options and making decisions using various forms of feedback. Many areas of software development seem to fight these becoming meaningful attributes. We really do need to examine and overcome the resistance. If hospitals operated like many software developers and spoke about these attributes but never really valued them….. I can’t imagine what the mortality rate might be.
What I saw in action looked a lot like Agile. Do doctors and nurses think of themselves as working in an agile manner or do they just do things that optimise quality of care and patient outcomes? Perhaps that is two ways of saying the same thing?
There are bad experiences and good experiences but each gives us the opportunity to take away things we can learn from. I think I’ll be debriefing, and learning from, this one for a while.
Finally – the magnificent work of a group of surgeons and nurses meant that my wife returned home less than 24 hours after surgery. Recovery is on track and we are all grateful for the expertise that, for the most part, we take for granted.
There are many pleasures being involved in software development. I’ve been involved as a Business Analyst, Support Desk Lead and a Tester. Working with smart people, working with people that are passionate about doing a good job, meeting with likeminded people that enjoying discussing how things could be better (and actually do things to try and make that “better” happen). Of all my favourite things though nothing beats hearing that analogy that equates software development work to manufacturing or building. It just never gets old (you’re picking up on sarcasm at this point – I hope). As far as I can tell the discussion always seems to pop up in relation to estimation (and/or cost) and is often accompanied by the “oh shit” panic of a project in a bit of trouble. You know the sort of scenario:
Manager: I don’t understand the estimates we give. When I ask for a house to be built I get given a price, the house gets built and delivered within the date timeframes.
You: They’ve built that house before, right? I mean you’re asking for a new house but that house has been built before for others. You’ve seen the house, been in a display model of it. You’re asking for a copy of something that exists.
Manager: I don’t get your point. We’ve built software before. Our software exists.
You: We build software because the software doesn’t exist. Our clients ask us to build something new into the existing system. They have neither seen or experienced that functionality before in our system, and neither have we. We are not comparing like for like when we discuss software creation and house building. Perhaps you could ask your builder to add a swimming pool to your lounge room when they are half way through the build.
……and so the discussion goes until the inevitable conclusion where the analogy lives to fight another day.
When we compare thought/knowledge work (software development) to the manufacturing or building analogy it is accepted, by many, as a flawed comparison. That we are comparing “apples and oranges”. We can’t compare thinking to a machine stamping out widgets. When we are doing this we are comparing, what I’ll call “determined repeatability”, to the creation of something new. “Determined repeatability” is possible because we have spent time developing approaches, formulas, processes and formed them into a chain that produces what we (more specifically, our clients) desire. We can continue to process these widgets infinitum (as long as market forces maintain a demand). But market forces can be fickle, so can resourcing inputs. What happens if one of these changes and our processing chain loses its “determined repeatability”? What if the widget needs an update with the addition of new attributes? I wonder, is there a useful analogy if we change the target area of the analogy focus? I think when we compare the creation of software to manufacturing a widget we miss that the widget required research and development. Before the widget there wasn’t a widget. Someone had to spend time and money creating it. Now that the widget requires new features the “cut and stamp” process is disrupted. We have lost “determined repeatability” In this phase we potentially have a useful analogy with software development. In this phase of manufacturing we see thought, iteration, experimentation, exploration, failure, learning and finally a product that can be produced “cookie cutter” fashion.
I like aviation, actually more than like. It mystifies me even though I have a basic understanding of the forces at work. I can (and sometimes do) spend hours watching the big birds take off and land. To me it is a graceful blend of man and nature working together (leaving aside the engine emissions debate). The Wright brothers famous flight was on December 17 1903. On April 2005, a jet that stretched further than the Wrights’ first flight, took its own first flight. In slightly under a century it is a mighty impressive demonstration of human endeavour. If you’re interested, you can buy an A380-800. The average list price for one of these is a cool USD432.6 MILLION. (Personally I’m thinking of spending on the Boeing 787 Dreamliner. I can get 2 of those for the price of a single A380). I guess what I’m getting at here is that I can get a very sophisticated, highly technically complex aircraft for a known price and a known delivery date. As much as this sounds like it underplays the technology, at this point, the A380 is produced “cookie cutter” style, it’s a known quantity. When we compare software development to this, it “fails to fly”(pardon the pun).
Now let’s go back in time a bit the A380 does not exist. There are potential customers but the aircraft is not a reality. Let’s also remember this is not the first aircraft either. This is true for the Airbus company and a large and relatively thriving industry. You could be slightly flippant and say “they are just making a variation of what has been done before” (ever heard that before about software development – I have). There is no shortage of experience and knowledge but, and this is important, they are going to a place they have not gone before. This will be the largest commercial aircraft ever. Even if it wasn’t distinguishable on just that aspect it will be made with new age materials and technology. Some have been used before, some are new.
So how did it all go? You might know the answer, or have some knowledge of the situation, but in summary. Not so well. Let’s start with some headliners.
Originally scheduled for delivery in 2006, the aircraft’s entry into service was delayed by almost 2 years and the project was several billion dollars over budget.
There must have been some fascinating boardroom discussions as the project travelled along. I think it is worth re-iterating that this is a company that builds incredible aircraft, they employee knowledgeable, capable people. They have a history of building aircraft. They have a strong reputation. How could this go wrong?
At the heart of the problems were difficulties integrating the complex wiring system needed to operate the aircraft with the metal airframe through which the wiring needed to thread. With 530Km of wires, cables and wiring harnesses weave their way throughout the airframe. With more than 100,000 wires and 40,300 connectors performing 1,150 separate functions, the Airbus A380 has the most complex electrical system Airbus had ever designed. As the first prototype (registration F-WWOW) was being built in Toulouse France, engineers began to realize that they had a problem. Wires and their harnesses had been manufactured to specification, but during installation the wires turned out to be too short. Even though the cables were at times just a few centimetres too short, in an aircraft you can’t simply tug a cable to make it fit. As construction of the prototype continued Airbus management slowly came to the realization that the issue was not an isolated problem and that short wires was a pervasive issue throughout the design.
A single miscalculation. There were reasons behind the miscalculation (a chain of errors), but none the less, the impacts were really something. It also meant “back to the drawing board”, let’s examine and understand the failure, let’s find other ways to meet our objective. Who the hell saw that coming? The answer is nobody. If somebody had seen it coming it would have been prevented before it became a major problem.
I can’t prevent people wanting to make comparisons between software development and manufacturing or building. That’s beyond my control. What I can have some control over is my response. That response will now be to acknowledge there might be some validity but change the focus to the development phase, where there are similarities, and not the completed “cookie cutter” production cycle where there are few, if any, similarities. If you want to make a comparison between production line output and software development, then maybe we should be discussing the physical delivery of the completed code after completion of development. That just might be an equivalent analogy with stamping out widgets.
Thanks for dropping by
A big thank you to Lee Hawkins for his review and feedback