Thursday, July 20, 2017

Presentations, Evangelizing, and Personas

As first posted on LinkedIn

The other day I was sitting down with a client and we were talking about one of my people that works with him. We'll call my person Ned for the sake of this article. As is generally part of my client touch-base discussions we talk about our people on project and how they are doing. His quick and immediate response was a good one. "Ned's great," followed by a thoughtful pause and, "Ned's good," less of a correction and more of a filling the gap in the conversation while he was still thinking. This is a good thing to hear, life is much better when your client likes the people you have working with them.
Then the client continued, "If I was to sit down with Ned for a beer and he pressed me for some feedback I do have something that I'd talk to him about." From there we proceeded to have a conversation about Ned's presentation skills. As part of our client engagement Ned was responsible for advocating for some new testing processes, technologies and models to up their quality organizationally wide. Part of this deliverable ended up being presenting BDD (Behaviour-Driven Development) to the implementation teams as well as following it up with real-time mentoring as they adopt the methodology.
The core goal of the presentation was not really to teach people how to BDD but rather introduce the concepts and gain their buy-in to why the new methodology was a good fit for the organization and therefore why they should adopt it with enthusiasm. Or to put it as the client did in our conversation, every presentation is your opportunity to 'evangelize your perspective.' He even took it a step further, as a high-concept design digital media company they give training to every team member on improving the quality of their pitches. Internally or externally, they practice excelling at their presentation skills.
Now Ned, as a tech professional at a fairly senior level has given a lot of presentations in his time. I have been there on a number of occasions when Ned has been presenting and he is really not bad; above average for most tech presenters. But, as many of you may be aware, that's a pretty low bar. He had, however fallen prey to one of the most common pitfalls in presenting, creating a PowerPoint with a lot of text in it and then reading from the slides more than owning the material as he was presenting it.
The key to absorption and retention of your presentation materials is always engagement. It doesn't matter if you have the most important information imaginable, if you can't engage your audience's interest they probably won't absorb and understand your message as you deliver it and even if there is a glimmer of understanding it won't be retained. Probably the most intangible part of engagement is your ability to capture the attention of the room. The internet is filled with tips to accomplish this, so it won't be covered her in depth but one of the cornerstone concepts to this is passion and enthusiasm.
An audience can tell when a presenter really cares about their content. They know the content so well that they don't have to refer back to their slides with anything more than a cursory glance. The presentation is filled with anecdotes, examples and explanations that seem to come from their own experiences. Their eyes glow with excitement when they tell one of their stories, or similarly you can see them remember the pain when the story isn't one of success. This presenter never has to read from the slides, they know each slide and what they want to say about it intimately. This comes through and forms a connection with the audience. They feel this passion and it produces a feedback of passion for themselves and results in better engagement.
Perhaps the most important factor in capturing the attention and interest of your audience is that of presenting your content in a way that relates to each member of your audience personally. It's often said that you have to know your target. This isn't always easy, often in a technical presentation you will have multiple interest groups present for the meeting. This doesn't, however, change the need. Coming back to our example of Ned, he was presenting to his audience their first view of BDD. The goal was to create a shared interest and base level of knowledge that would allow the team to adopt the use of BDD in their next project. At an even more core level it was to build enthusiasm and buy-in for the BDD methodology. Buy-in is the secret sauce in adopting any new approach. People will be much more tolerant of adoption pains if they believe in the end goals.
In this case the audience consisted of four main groups, developers, designers, user experience (UX) and project management. The presentation was well put together technically and had no problem at all capturing the hearts and minds of the developers. This, however, wasn't to be unexpected because BDD as a methodology is targeted to solve a lot of pain points for developers. The goal that it didn't attain is converting the designers and UX members of the audience to becoming advocates of BDD themselves. They were left a little confused and nonplussed. A part of this may have been the presentation delivery, or at least a more powerful talk may have won more people over. In unpacking the situation a little further however we discovered that the problem may have been more around the concept of targeting the members of the audience. Perhaps the presentation didn't do a great job of building a connection with everyone present. In this example this problem was actually quite short lived. In the next phase Ned ran a workshop to kick off BDD that all parties were present for, and the parties quickly became aligned with the goals and value of BDD. In a workshop, not only did the methodology itself speak to its value but Ned became impassioned and obviously checked-in. This was something that was felt and embraced by all members present.
When I was looking at this situation with fresh eyes an example quickly came to my mind. What if, in one of the early slides, Ned had said to the designers and UX people, "Have you ever worked your heart out producing a great design for a beautiful product and handed it over to development, who took it and worked their hearts out building something great. Then when they handed it back to you, you took a look and your first thought is, 'But why did you build THIS?'" Then, when he saw the nods from the crowd he could have said, "Breaking down communication barriers and building alignment for the targets early eliminates this kind of situation. THIS is what BDD does for you!" Instantly he would have buy-in because this is a real pain point for everyone building a product. This buy-in would translate to engagement and people relating to the material quicker and understanding more.
Ned and I sat down after my client meeting and we had a chat about everything I've said above. Ned is a great guy, one of those rare birds that is absolutely receptive to feedback about his performance. We were having a great conversation about some tips and tricks that could improve his presentations. I said to Ned that on each and every slide of his deck he should be ask himself, "What do I have on this slide to speak to each member of my audience?" By asking this question continuously you ensure that your are going to capture and retain the interest of everyone in the room. It would be a little onerous to ask this question of each and every member of the audience. But you don't need to do that, you can assign people to personas. A persona is a short (one paragraph) description of a typical user or audience member (in this case) grouped by their interests. It describes what they do and more importantly what they care about at a base level in doing their job. Ned could assign 3 or 4 personas for the people in his audience and ask the question about the representative description. Another suggestion I had was to spend a little time at the beginning of preparing your presentation to put together a slide that lists the personas that you intend to target with your presentation. You would mark this slide as hidden but be able to quickly refer to it as you prepare your presentation and then later as you prepare to make the presentation. It is always good to have a solid idea of your targets in mind throughout your delivery.
In the end I don't have any fear that Ned is on his way to becoming a masterful presenter. The odds are good that he will surpass myself any day now (I don't claim to be masterful at presenting myself). Ned will accomplish this by an unwavering focus on who is in his audience and remembering to target each of them throughout. By asking that question on each slide and referring back to his personas captured in the hidden slide he can practically guarantee engagement. Ned should also remember to be himself, own the presentation, and not be afraid to demonstrate his passion.

Monday, July 17, 2017

Some Speakings

Some speaking dates set up for this year.

CAST 2017

I am speaking, two talks, at CAST 2017 this year in August, in Nashville.
- Augmenting the Agile Team - A Testing Success Story - and
- Technical Nomads - Stemming the Migration of Senior Talent

More about CAST 2017 over here - and my talks are summarized here.


StarWest


I am giving one talk at StartWest this year in Anneheim in October
- Augmenting Regression Testing in Agile Teams

Talk summary over here - includes a promo video that I created.  (you can tell I created it)


Confoo


And in December I'm giving two talks at Confoo.  This one's in Vancouver.
- Augmenting the Agile Team - A Testing Success Story - and
Lessons Learned in Adopting a Guru Track Career Path

More about Confoo Vancouver  over here.  

You may have noticed something, there are really only 2 talks here.  Some titles and summaries vary but the core contents are the same.  Which is ok, I'm not sure I have the time or motivation to come up with a 3rd or 4th talk this year

Monday, August 22, 2016

CAST 2016 - Presenting, Learning, Enjoying


Last fall I learned about AST for the first time.  That's AST - The Association for Software Testing.  Prior to this I haven't spent a lot of time involved with professional organizations, mostly because they haven't seemed very aligned with my professional interests.  I was with ASQ for a little while.  I learned a lot from ASQ and my time with them but for the most part they weren't focusing in the areas that I was and they were just too formal for me to relate to them well. 

AST is a little different.  They do have conversations about things that I consider pertinent.  Whereas ASQ is at the very formal end of software testing when it talks about testing at all, AST is having the conversations that I'm interested in.  Like, how to make exploratory testing safe and relevant.  Or, how much automation to really do and how to do it.  Or is Test Manager a dying title.  Relevant enough that this year I asked to speak for them.  I didn't make the first cut but I was brought in as a backup when another speaker had to bow out.  

I had been working on a talk for a little bit that had as its core intent making testers understand Agile better, understand their place in it and what it can do for them.  With this information in their toolkit, when it comes time to iterate the process and make it better, (something core to the agile ideal) they can change the system in a way that makes more sense for testing and therefore quality.  

I thought that there would be a little bit of fun in walking through a list of reasons of how agile is good for testers.   When I started my process I arbitrarily picked the number 23 as the number of reasons that I would have.  Upon reflection, partially for timing in a 40 minute presentation and partially because 23 was a daunting number, I settled on 17 reasons.  In the end I didn't have a lot of trouble coming up with 17 reasons and could have done 23 if I had to. 

In the last session of the conference I still managed to get 35 people into a room to listen to me talk about agile and the reasons why it's good for testers.  I do recommend that you NOT assume that the schedule from day 2 to day 3 of the conference you're attending is the same just because it looks the same.  I thought I was 10 minutes early for my talk, time to get setup and relax, but rather I was 5 minutes late.  The crowd was pretty tolerant though.  The talk went well.  This was my first conference, both attending and speaking and the talks weren't that much more stressful than a meetup talk.

Because, I believe, I said that I was happy to facilitate and did have some experience, I received the honour of facilitating 3 talks at the conference as well.   This was made even more interesting by the k-card conference facilitation system, which I learned on the fly at the conference.   After seeing a couple of sessions operate with the cards I was totally on board with the concept and was all prepared to facilitate the hell out of my first session. Facilitating at a CAST conference means getting up at the start, giving a brief introduction for the speaker, dealing with any issues and then sitting down until the end unless there are crowd necessary interruptions.  Anne-Marie Charrett was my first speaker.  Anne-Marie, the self-titled Maverick Tester, came and and told me that things had gone awry.  Her newly acquired laptop couldn't perform and she was going to hold a discussion group sort of thing instead.  I said, 'no problem.'  We never touched the k-cards and had a hour long discussion about trust, what it means, how to gain it and how to lose it.  It was one of the high points of the conference for me.  Anne-Marie also gave a good keynote about whether the idea of 'Test Manager' was dead. 


The next day I was completely floored by a presentation called, hmm, Neurodiversity in Software Development (i think) by Sallyann Freudenberg.  It was astoundingly riveting and fascinating.  Never before had I seen the case for including a neuro diverse group of people on your team put so well.  So many things to think about there.  The rest of my day on day two was spoken for.  I facilitated two more discussions, one on implementation of exploratory testing and one on lessons learned in 25 years of being a rockstar in testing.  They both went well and the facilitation wasn't particularly challenging.  Well, in the latter I had to track people who were voting on songs to indicate they were Canadian artists.  But that just made it more fun. 

Last session of the last day fell to myself.  I took the session before off to review my notes.  Not sure it made a large difference.  I was ready, and as I said above, I was late.   I went into the auditorium 10 minutes early, something I'd been doing all day because of facilitation.  Only this time there were 22 people sitting there already.  I made a joke about keeners and was told that I was actually 5 minutes late.  And they were right.  I was embarrassed, so I got set up as quickly as I could and got started, without my facilitator (who was also late).  I sailed through my presentation, barely looking at my notes.  Everything went very well.  As far as I can tell, I do OK as a presenter.  I could have slowed down some but I didn't so that I could make sure I got through all 17 of my reasons.  I was worried about the late start.  It wasn't a problem at all though and I finished a couple of minutes early.  There were some good questions.  Enough people had filtered in that I had 35 total attendees.  Given that there were four presentations going and it was the last presentation of the conference, I was pretty happy with the outcome. 

Link to the slides - 17 Reasons Why Agile is Good for Testers

I will go to a conference again.  I will probably speak again as well. 

Tuesday, April 5, 2016

There are three types of people

This past weekend we went out for a walk as a family and I came to a bit of a realization.  My wife, myself and my 3 year old represent each of these panels.  There really isn't much wrong with the first two methods of hill climbing although there are a lot of parallels in life that aren't too far off this description that probably provide more judgement that I would place on the hill climbers themselves.  

As I drew the three panels I knew that there would be engineers out there that would complain so I added them.  And when an engineer builds it...a salesperson will always pop up to try to sell it. 


Wednesday, March 30, 2016

Failures in Recruitment - Episode 11

Our recruiter set up a phone interview with a candidate. You can tell it was a phone interview because the meeting request had a phone number in the 'Location' and in the text it said, "I will call you at 1 pm."


The candidate shows up at our office at 12:55. Our recruiter was a little flummoxed. The candidate is wearing jeans, T-shirt, ball cap. Awkward. But the recruiter pulls through and does the interview like a champ. 


The candidate proceeds to tell our recruiter the story of how he was trained as a pharmacist but then spent 6 months with a testing guru learning the ways of QA and then was ushered across the seas to begin his career. Odd.


The candidate's resume doesn't have a last name. Their 12 letter first name is there so maybe that makes up for it. Their first name is also the first part of their gmail address, only missing a single letter right in the middle that makes no reasonable sense in its absence. Maybe this is correct but my QA brain says that maybe something is awry here.


Everything about this candidate says they will be the perfect addition as a client facing professional, no?

Friday, July 17, 2015

Be the best at what you can be?

This morning I was reading an article by James Altucher in which he was talking about what it takes to become as good as you can be at something.  It was an interesting article, I find a lot of what Altucher writes to be pretty interesting.  But there was one thing in it that took me off onto a tangent that I found of particular significance.

If you're in the top 1% of any particular ability on this planet that really only means you have to be as good as 70 million other people.  His statement around it was, 'that seems doable.'  On one level I can't find anything to fault with his argument.  Then I started to think about it some more.  What am I better at than 99% of the rest of humanity?  What am I better at that I can say six billion, nine-hundred seventy million people don't hold at candle up to me?  That's where my mind boggled.

You see, I'm really quite good at a lot of things. Really I'm an excellent all-around-er.  But I don't really know that I'm incredible at any one thing.  If someone comes to me and asks me what my absolute best skill is I don't think I could come up with a good answer.  I could list off some of the things that I excel at:  I'm quite witty and come up with good comebacks really quite fast on a very regular basis, I lead my teams pretty well into being high performers who like their job, myself their company, I am quite good about focusing on quality in process and software, I'm a really good cuddler....  See the list is a little sad when you start to put it down.

I know that there are a lot of you out there that have a skill that you've found and nurtured and worked on and while you may not come in first all the time when you compete, even if you're top 5 on a regular (or hell even irregular basis), you're likely in that 1%.   I applaud this and you should really consider it in this fashion before you get depressed that you don't win more often.  Realistically, if you run in iron-mans and come dead last each and every time, you're in the 1% because there aren't 70 million people out there doing iron-mans and you've got to be better than most of the people who've never done one.

But to be better than over six billion other people at something?  I don't really compete on a wider scale on anything so there's not really any meaningful measuring stick with which to gauge myself.  The closest I really come is in my career.  I'm pretty damned good at what I do.  Am I the best?  Heck no.  Could I improve, heck yes.  Do I try to improve on a regular basis, of course, but certainly not with the single-mindedness that gets someone like Serena Williams to the top of her game.  Do I need to be in the top 1% at something?  I'd like to be for sure.   In order to be able to claim that and back it up, I'd have to either prove it in some way or just decide that that was something I could say and argue reasonably.  That takes some level of ego that isn't really me.  It also probably relates to my QA brain, if you make a statement you're serious about, there'd better be some factual basis for it.

One of our core values at Hootsuite is 'leading with humility.'  I think that this means that you don't have to think you're the best at something or even say you're the best.  Instead what it means, I think, is that you strive to be the best in what you do and put yourself out there while doing it.  Everyone watching you can learn from the things that you do that work as well as learning from the things that you do that don't work.  If you work in a manner that allows for the notion that you are always looking to find a better way, then that's really the only example you need to provide.  If you're not doing it the best manner and you've embraced leading with humility and always looking for a better way then the people following your lead will be willing to form a community that can help you improve.  Respect is definitely a merit based system. Earn it in all you do but being the best is only one path to respect.

It helps if you're pretty good at what you do when you start so that people do look to you to lead.  It helps even more if you're in that top 1%.   Everyone wants more successes than fails so when we hire we really try for that 1%.  I'm not sure that when we hire, though, that we try to hire people that think they are in the 1%.  Reducing ego's in our work culture is another of our strong goals.  So am I the best of the best at what I do?  Maybe I am, maybe I'm not.  It really doesn't matter when you come right down to it.  Best is simply the demonstrable goal.   I'm still daunted by the 1% though.





Friday, June 5, 2015

Scrum Challenge - In a Pickle

Today's Scrum Challenge was a fun little game that I derived from the board game In a Pickle.  In the game you are given some cards with nouns on them and on the game board are four piles of similar cards.  You must play one of your cards, and justify it as necessary such that it either fits in the smallest item on the stack or that the entire stack fits in your item.  It's pretty fun and really stresses creativity and the ability to argue and sway people to your way of thinking.  As might be expected I excel at this game. 

Instructions

  1. Leader picks an object of some sort.  Should start fairly large. 
  2. Next player must list the objects that come before them and add another item that will fit in the smallest item in the list. 
    1. As necessary the player must justify to the team and the leader that their chosen item does indeed fit inside. 
  3. Each player has approximately 3 seconds to come up with the list and item or they are out. 
    1. Missed items in the listing will also kick you out. 
  4. The game continues, going around the team circle, the list growing longer and smaller, until there is only one person remaining.  That person wins. 

The Results

I'm including the results of our first game. 

  1. Empire State Building
  2. A whale.
  3. A large plastic bucket
  4. A small dragon
  5. A small shark
  6. A muffin
  7. A pencil.
  8. Lead in the pencil. 
  9. A bug in the lead. 
  10. An amoeba in the bug. 
  11. A cell in the amoeba (entire team missed that an amoeba is already single celled)
  12. Martin Short shrunk microscopically as in 'Inner Space' in the cell
    1. We quickly realized that it was Dennis Quaid shrunk in 'Inner Space' into Martin Short but it didn't matter much for the game. 
  13. A Bucky Ball inside Martin Short
  14. A neutrino inside the Bucky Ball. 


Reception
This game was hard for some people because thinking fast isn't always easy, especially when you're doing something so outside of the norm.  In general however it was a lot of fun with much laughter.  Even the people who went out took it well.  The largest challenge ended up being maintaining the list. 

What Went Right
Eventually everyone got the game and how it was played, but thinking fast was often challenging.  Keeping the list going might have been the most challenging and fun part of the game for the team.  If we hadn't done the list part, I don't think that there would have been as much involvement and laughter. 


What Went Wrong
Start with a good 3 entry example so people know how it goes before they have to start.  Let people participate as a team in the justification discussions.  As the leader, go with the majority opinion about appropriateness of any particular entry.   Being creative in coming up with your smaller item might be just difficult enough that it's difficult to pick strategic entries that benefit your future team members.  ie - pick something just a little bit smaller than the last item so there are valid, non-difficult choices open to your teammates. 


Lessons/Team Benefits
I think that this is a pretty good team building exercise.  I witnessed team members helping each other to remember things for the list.  Good, lively, laughter filled discussions about entries and whether they were valid were numerous.  From the team perspective this is a very good thing, it teaches your team that they can disagree on items, have some discussion around these items and things still end positively.  As always laughing and succeeding together always help build the team. 

I will definitely use this exercise again.  I believe it is a very good little team building exercise to use on a brand new team.  You don't need relationships or to know people well to still have a good spirited result.