Tuesday, April 28, 2015

When great memory fails you

I've come to appreciate the idea that I have a pretty good memory. Let me start with a story from yesterday, testing in our application at work.

I was testing around, with a particular focus to a change we had just recently included. Business as usual, we change things all the time and deliver to production whenever they're ready. I was looking at the main screen of our application when a nagging feeling hit me: something was off. The user interface had just been completely changed last week and I had already gone through changes related to that and things were ok as far as I could tell. Already before I could tell what was wrong, I had a gut feeling there was something. The gut feeling made me stop, made me take a thorough approach on what there should be an notice that a feature had gone missing.

To support my memory, I create checklists, not test cases. The checklists enable to to create a map or hierarchy of things and their connections, and recall vast amounts of information. It's like building a product specific heuristic that helps me recognize patterns. People are pattern recognition machines, and this plays well with the implicit knowledge that I've acquired as a tester in this application for the last three years.

This experience reminded me of something we did over dinner at Agile Open North West in USA a few months back. My dinner party was trying to list the 50 states and with some brilliant minds, there was the confidence that they can do it. And yet both who tried ended up getting stuck without a complete list, until they collaborated to trigger the others' memory.

This lead me to two realizations about how I test:
  1. Great memory is supported with right toolset - and a mind-numbing list of test cases isn't the toolset in my mind
  2. Great memory fails us every now and then, and when it's relevant that it doesn't, the "executable specification" is a lovely, lovely idea. 

Monday, April 27, 2015

This boat leaks: women in tech

Last week, I met a few amazing ladies. These two women we're a little older than me (I'm 40 years old) and shared experiences with decades of doing behind them. Both ladies had been programmers, but were now testers or about to become testers.

Both ladies had started off in programming at time of Cobol. When their organizations moved on to Java, they both had volunteered to learn a new programming language. But their organizations reply really surprised me:

There's no reason to learn programming in Finland, as strategically our company is outsourcing all programming work to India.

Specification work and testing work will stay in large extent. But Java-programmers are cheaper elsewhere.

I was shocked. For me, the idea of sending all programming to India is absurd.

Our boat leaks with fundamental attitude issues.  Two technical women, who want to be technical and are encouraged not to be that. On one side, we work hard in Finland to introduce girls (as well as boys) early on to computing. And then we have major companies that drive the women we get on the industry away from the work by telling them there's no job security with that skillset. And job security matters, at least it did for these two ladies.

Tuesday, April 21, 2015

Fighting Enthropy taking us to Schedule over quality

Approaching a year, my team has been doing Continuous Delivery without Test Automation (or with very little test automation). We've lived a timeframe of quality over schedule, because with the chosen strategy, any feature we're working on gets released when it is done. If quality isn't up to par, the feature stays in development longer. We measure lead times and discuss reasons things start taking longer and have two common causes of delays: 1) not knowing how to to split the item and thus working with too large chunks, 2) skills and lack of pairing/collaboration to even up the gap.

Yesterday we talked about the latest significant feature we're working on: changing the user interface. It's one of these features where we don't do all of it at once, but the chunks we're doing are still quite significant in size. And there's unexpected side affects, throughout the application. But it's approaching ready and while we don't estimate work, we talk about ideas on when it would be in production. And we said to target Wednesday. We talked about the idea of "freezing" user interface look after the release until a major sales-related date about a month from now, and I was under the impression that we would understand it means that we deliver this feature as done without having to go back to it.

A day later, the time of deciding on whether we'd release it was at hand. From the undercurrent of the comments, I could see something had changed: it was "ready for production whenever we feel like putting it there, we can always fix it later". I was puzzled.

We had a discussion again on the basic idea: we work quality over schedule. Mentioning a schedule never means commitment to schedule over quality. For problems, we stop and fix, and then move on. 

It's interesting how easily, even with the experiences we have as a team, we were about to slip back to working against schedule. All it takes is a bit of wrong emphasis on a deadline. 

Monday, April 20, 2015

Vendor lock-in: It's a bug in contracts

For years, the Finnish software and testing community has remembered a public failure in product quality. VR (the Finnish railways) had significant problems with a new system after go-live and VR together with their contractor Accenture was all over news on the problems.

The talk of today is that the story has another turn: Accenture owns a core part of the source code this system is built on, effectively ensuring that no other contractor can deliver changes VR will need for the system. And the sum mentioned in press is 3 million euros.

This is an example of vendor-lock in. There's something in contracts and the way the development has been set up that ensures the customer will have no other choice but to buy more services from the original vendor.

In a Agile CxO open space within Agile Finland about half a year ago, I noticed that a common value companies discussing in the realm of agile contracting was to serve customers without creating a vendor lock-in. It came out so strongly, that it could almost be described a common value - believing no vendor lock-in is in the best interest of the customer. Software in agile is built with a change in mind.

Over the years, I've experienced many examples of vendor lock-in:
  • No code comments: in a project delivered, code was uncommented. No one had required it needs to be commented. 
  • Undescriptive variable names: sure, calling variable with one letter alphabets is concise but not helpful trying to figure out what the code does.
  • Choosing end-of-life open source component: in a project, the contractor drove a decision to use "tried-in-production" version where a newer was available, without mentioning that the newer existed as the old architecture wouldn't allow for changes needed - also for this customer. 
  • End-user pseudocode in specifying: having customer organization specify things in detail and translating that directly to code without code reuse by smart structures.
Vendor lock-in is a big bug in contracts between customers and contractors. It's a bug I've needed to report many times as a tester. It's a bug that I've been invited to remove before the contract is made, not only a bug with consequences to mitigate in acceptance testing phase. It can be a really expensive bug. 

Specifying in detail what is expected in contracts isn't helping. We need a change in mindsets: instead of the big contractors who repeatedly create intentional vendor lock-in, how about going for the smaller agile contracting companies.

If you want to find out who those are in Finland, ask which companies were part of Agile Finland Agile CxO discussions. Get involved in that group as a customer. You might also learn ways of acquiring your software so that you get value in production earlier, more effectively and efficiently and not only right now in this project but actually designed with a change in mind: continuously.

Sunday, April 19, 2015

Organising Women-only conference

I volunteered with Speak Easy and am now organising Speak Easy World Tour 2015 as the international conference chair. It's a 'unique female conference' providing a stage to give room for female voices and experiences of testing to be shared, and it will be video'd and thus shared for crowds larger than the local participants.

For quite some time, I've been thinking of setting up a signature webinar series, as a chance of getting your talking work sample - the best one - shared and promoted. And with the world tour emerging, I feel it is one step towards having more samples available out there, when considering new speakers.

I'm usually very careful with women-only conferences. While in the masses of great people who want to share stuff of testing is so many women that you really don't need to choose based on gender but content, I've grown to appreciate the idea that balancing the availability of female samples and stories with women-only conference is good. However, I would hope the contents reach a diverse audience of both genders.

When deciding I would support this by volunteering, I had a discussion with a friend. She feels even more strongly than me that we shouldn't do separation. Separation is unnatural.

What is unnatural is however cultural. It's seriously unnatural in Finland which I find to be a very gender-equal place in general. It might not as unnatural for countries where all-female schools still exist or where the culture is essentially more patriarchal.

It's as unnatural as the water taps in UK. Seriously, how do you wash your hands when you have to get separate taps for hot and cold?


Organising a women-only conference is a bit like these taps. We open only one of the taps to let in ideas from that group. We'd really want them all coming out from the same tap, but meanwhile, in culture change, we just need to find another way to mixing things to be just right in balance.

Another friend reminded me that women in medicine were not invited, welcomed and helped in either. They just decided to show up and that is what we should do in general. I think I might need to get over my "invite me and I show up" idea, which is just playing with the general observation that technical speaker women are not that common and expecting special service. The friend had a point: in his life, he has heard more "no" than I have, because he asks. That goes for personal life as well as professional. 

Friday, April 17, 2015

Conferences and women of merit

What I want to say about conferences in general and without women keynoters in particular does not fit in a tweet. I'm posting my points after a long consideration of whether I really want to say anything about this. With my share of pondering, offloading what is on my mind seems necessary.

You might know what I'm talking about: EuroSTAR 2015. Choosing keynotes based on merit. And end result is that there's no women.

Should testing conferences care about women?

A few weeks ago, a post in my Facebook feed piqued my attention enough so that I read it. The next day, I heard a podcast about the same story. It was a story about a 12-year old girl who realised that in games she loves playing, there were no characters that look like her. She did her research in a particular game genre to learn that 15 % of games had female characters for free and even with money, only 46 % would offer female characters. Her message was published in Washington post, and her message is very powerful.
"These biases affect young girls like me," wrote Madeline Messer. "The lack of girl characters implies that girls are not equal to boys and they don't deserve characters that look like them. I am a girl; I prefer being a girl in these games. I do not want to pay to be a girl."
I work in testing. I love testing. And testing as a field has lots of women - more than programming. In communities I facilitate, there's easily more women than men. In testing conferences in Finland, the same applies. I have a male friend, who opens introductory testing talks at universities on why should you join the field of testing with a half-serious joke: it's the community where you actually get to meet women, even be surrounded by women.

When Lisa Crispin pointed out publicly what many of us thought on lack of women in keynotes in EuroSTAR 2015, I was disappointed. It's like I, at the age of 40, need to have the same realisation Madeline had: there's no role models for me.

These biases affect women like me. The lack of women keynotes implies that women are not equal to men and they don't deserve the keynotes by people who look like them. I'm a woman; I prefer women keynoters in these conferences as my role models. A 12-year old girl can inspire a 40-year old woman. And the young women joining tech in masses with future generations need to come to a community where they are not an abnormality.

Saying there's other minorities ignored seems to be missing the point. Women in testing are not a minority. Women in conferences as speakers and participants, particularly in EuroSTAR, may be a minority. Perhaps lack of models has something to do with that too?

Where's the merit, really?

The responses of programme chairs from 2014 (Paul Gerrard and 2015 (Ruud Teunissen) seemed a bit odd from my perspective. Having been in EuroSTAR program committee with Michael Bolton as the chairman in 2013, there's a bit of an insight available what might happen in Galway when the programme is being built.  The part that mostly ended up being my focus was that the committee chooses on merit and if women are not on the program, it's implied that it's on lack of merit as well as not submitting.

As for my experience, keynotes are invited talks (paid for with an honorarium). Ruud mentions in his blog post he denied everyone who contacted him personally about keynote the honour. Choosing from the track submissions isn't something that happens every year. It might have happened this year. It did not happen in 2013.

This leaves me wondering: really, in the field of testing and ideas inspiring testing in practice as the EuroSTAR theme, there's no women of merit to invite? Fortunately there's the relative rule (thanks Michael Bolton for this!), and we can always add the silent "that I'm aware of or would care about" that we always add to statements like this. Merit, just like quality, is relative. An unrepresentative program committee would have hard time representing all views of merit with our significant research work in the community.

It's not hard to find both men and women to talk to about testing, to share experiences, to learn from one another. For me, it's sometimes hard to find the men to do talks, since I seem to be biased into chatting up every woman I find to learn what they could talk about that I could learn from. I do the same for men, if time permits. I would claim on average I strike a balance of  genders when inviting. I can easily list 100 worthy women to hear in EuroSTAR keynotes, and there's great women in the topics that the current program lists as themes in keynotes. Were they really equally considered? Why is admitting personal bias so hard on this?

I can list great women, because I actively look for role models that are like me. And I know many women who find gender more relevant than I do in finding their role models.

Pamela Gay in one of her astronomycasts  (there's a woman to admire!) shares a story about achievements and bias in assessing. For an achievement that a man has always been offered tenure, a woman gets assessments implying she isn't worthy as she does not walk on water. Are we really assessed on the same criteria? Or are women actually expected to be just a little better to even be considered on the lists that the male-only committees make on potential keynotes?

Merit in keynoting is two things

I view merit for speaking as a keynote as a combination of two things.

  1. Presentation skills

    There's the presentation skills and experience. And I find it natural, that a native English-speaker gets favored on that. It's wonderful when the language skill is well versed in doing the talk. EuroSTAR has a LOT of native english-speaker keynotes with emphasis on USA and Canada (not Europe) and UK and rest of Europe is underrepresented, it would seem. But it does create the idea that great testing might not happen around Europe. I've really appreciated Jurgen Appelo for creating the vision for ALE (Agile Lean Europe) to show that we do great stuff also around Europe and would love to see something similar for testing.

    There's a number of very educating, well presented and fun keynotes that you can't remember at all the next day. It's a pleasure to see someone who is well versed in presenting, but in a technical conference (testing, even business-facing, is technical), wouldn't we seek contents we can apply as inspiration for our work? They could be from anywhere in the world, but for EuroSTAR, you might want to expect Europe to be heavily represented too.
  2. Relevant content

    Since we all have our unique experiences, stories to share and ideas on how to put those together for a talk, I would argue that everyone I have met had unique and relevant content. Your experiences and my experiences will be different.

    Some might have content that is more fine-tuned and polished, collected over longer periods of time. Some might have experiences that are particularly inspiring and motivating. But as far as I can see it, it's arrogant to claim that the stuff that made it in the program would be with most content merit out of all opportunities in the world. You might just not have looked around. For the EuroSTAR conference theme in particular, "Walking the talk", it might appear you are looking for experienced practitioners - and there's plenty of inspiring people with merit - women included - in that side of testing. 

Passing responsibility to submitters

Agreeably, probably any of the women I have in mind as great keynotes did not submit. I for sure did not submit. You could say that lack of women in keynoters is because we don't submit. But instead of passively waiting for submissions, there's also the reaching out and listening part a committee should do.

Submitting a proposal for a conference is hard work. I prepare the talk to do my submission and that is a relevant portion of time to use. In the last year, I've submitted to five international conferences and got accepted to six - that is, there was one that knows that in general I'm not submitting as I'm against the pay-to-speak work-for-free-without-reward ideas that often are embedded in conferences. I work for free in collaboration with conference organisers, to prune one out of my hundreds of possible talk ideas whenever they contact me. Hundreds of ideas is easy, when you work as hands-on, full time tester and have been around a little. Some conference organisers work with me on the perfect talk for them. I wish there was more of thats style, regardless of gender, as we waste a lot of energy into reviewing well-formatted ideas that get abandoned as they are not right for the conference and badly-formatted ideas that would be right but get rejected because the message does not come across as the foundation work was not yet done to expected level.

Relevant diversity of three aspects

There's three aspects of diversity that I invite focus on that EuroSTAR misses:

  • the population / profession gender balance - testing has a lot of women yet none of the keynotes looks like me. 
  • the European balance - UK is not the only European country and US/Canada are overrepresented as we don't do our research in Europe
  • the product company vs. testing service company balance - I'd like to hear more from companies that need to do testing, but that don't have a business incentive to make that particularly visible

Out of these three aspects of diversity I really miss one. I've not gone to a single EuroSTAR where I did not speak at or program committee at. Having been to three or four, I know that out of all the conferences I've been to, EuroSTAR has been giving me the least value. Meeting other participants is great, the masses in large conference have brilliant minds. But the sessions have not been worth the time and money invested. Too many sales-style talks, which I attribute for the lack of diversity in people in product companies (not selling testing).  It would be a much harder case to make that I would pay to speak when my company isn't getting sales-related visibility from that, as testers are not my company's audience. And Pay-to-speak is the EuroSTAR model. So you might want to consider taking your submitting time and your conference money where the model is fair for speakers and does not drive sales-oriented contents. Try TestBash, Agile Testing Days or BTD Conference, just to mention few, for conferences that do not build their business on people who have to pay to speak.

Inspired by Madeline, the 12-year old, I might need to add the gender balance on my list of reasons of not going to EuroSTAR. I want to see hope that I could one day stand on that keynote podium. If none of the other brilliant women have the merit, why would I believe I should? Keynotes are invited, not suggested for most of it.



Monday, April 13, 2015

The feeling of testing something new

During weekend, I did research on open source projects I'd like to use as test targets for testing courses. It needs to be something conceptually easy enough so that people don't get lost and focus energies on something other than learning testing. And for this particular time, it needed to be something simple enough yet deep enough for relevant bugs, with ability of actually building it from scratch. That is, I'm preparing with Llewellyn Falco for our workshop in XP2015 in Helsinki: Collaborative Exploratory and Unit Testing - How to harness the insight of bug discovery to protect your code.

Browsing through the options, I realized I was feeling uneasy, almost afraid. What if I would find software where I could not find bugs? What if I couldn't come up with insights of any kind? What if I can test the system I test at work,  but not other systems? On the other hand, I know that I know what I'm doing when testing. But facing a new system, I could not help but feeling like I was an impostor.

The feeling took me back to time three years ago, when I had been doing test management with way too little hands-on testing. I felt similar fear and uncertainty back then. I think I feel it with every system I start with, and it fades away as I grow into the product I'm testing.

The feeling passed quickly when I found insights of things that are missing and things that don't quite work. I started building a mindmap, collecting things I would need to look into and their connections. That alone made me feel useful, something tangible to tell the story of where I focused on was being created. But the bugs in particular gave back my confidence.

Knowing that I still have it is comforting: the ability to learn new products to find out how they might not provide the value they're expected to. I will need that when jumping into the world of unit testing. This workshop is about to be so much fun. See some of you there - XP2015 in end of May in Helsinki? 

Sunday, April 12, 2015

Identifying contributions: on doing vs helping

Over the last few days, I've been thinking about a tweet exchange with Michael Bolton. It seems we feel very differently about the need to separate who does a thing in development (programmer) and who helps do it (tester). And I realize my perception of this has changed a lot with working in agile projects.
In agile projects, it's typical to work in pairs or groups. In a group, we don't discuss who is doing  and who is helping as both contribute. We don't care. I don't care.

I find that it suits my personality and style of doing things in general. I go around meeting people and hear things others would be interested in but don't manage to get forward with in organising. I take the idea, pass it around to a few other people to seek the energy and in a few weeks, we're having a meetup to share ideas and experiences on the topic. Without the person who triggered me, nothing would happen. Without me, the session wouldn't happen. We both contribute to a common goal and attribution of pieces just seems irrelevant. We're in it together but the need to attribute individual contributions sits deep. I hear a lot of people telling they did nothing in these interactions, while I recognize that their contribution was the force that set things forward.

Think about it this way. Imagine you're baking a cake. You'll need sugar, eggs, flour and a bit of vanilla for the flavor. With your recipe, the cake is really good. Which of the ingredients contributes to the goodness? Can you leave out the sugar? Can you drop vanilla, since that's the smallest portion in the ingredients? All of the ingredients are actually necessary, and you can't really tell which one of them individually contributes what to the goodness of the cake. The right answer to me seems to be: I don't care. I care that the cake is good.

In doing something in team together, I don't care whose contribution it is. Without the help (if that is is what you want to see a tester contributing) the end result is different - and I believe inferior. Identifying individual contributions and focusing on roles rather than skills we bring into the collaboration seems like a dead end to me.

I was given advice on getting all wind up about this with an unattributed proverb:
Don't get into argument with an idiot. He'll drag you down to his level and beat you with his experience.

The advice kind of sums up what I still haven't learned: arguing over semantics is a waste of time. Arguing in general is a waste of time. I'm reading now Deborah Tannen's book The Argument Culture: Moving from Debate to Dialogue / Stopping America's War of Words, and that text resonates big time with what is going on in the testing community. But that is a topic for another post.

Just for the record: I admire Michael and don't think he is an idiot, quite contrary. I should learn to pick my battles, and on this one we're just fundamentally coming from a different place. I recognize that and continue admiring him and his contribution to my self-understanding as well as testing profession in general.


Wednesday, April 8, 2015

Illusion of projects

Inspired by a talk on "Project Design" in San Diego .NET user group tonight, I feel the urge to write about past experiences on projects. The inspiration may not be in the form intended by the speaker, as I felt extreme happiness in not sharing values he communicated about big up-front design and class division of non-coding architects and replaceable developers. But something he said triggered my memory: never being on a failed project, or project that would be over budget, late from schedule or delivered with bad quality.

In one of my past places of work, there was a project manager most people admired and liked. I liked him, as he was a very nice person to talk to and was driven, making things easier for people in his projects. His reputation after years of doing his work was that his projects succeeded.

As we worked in the same company, on same level for years, I had a chance to observe what might be keys to his success. He seemed to have identified a great recipe. He would always choose which project he would manage. The project would be one that was of utmost importance for our employer. If the project need something to succeed, that would be given. Often at the expense of other projects around, having to give up their critical people on critical times. One succeeds but all other ones fail.

Just like the speaker today, this project manager would go around telling people he has always delivered his projects on schedule, but making it also very clear that the "on budget" part means the latest approved budget, which could be significantly different with where the project started from. In public, I don't recall him mentioning the detrimental impact his projects had on other projects around him, but in private he was smart enough to see that.

In the session today, the speaker mentioned developers being assigned to other projects before start of system testing - a pattern that usually spells catastrophe in my experience. I've seen the bugs hidden and pushed away until they surface in a later project. One person's catastrophe can be another's success: project completed on time and budget and scope, and bugs fixed in a new maintenance project for twice the hourly rate might sound ideal from the contractor's perspective.

There's this whole field of illusions, that need dispelling around projects. If we find ways of delivering continuously to production, the need of a "project" goes away, we manage a process instead of project. We deal with reality instead of plans. The project managers, architects and test managers with status may not always like it, but instead of paying 5M for a 1M project just so that a person of status can "always deliver on time, budget and scope/quality", we could stop accepting the mediocrity that self-fulfilling bloated plans drive us to. We could accept that software development includes learning on all levels. Requirements don't change as much as we think, our understanding of them evolves. Sometimes our understanding evolves so much that we'll actually require a completely different system.

We really need to think about people: what kind of environment makes us, together, deliver the best possible solutions. I have hard time believing big design up front would have much to do with that. 

Sunday, April 5, 2015

Being your own worst enemy - an experience in code reviews

Back at work for one of my teams, we were struggling to get code reviews somehow included into out ways of working. People would always work on individual areas, and getting on someone else's area was deemed hard.

The team's architect had been contributing on code review front a lot, and was at a point where he said the work needs to be shared. So the team was discussing how to get that done, without being able to significantly put time into reviewing.

Many voiced out the concern that reviewing without understanding what the change is about (feature this adds) is like proofreading and not really the thing they'd be into. And understanding the change - as they tended to not be that small - would take an effort, as even the basis that was being changed was not well understood by others.

I would throw out various suggestions from pair programming (continuous code review, really) to people presenting the change and code to another developer, and we went for this: agreeing a pair for a sprint (month) and having at least one one-hour present and discuss session. And as it turned out, the pairs without me would be uneven, so I would of course volunteer in the circle, not really looking forward to it.

With names picked out of a hat, I would have my pair. We'd schedule a time, with the difference to other pairs that there would not be my code to show as I did not produce any. So we went for half the time.

At time of review, there was nothing indicating that the developer thought that the whole pairing up with me was silly - except things going on in my own head. I "knew" he'd rather have some of the more advanced developers with him. I "knew" he did not really want to explain stuff to me. And I kept all my discomfort inside me, and did what I could.

He showed the code and his changes, and I was mostly just puzzled. His code seemed very straightforward, his explanations made sense to whatever degree I could judge, and we kept browsing. We very soon run into code that had been commented out, many times. I would ask why that was there, and after a few of those questions his "I might need this later" turned into "let's take them out while we're at it, I always forget to clean them up later".

As our time was up, I felt I had been very little use again. But now six months later, that developer having left the company to be replaced by another, I started appreciating even this little contribution: removing the clutter that really made it harder to read.

I also realized that in situations like this, I tend to be my own worst enemy. I'm the one who expects more of me, while others do not. I mirror my own insecurities into others, and forget to celebrate the little successes and learnings. 

Thursday, April 2, 2015

Thinking of a great conference talk

I really, really enjoyed #TestBash last week. As another senior professional pointed out, it was surprising that most of the presentations were experience reports - a style of presenting I usually have to go to peer conferences for. The stories were (supposingly) real even if in the presenter's perspective. Each experience had a lesson to learn. Just my kind of content.

This week I'm in #stpcon. And while I enjoy the conference, I'm puzzled. Out of my sample, I seemed to be the only one who delivered an experience report. My style of talking was clearly very different, and I started to think about if it was actually inappropriate.

This leads me to sharing a few ideas that a friend helped me figure out.

Don't forget the newcomers

Every five years our industry doubles. That means half of people has less than five years of experience. There's a lot of newcomers in the conferences. They have not heard the basic theory of risk-based testing, security testing, performance testing, exploratory testing, proper test documentation or the sort. A class that gives a theory instead of an experience on one of these topics could be really useful for them.

Where I go to conferences to learn about new ideas and deeper experiences, a newcomer might not be ready to absorb the same information.

There could be talks that have layers that make sense for newcomers and seasoned professionals. There could be talks that are targeted for an audience.

Scan Agile tried splitting things into basic / advanced in three layers, but as far as the people I interacted with saw it, did not do that good a job in sticking to the expected level. The basics had in-depth contents, and the advanced had basic concepts. It's really not easy.

New presenters model their presentations from majority of current presenters

When a new person starts thinking of steps to take to become a presenter, they'll be looking back to presentations they've seen. It's likely that a new presenter would model after majority of speakers. From #stpcon, the model would be a short class with a little audience interaction. From #testbash, the model would be an experience report that teaches through a story.

The conferences invite proposals, but seldom say which style they favor. And the blurbs don't really open up which type the talk will be.

There's a third format that we rarely see in testing conference sessions: something really practical, the show-and-tell of testing. Very few people show how they test. How they think and why. How you take a problem, apply a technique and come to a conclusion. Useful results instead of repeatable results, but modelling actual testing work. All hands-on sessions and simulations seem to happen in workshops, not conference sessions.

I've been thinking about presentation formats a lot as I volunteered with Speak Easy. I started mentoring someone who wants to speak, interestingly, about a topic I just talked about in #stpcon. His experiences would differ. But if we presented a theory based on what is said about that, our talks might be very similar. I got very excited about his case study, the experience report perspective. But listening to talk styles that others use, I'm thinking if I'm unfairly biased.

Do I really know what is the style that people enjoy? Is what I enjoy in any relation to what others enjoy, even seniors? And is the style needed essentially different for a newcomer? Do first time speakers deliver better talks in one style or another?  I really don't know and would love to discuss this.

As conference organizers, we should have a vision of what style we look for. And we should, as coaching of new presenters, have also coaching on the very different styles you might go and use.

The stories may not be true

The last of my ideas comes from Scan Agile. I listened to a great talk that was a compilation of project stories. My impression from the talk was that the stories of experiences were real, but that they were compiled into one imaginary project as it's growth story. I thought every story told was real.

After the talk, I learned that the lessons of the stories were real experiences, but the details were just made up. For a person leaving your project in trouble (this has happened), the reason why this happened was imaginary, one that made you feel more positive about the person leaving others in trouble and making a better, funnier story.

I asked around (¨10 people) to learn that the expectation of reality in story you tell was a 50:50 split in my sample. Some people thought that stories you tell in "I" format, must actually have happened to you. And some people thought that delivering a mark in audience memory is so important that you can just act out, that getting on stage is always a performance and you shouldn't really take it as reality but just delivering an idea you'd remember later.

Since this experience, I've become more suspicious. I also feel lying storytellers are wasting my time with their lies, when I could be spending time with someone who has an actual, honest story from their experience. And I'm recognizing there's a cultural difference on whether fake details of experiences are acceptable in technical conference talks. Then again, a great but false talk is much better use of my time if it invigorates my thinking, than one based on reality not delivered as wonderfully.

This is again something I would hope for better guidance on others' expectations.