CAST 2017 - Recap and Content

Quick post, mostly to make the content available. 

Thoughts:

• Submitting more than one topic so that at least one will get picked up - can backfire and both might picked up. 
• It was fine.  The biggest issue was being responsible two conference nights in a row because I was speaking the next day.  (three if you count getting up at 6 for my flight the third day)
  
• Going to conference away from your hometown is better.  Being in the hotel meant that I didn't run home to do family things and instead met people and talked and built some relationships. This was more lacking in Vancouver last year.
  
• The first talk, Augmenting the Agile Team, if there was a talk that had me nervous, was this one.  I knew the material and certainly understood it but the other talk was one I was more connected to, more passionate about and really just knew what I wanted to say and in what order I wanted to say it.  I could have done my 40 minutes without slides.  
• Turned out fine.  There were a couple of hiccups (partly due to interruptions) but I was back on track pretty fast and someone told me they didn't even notice.  My flow and energy were good, the message was pretty clear I think.  Question period was full, complete and had interesting questions.  The questions indicated that there was some real value for people.
• Got the best feedback I've ever had for a talk.  My talk came after a pretty good keynote that I found very mentally invigorating and thought provoking.  But a person I respect in the community came up to me afterwards and said, "You know, I got more out of your single talk than I had hope of getting out of the entire conference."  So to get that after a keynote I enjoyed was pretty amazing.  Better yet, if that's the start of her conference, think about how much better it would be able to get?
• There was definitely some positive reception to the core point that doing Agile doesn't mean following a prescribed path.  That it is OK to find something that will work for you as long as you're doing it intelligently.
  
• The second talk, middle of the second conference day, Technical Nomads was amazing.  Theoretically I left Testing Games early to do a quick last minute prep on this one the night before but got caught up talking to my family and didn't do any last minute review/prep.  
• Turned out great, for me at least.  I had great energy, great feedback.  Was able to move with the energy of the crowd.  Came up with some jokes while speaking that got laughs (and not the nervous awkward kind).  I came out of this talk with a pretty solid buzz. 
• Questions were intelligent and showed that the talk had value for some people. 
• Feedback was a little less thoughtful but still pretty good.  One person said it was "Fan-f***ing-nomenal!!!"  A new phrase for me, but definitely not a bad one. 
• I had been a little more worried about reception of this one.  It had been turned down by a few other conferences before this point while the other one had gotten better attention.  ie - it's a little less mainstream in it's appeal.  But I think that the content is actually pretty near and dear to people's hearts, whether a manager or a tester and people liked knowing that it was being thought about out there.  There were definitely people toying with doing some of the concepts at their own organizations already.
  
• Most of the content I chose to go to was interesting, vibrant and useful.  I really only had one dud talk.  Definitely wish I could have gone to more of them but I'm really happy with the ones I went to.
  
• The Gaylord Opryland Resort is a palatial megaplex.  Four (maybe more) separate fully sized conference areas.  An indoor jungle, well, two separate ones.  An indoor river with boat rides.  17 restaurants.  A starbucks.  A gellato and a separate frozen yogurt place.  It was 2000 steps from my room to the front desk, that's close to 2 km's.   But it was gorgeous.   Very high service, very friendly.
  
• Conference Food - the breakfasts were passable but I was happy with lunches and the reception.  The restaurants in Gaylord were ok.  I had a great burger at Fuse but PaulH had the worst nachos known to peoplekind.  
  
• Tester Games - This was unexpectedly awesome.  I mean i already liked board games quite a bit but playing board games with new people you've just met but kind of all share the tester brain is beyond cool.  It really helped to make some connections to people that you couldn't really do in the corridors.  So awesome that we even did this rogue, stealing into a random conference room one night instead of the beer-crawl.
  
• CAST is really a conference apart.  It really is about testers from all over the world coming together to talk about their passion.  (that's testing, if that wasn't clear)

Ok, my quick thoughts stopped being quick about 500 words ago.  Below are links to my slide decks.  Happy to continue the conversation about these in the comments.  Or on twitter or wherever. 

Augmenting the Agile Team - A Testing Success Story 

Technical Nomads - Stemming the Migration of Senior Talent

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.

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

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. 

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. 

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?

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.

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. 

A shower moment of clarity, about, well, clarity.

I get a lot of ideas in the shower.  I won't really call them epiphanies, most of them aren't really worth much but it is good to stay amused wherever you are. The best I can generally hope for is a little clarity.  Today's idea gave me some clarity around clarity in communication.   How you say things can be every bit as important as what you say. Today's shower thought, I think, is worth considering and maybe even a little discussion. 

Let's start with a little story about my shower.  We have a pretty standard bathtub shower with a shower curtain and a curtain liner.  The liner is waterproof and functional and the curtain is pretty and not so very functional.  About a month ago or so it was decided that the  curtain liner was getting dirty and needed to be cleaned or replaced.  After more complications than need to be discussed, we cleaned the curtain liner and I put it back up.  

Let's fast forward to this week.  I've been noticing that the ends of the curtain liner have been curling back from the wall a little, not producing as effective a water seal as I would like.  I've been fiddling with them a bit to little success and today I found myself wondering if maybe it's because the liner used to be reversed.  I don't know that I put it up in the opposite direction to the way it spent the first 15 months of its installed life but looking at it in the shower, I couldn't see any particular reason it should go one way versus the other.  

Knowing that my wife bought and installed the curtain and liner originally I figured that asking her if she knew if there was a 'right' and 'wrong' way to have it up might shed some light.  As I started to holler out a question from my shower I stopped myself.  I should have stopped myself regardless because you can yell out questions from the shower all you want but you can almost never hear and understand the response but this time I stopped myself for another reason.  

Here's the question I was going to yell out, "Hey sweetie, is this shower curtain liner reversible?"  A pretty innocuous question all-in-all you might think but in reflecting on the question I realized that there lies within this statement an onus of assumption that my wife is supposed to have this knowledge.  I grant you that she could simply say, 'I don't know,' without any real problem and not think anything of it.  But, if moods aren't as good at that particular moment as they might be, this tone, or onus of assumption, might feel a little presumptive and accusatory.  ie, if she doesn't have this knowledge she might slip into defensive mode.  Defensive mode can all too quickly escalate into some sort of fight.  Suddenly an unimportant question might put us on the outs.  If I had, with pretty much exactly the same amount of energy and thought input asked this question instead, "Hey sweetie, do you think this shower curtain is reversible?" that onus simply wouldn't exist in the same way.  It's obvious in the second form of the query that I know that I'm simply asking for an opinion. 

A little later, when out of the shower, I asked my wife the question, the second way.  Turns out she doesn't know.  Then we talked about the different possible forms of the question and she readily agreed that there is an implied onus in the first form.  Both of us also agreed that in a committed and successful relationship there is already tacit agreement to give a person the benefit of the doubt in most situations that the partner is coming from a place of caring and understanding and that they expect the same in return.  So the conversation ending up being defensive is less likely and even if it does, we're more likely going to come to an amicable conclusion. 

Turn this around though to the relationships you have in the workplace.  There is no particular need for any one person to take the things you say or ask in their most generous interpretation.  (I recommend that you live your life coming from that viewpoint but I do find this to be the rare and wise individual that is capable of this)  Indeed it is more likely, in my experience, that one in three people is more than capable of reading any statement in a way that will leave them negatively impacted. 

Yesterday I was talking with one of my guys.  His sprint team is having some issues, mid sprint, and it looks like they might not accomplish their goals.  In bringing up the fact that there might be some challenge in reaching their goals for demo day there was some negative blow-back.   If you know that you're a person who is more responsible at that particular point for success in the sprint, you're more likely to become defensive when it comes up as a point of discussion.  Again, this is human nature, it takes a wise individual to not jump to the defensive stance.  In this type of situation the words that you use to bring up the topic are incredibly important.  There are defusing ways to tackle the subject that help everyone staying in the productive 'how will we fix this' mind-set rather than the defensive, 'this isn't my fault, leave me alone' mind-set. 

By example, you could say the following, "If you don't get me this feature until next week we won't be able to finish it in time for demo."  This phrasing is particularly fraught with challenge because it also provides the semi-justifiable out that it was delivered to someone else before end of sprint therefore the blame belongs to the person who got it last and didn't finish it.   If, however, you said it like this, "I see that things aren't moving as quickly as we'd anticipated, what can I do to help move things along better."  Both phrases accomplish the necessary task of starting a dialogue about getting things done but the second will start in a more productive space. 

To come back around to my shower and the title of this post, I had this moment of clarity about how being clear in what you're saying isn't just about using words that mean the right things, or even in just in being succinct in what you say.  If you want to be an effective communicator you need to understand your audience, their context and the way that they're going to listen to what you say.  The way that you say it can combine with the way they're going to hear it to produce an effect that you never intended. 

Show Up Every Day

I was just reading this article by James Altucher.  The gist of the article is that you need to show up, at whatever endeavor you're undertaking every, day.  Each and every day.  I also like that it doesn't say that you need to show up ALL day. 

It started me thinking that there are a number of ways in my life where this advice holds true.  

Habits

When you're working on a project, be it for work or at home and you don't have a set deadline and you're being self-motivated you should put extra effort into showing up every day.  By making sure that you accomplish something real towards your goal each and every day you build a habit towards working on that project.  Habits that you build in that way will build their own momentum and happen on days when you don't have the motivation to make them happen.  Not to mention, when you continuously work on something every day progress happens and before you know it, you've achieved your goal.

Motivation

I find that motivation is very much a momentum kind of thing.  If you have momentum forward you don't have to think about your motivations so much.  You just move forward with the momentum and accomplish things.  As you accomplish things you are motivated by your success and produce even more forward momentum.  This is why the end of projects, especially very long all-consuming ones can be dangerous.  Suddenly your momentum is halted because you don't have a path forward in the same direction that you have been following all along.  This is why it's good to run with multiple projects, some in the design stage, some in the kernel of an idea stage and some in the mainstream.  As soon as you finish one you can refocus on another. 

Some of my least motivated days are when your large project ends, all the loose ends are tied up and you set yourself to just tackle the things that were left around undone while you were on project.  Those things were never going to be very satisfying to undertake or you would have made the time to do them.  I find myself doing parts of each task before I'm distracted by another more interesting task.  By having another project to move towards with a goal, I can spend 10% of my day on that and the rest doing the clean-up and still feel pretty motivated.

Staycations

I discovered a number of years ago that staycations can be pretty awesome but that they had an inherent risk.  If you don't make a plan for a staycation you run the risk of diddling away your time and then at the end of it when you're back at work you'll find yourself thinking, 'I didn't do anything.  The time was just wasted.'  This seems counter-intuitive because the very act of staying home and doing nothing was probably what you wanted to do but without any defining events within that time everything will have just sort of blended together into one giant blob of dis-accomplishment.  It will feel good during the staycation but you won't have as much durable satisfaction afterwards.  (or you might, we're all different people). 

I came up with a strategy that deals with this though.  Each day of your staycation you plan one event.  For me it often meant leaving the apartment to go to a movie.  The rest of the same day could have me lying on my apt floor staring at the ceiling, the point was simply to have the one planned event each day.  The event could even be within my home, such as painting a wall.  As long as it was a unique event that wouldn't normally exist in a lazy stay-at-home day.  The event could even be something extra lazy like sleeping in the hammock all day but then you'd have to put just a little bit of extra pageantry around it to make it special. 

It may all sound a little strange but I found it really worked for me.  By spending two 'productive' hours in a day the whole day was remembered as bring successful.  I could have spent the rest of the time sitting on the couch watching reality TV (not that i did, ew) and the day would still feel later like it was a worthwhile day. 

Of course there's those people with boundless energy that take a staycation to accomplish things around the home.  Well, if you're going to do that, you'd best make sure that there are tangible re-livable results because that's the only way you're retain the sense of time well spent after the fact. 

Show Up Every Day

By showing up every day you build habits that maintain motivation, giving you momentum so that the next day you can achieve the same thing, only perhaps even better.  It's self-fulfilling and it's moderately eternal.  You'll feel better about yourself and what you're accomplishing which will give you the verve to continue doing so.   It's a very simple formula that just requires you to show up, every day.

Build Your Own Terminology - Knowhole

We've got a history of creating new terminology when we need it in my team.  Sometimes this goes well, sometimes not so much.  One of the most successful instances of this is the term Resolution Testing, referring, of course, to the validation of the resolution to a bug that has been fixed.  (or our vernacular term for same Babooning)

More recently we've come up with another term.  

The term is Knowhole.

It is defined as an odd hole in a person’s knowledge that would be considered in general to be common knowledge.

An example would be not knowing that unicorns had horns.

It evolved from the term Noah hole, for a co-op on my team who didn’t know that unicorns had horns.

The usage has expanded.  Here are some practical usages that I’ve heard:

You’ve never heard of the Ukraine?  That’s a pretty big knowhole.

Shove this in your knowhole.

Take this book and stick it in your knowhole. 

English is a beautiful language, let's help it blossom and grow. 

Rules and Process, Process and Rules

Recently my old boss transitioned out and my new boss transitioned in.  The new boss, is for the most part a pretty good guy.  Head firmly on his shoulders with brain intact.  So far I've enjoyed working with him and expect that trend to continue. 

He has brought with him a skill/habit that I haven't encountered very often.  He's been consulting at the VP Eng level for a while now and as such, with his multiple engagements he's had to build up a skill set around figuring people out quickly.  He is well versed in a number of frameworks of personality assessment and uses these as tools of his own for understanding.   As far as I can tell, so far, he allows these to provide a snap profile for people that he then uses judgement and experience to evolve into a more accurate and true picture.  

I do know that there are people out there that loathe this type of approach, of pigeon holing people instead of treating people as individuals.  Loath might, in fact, be too light of a word for it, I've watched people start foaming at the gums with glowing red eyes over the entire notion. I, however, think that it's a moderately reasonable approach to your interactions as long as you're fairly open to allowing ongoing evidence to alter your opinions.  I've been pretty happy with this aspect of the new boss as well.

By way of an example - I found out that this boss had tagged me as a person who pretty closely tracks to rules and processes.  This highlighted itself in our meetings as we've started transitioning the team to agile in comments that indicated he believed that I would be the person being a stickler to following process.  And indeed in some ways I am, not so much in that I insist that we follow a process but rather in that we acknowledge that there is a process that has been set in place for a particular situation before we proceed down a different pass.  But within the objection itself, he believed that I was trying to keep us on the path.  After some discussions about these facts he no longer believes that I am so stuck on the process trail. 

 I am a firm believer in the value of having process for anything that you do that is repeatable.  Whether it's in your personal life or in your business world.  Process isn't necessary defined, for me, as 'the best way to do something.'  Process for me can rather be defined as 'a way of doing something such that you are getting a reasonably high return value from your actions, each and every time that you do it.  It must also be a way that is effectively follow-able by each team member without being so complicated as to be a barrier for compliance."  It's not necessarily the best way, every process can be improved. It's more important to find a reasonable process and implement it rather than wait for the best way.  It is essential to make sure that your process isn't super complicated as well because if it's too hard, people simply won't do it, or at least won't do it right.  There's nothing saying that you can't improve process after you've declared one, they should be considered to be living entities, ready to evolve...with the right process being followed. 

Process is important because it's the thing that helps you perform something correctly when you're not really paying attention, or you're a little sleepy that day, or you don't perform a task on a regular basis, or you're just new and don't understand things completely.  Process is the thing that tracks the little things when you don't want to so that the whole is accomplished with a greater level of success.  Process also helps define success so you know when you're done.  

So OK, now that I've made it seem like my new boss was right and that I'm a rules Nazi there's an extension to what I've said above.  It's only when you understand a process that you can make a decision to remove yourself from that process, go another way and still hope for success.  More often than not when we're doing something that doesn't quite match up with process I find myself asking the question, 'This is what the process says we should be doing, if that's the case, should we be doing what we ARE doing?'  If you have a reasonably intelligent answer and can field my follow up questions that start with, 'have you considered...' (questions that flow from the actual process themselves) then I'll be your biggest backer in going off the reservation. 

If everyone thought the same, worked the same, made decisions the same and went into everything fully aware of all the factors in play then we wouldn't need process because every time you'd still get the same result.  So that's what process does, it helps you to success when people aren't aware of all the factors or aren't thinking clearly.  By asking the questions of whether you should be breaking the process you're ensuring that you are thinking of the important factors and it's OK to move off process.  

Maybe. 
You might still be dooming yourself. 

temporary difficulties

My apologies. It would appear that my site stopped working late last week.  Something to do with the auto-forwarding to qaisdoes.  After attempting to self troubleshoot with no success I put in a trouble ticket.  Today it miraculously started...well, behaving differently which allowed my self-troubleshooting to be more successful.  

We're back up now.  I apologize for the absence. 
Additionally, I have an actual entry near post-able - it will be up soon. 

Scrum Challenge - Little White Lies II

This scrum challenge is pretty closely based upon a team building challenge I found off the internet in a number of places.  Sometimes it is called Two Truths and a Lie.  In fact this was the second time I ran this challenge - the first time was last year.

The challenge is pretty simple. Each person 

Instructions

During Scrum

1. Each person is handed a piece of paper.  (they've been told to bring pens)
2. Each person has 2 minutes to write down three statements about themselves and their name on a piece of paper.
1. the statements can be things like their shoe size, their birth place etc.
2. one of the statements will be a lie.
3. that statement should be marked as a lie.
3. The judge reads out each person's statements anonymously, randomizing statement order for each person.
1. going around the table each person votes on who wrote the three statements.
1. the judge records the people that get it write, anonymously.
2. a person voting for their own entry gets that point.
2. going around the table again, each person votes on which statement is a lie.
1. the judge records tallies against each statement.
2. a person voting on their own lie doesn't get counted.
4. At the end the judge tallies up the scores.
1. one point for each person's vote for the right person.  ie if Joe has 3 people pick his entry, that's 3 points for joe.
2. one point for each person's vote for the right lie.  ie if Joe has 3 people choose the statement that was actually a lie that's 3 points for Joe,
5. Winner is the entry with the fewest points.

The Results

I'm adding in the results from my team, although i am changing the names to protect the innocent from payback from the less innocent.  These results aren't really going to be that interesting to you I don't think, however they are indicative of the types of things you're going to see in a challenge like this.  

Author	​​​Statements (red is lie)
​T1	1.     ​I've done ballet 2.     I play the flute. 3.     I'm a black belt.
T2​	1.     ​I am a good swimmer. 2.     I am a good dancer. 3.     I am a good snowboarder.
T3	1.     Star Wars is my favourite movie. 2.     I've been to Belgium. 3.     My legs have been shredded by kittens.
T4	I play the piano. I play the saxaphone. I play the trumpet.
T5​	1.     I was born in German. 2.     I lived in Germany until i was 2 years old. 3.     I have been married twice.
​T6	1.     I don't wactch TV. 2.     I don't drive 3.     I have 4 cousins
T7​	1.     ​I lived in Alberta when i was younger. 2.     I think some hip hop bands are really good. 3.     I used to compete in skateboard competitions..
​T8	1.     ​I was born in Hong Kong 43 years ago with a bad weather morning. 2.     I had my first car which was a Toyota. 3.     I joined DPT 5 years and 8 months ago.

Reception

Maybe it's the challenge of writing down things that other members of the team aren't going to know or being given permission to write down a lie but this game has gone over quite well both times that we've played it.  People get into writing down their statements and seem to enjoy the process. 

What Went Right

The right level of statements came out right.  People were able to tell lies sometimes and not other times.  People learned things about each other.  It seems to have all worked rather well. 

What Went Wrong

We ran out of time on this one so the review of the statements was a little rushed.  A little more haste in the early parts would make things work better. 

Lessons/Team Benefits

There's always a benefit from a team strengthening their bonds and forming stronger relationships. This challenge does that directly through passing information about people back and forth.  It also provides good interaction as a team, solving problems, laughing at the situation and one-another and providing that bit of stress around being caught out in a lie that makes you a little more open in the situation.