When asked by Jonathan Bach if I was doing a lightning talk, I wimped out. I had never seen one done, had no idea what to talk about, and certainly had no clue how to do it in less than five minutes. I eventually said I would do one if time allowed for it. It turned out that time did not allow (everyone was hungry), so StarEast was not meant to be the stage for my first lightning talk.

It ended up being at Agile Coach Camp Canada 2010. Instead of 5 minutes, I had a mere 3 minutes (the topic for which will be covered in a different post). I learned some interesting things through that experience, some of which surprised me.

Learnings from Lightning Talks:

• Your topic could be anything from something that irks you, a proclamation that falls in line with (or against) the event theme, promoting something you are working on, seeking other people to collaborate with, or a story that relates to the event somehow.
• Talk about something you are passionate about. If you are not passionate about your topic, the audience will sense it, and not pay you much attention. While your talk is only 3-5 minutes, the audience not paying attention may not seem like a big deal, but consider whether anyone will remember your talk, and if you want them to.
• Keep it simple. Don’t try to cover the meaning of life, research results equivalent to that for the search for cancer, or a one hour presentation crammed into 5 minutes. Pick 2 or 3 key points that you feel are the most important for people to take away from your talk, and stick to supporting those.
• Make your point. Don’t wait until the last minute to make your point clear. Despite the limited amount of time you have, if your message isn’t interesting or clear, people will tune you out. If you want folks to listen, make your point early on.
• Limit slides to few, and very simple. With a 3-5 minute window that starts immediately after the previous speaker finished, you don’t have time to figure out computer problems, or provide enough context to ensure audience members understood every teeny detail. Better yet, just skip them.
• Your talk might change. While the overall message for my talk is what I delivered, how I communicated it was quite a bit different. I was going to talk about trying to fit square pegs in round holes, but instead talked about something else (again, I’ll get to that in another post).

Lightning talks were a phenomenal way to share ideas with other people, in a fast and inspiring way.

It was amazing to hear so many different ideas from so many different people in such a short amount of time. I quickly discovered who had similar interests as me, who had conflicting ideas that I wanted to explore further, and who may be interesting to pair up with on a project. I was inspired and provoked to look at my own ideas from a different perspective. It was also a lot of fun!

Try It!

I really enjoyed my first lightning talk experience, and look forward to doing another one again soon (likely at CAST 2010, in the first week of August). If you haven’t tried one yet, I highly recommend it!

You don’t need a conference or big event for lightning talks. Try setting up a weekly team meeting as a series of lightning talks one week, or even do a lunch and learn for lightning talks. You will be amazed by the idea’s you hear, and by the energy created. Lightning talks are a great way to mix up the daily flow, generate new ideas and solutions, and find other people to collaborate with.

To learn more about lightning talks and some tips to excel at them, read more at:

http://agilecoachcampcanada.com/about/lightning-talks/

http://www.perl.com/pub/a/2004/07/30/lightningtalk.html

Note: I am not an advocate for McDonald’s, own no stock in the company, and would never ever step foot in one again if I can help it, due to a variety of reasons not relevant to these postings or this particular weblog.

One of the first things I learned working in the fast food industry was how important customers were. Customers are necessary for keeping a company operating, but are also important in shaping many business operations and decision points. Here are three things that stuck with me after working the daily grind at McD’s:

Customers keep the business running, and your job intact.

Seems obvious, doesn’t it?

Sadly, it doesn’t seem to be in many companies. I bet you can quickly think of at least three bad customer service experiences you have had in the last three months. Sub-standard customer service, interactions, and expectations have become common place in today’s society.

The good news is that companies who make customers feel valued, listen to them, and actually improve their business based on customer suggestions are further ahead of the competition. Customers return when they have had great experiences.

While working at McDonald’s I focused on ensuring customers had a great experience. It all started with the first friendly and happy greeting, through to listening carefully to their requests, filling the request quickly and accurately, and finishing with a friendly good-bye. If anything happened to go wrong with an order, I quickly stepped in to compensate before they became frustrated and upset.

Customers also keep the business running and our jobs intact in the software industry.

Whether you are a programmer, a tester, a project manager, in operations, or in any other role, we need customers so we have a business. The customer may be an actual end-user of a product or service, another company who is purchasing a product or service for delivery to another customer, or even an internal user of the software.

Regardless of who they are, it is our job to provide a positive experience for that customer. That means:

• Understanding what problem they need solved
• Learning what they need to be happy with the product or service
• Determining how they will actually use it, and
• Ensuring every interaction is focused on the customers’ satisfaction and happiness.

Customers drive future products, if you listen to them.

Every customer is going to have some sort of feedback about the product or service they obtained. It may be positive in identifying how well it works for them, recommendations for improvements to improve it’s usefulness for them, or even complaints about how it doesn’t satisfy their need at all.

Running a business comes down to understanding what customers need and why they will buy something. If you don’t provide something they need and will purchase, you’ll quickly be out of business. This makes sense, but how often do you take customer feedback into account?

Context: Restaurants located in Southwestern Ontario, Canada.

In the early 90′s there were several products that McDonald’s offered that I really liked. Salads and pizza. For whatever reason, neither product sold well enough to keep them on the menu. Corporate listened to the customer feedback (which was represented in sales numbers, and in surveys and feedback forms) and removed both of them from the menu. While I was disappointed, customers were happy when new burger selections appeared on the menu to replace them.

Flash forward to early years in the new millennium, and you may remember that salads made a comeback and were added back to the menu as customers became more health conscious in their dietary habits. Additionally, as consumers became more environmentally conscious, most of the styrofoam packaging was done away with and replaced with paper and cardboard products.

Customers should also drive product evolution and new product creation in the software industry.

I have worked in organizations where someone internal to the company came up with ‘the next big thing’, developed it, and it flopped. Why? Because customers didn’t need it, want it, or it didn’t satisfy all their needs appropriately.

Learning customer needs and wants is critical for developing successful products.

• Product Owners/Managers need this information to devise user stories/requirements that will actually satisfy customers and make profits.
• Programmers need this information to ensure they program a solution that satisfies customer requests, wants, and needs.
• Testers need this information to confirm that what is developed not only fulfills a need and desire, but is actually usable for the customer in the way they will use it, continues to evolve per customer feedback, and satisfies many non-spoken product/service requirements.

This requires time to research, learn, and understand customer desires.

Customers evolve company image and business direction.

Most companies are in business to make money. To make money, businesses need customers. To get customers, they need to know how to attract their target market(s). Understanding the desired customer base, their lifestyles, and their interests is paramount for promoting an image and devising a marketing strategy that attracts, and keeps, the people wanted as customers.

Context: Restaurants located in Southwestern Ontario, Canada.

Do you remember the marketing strategy that McDonald’s used in the 80’s and early 90’s? They targeted most of their efforts at children. If children desperately wanted to go to their restaurant, parents would take them. From now-classic characters such as Ronald McDonald, Grimace, and the Fry Guys, through to the bright and bubbly in-store decor and family-sized booths, the company image was all about the kids. Some stores even had train cabooses that were used to host birthday parties, much to the delight of many children.

In the mid-to-late 90’s, McDonald’s changed their target to be less child-focused and more adult and family-focused. In-store decor evolved to be more subdued to attract a new customer base, Children’s Play Places were added so parents could have a break from their kids while knowing they were safe and having fun while in the restaurant, the Monopoly game was introduced to collect pieces and win prizes, and the infamous characters were fading away. McDonald’s was growing up.

From there McDonald’s further evolved to focus predominantly on the adult and teenage market. The company image and direction shifted to obtain customers outside of the established children-and-family market. They became more trendy, hip, and grown-up by introducing the “I’m Lovin’ It” commercials, advertisements and commercials focused on the working professional, and updated decor reminiscent of upscale cafe’s. McDonald’s touted a cool and adult-friendly image.

Consider whether customers influence the image and business operations of your organization.

• Does your company evolve its image as the target customer base evolves?
• Do marketing strategies change to acquire new target markets?
• Does the company consider customer lifestyles and interests into how it promotes itself?

Customers aren’t just the people who make a purchase for an end product or service, but are also internal to a company.

• Does your internal organization modify and adapt it’s image as other organizations in the company evolve and change?
• Do you know how to appeal to them so that working relationships remain strong over time?
• Does your organization evolve as your internal customers evolve?

Let’s go one step further. 

Suppose you have an external customer who likes to be heavily involved in defining a project, makes many changes, and likes to have flexibility in what the final end-product is.

• Does your organization evolve to use more agile practices that can work with this customer more effectively?
• Or does it stick with heavy-documentation, everything-is-planned-upfront, and nothing-can-change approaches? Guess how well that customer relationship will work out.

This isn’t just about company image and branding.

It is also about the processes and methodologies you use to appeal to, work with, and satisfy the customer. That extends from sales and marketing, product management, programming and testing organizations, operations, and customer support. If your organization isn’t adapting how it operates in order to keep up with the customer needs, you will soon be left in the dust.

What’s Next?

Take a moment and consider whether you, your organization, and your company really value your customers.

• Are customers welcomed, appreciated, and treated as a valuable part of the company/organization?
• Is customer feedback gathered and regularly used to adapt in product creation and evolution?
• Does the company image and business direction evolve according to the needs of the target market?
• Do methodologies and approaches adapt to work seamlessly with customer needs and methods of interaction?

Watch for the next part in the Food Service Lessons series, Lesson #2: Teamwork.

I remember a lot about the training I received when I started my job, from the old out-dated cheesy training video’s, to the shadowing I did with existing employees at the customer counter. I also remember smelling like grease all the time, no matter how much I showered. But I digress…

This was back in the early 90′s when the classic McDonald’s characters were still around, though waning in appearances. Back then, at least in the restaurant that I worked in, most employee’s worked hard to deliver value (a.k.a. food) to the customers. I sure did! I was getting paid to work, and work I did. We still had fun while on the job, but never at the expense of the customer experience.

I quickly moved up the ranks from the main in-store counter, to the food delivery window in drive-thru, to the high pressure first drive-thru window (I was the multi-tasking queen!), and to new-hire trainer. I even revised the outdated training program to be more relevant, effective, and context appropriate.

Note: I am not an advocate for McDonald’s, own no stock in the company, and would never ever step foot in one again if I can help it, due to a variety of reasons not relevant to these postings or this particular weblog.

That said, I had many experiences and learned a lot during the three or so years I worked there, many of which I carry with me in my work today. Believe it or not, many of these lessons are readily transferrable to other companies, and to software development (which includes testing).

What I had intended to be a single blog post has somehow taken a mind of it’s own and evolved into a number of blog posts into a full-fledged series. As this was not expected, I am curious to see how these are received.

I hope you will follow along with me! Subsequent posts in this series will be added as links from this entry as they are published.

First stop, Lesson #1: Customers Are Key

That Good Morning Cup, by Wespionage on Flickr

I once worked for a manager who did a great job of smiling and saying ‘Hello’ to his employees every morning. He then spent most of his time in meetings during the rest of the day… he was a manager after all, and managers are busy people.

When he was available for his employees, he enjoyed having discussions with his senior staff members to make decisions, decide on new directions, and figure out how to handle challenges.

Sounds like a great person to work for! … Right?

Perhaps so…

… But perhaps only if you paid attention to WHAT they were doing…

… and not HOW they were doing these things.

For instance, you might begin to notice that while your manager made the rounds saying ‘Hello’ every morning, their tone of voice and the words used changed depending on whom he was speaking to.  You might even begin to notice a trend amongst your fellow colleagues in those differences (but what does it all mean?!).

Now let’s say you were one of the fortunate few to be a senior staff member to this manager.  Wouldn’t that be cool?!  To be on the inside track, working closely with your manager to set the direction of your team / department, and getting opportunities to take on more responsibilities.

That sounds like fun to me!

The opportunity would become less fun as you begin to notice that your ideas are rarely considered or used for making decisions or improving the team.   Now you are beginning to wonder what is going on… your ideas and perspectives have been highly regarded by others in the organization.

So what gives?  Why isn’t your manager respecting your ideas or supporting you?  Is this happening to everybody?

Upon further observation, you find that this manager does in fact appear to take ideas from a couple of your peers.  But wait a minute, those peers are just reframing something that your manager said!  They are repackaging his comments to simply agree with what he wants to have happen.

Your manager doesn’t want new ideas, or someone challenging his (obviously perfect) ideas.

Your manager wants ‘Yes’ Men!

People who will agree with what he says and not challenge his ideas.

Aha!  That explains why your ideas are rarely considered or used – you don’t blindly agree to whatever is thrown on the table because a particular somebody said it.

Thinking back to those morning greetings, you realize that the ‘Yes’ Men on the team get meaningful interactions with your manager in the morning… and the people who aren’t?  They are getting a syrupy-sweet-so-you-can’t-actually-complain-about-me-fake greeting that lasts all of one second.

Moreover, you realize that your manager thrives on a dictatorship.  He is happy when he tells people what to do, and they do it.  He supports the senior staff who continue that behaviour with other team members.    So, opportunities on the team for growth and advancement are only given to those ‘Yes’ Men.

Not so nice anymore, is it?

This type of person does exist!

I did in fact work for someone like this after a good manager left.  I ended up leaving the team when I pieced together what was going on.  To say the least, it was a toxic environment, and I stayed in it much too long.

I learned a lot from that experience though, such as:

• Recognizing when I am working with someone like this
• Understanding myself and my own limits better
• How to view painful experiences as valuable learning opportunities
• When to try to work past differences with other people, and when to move on
• How NOT to behave if I wanted to be a good (or even great) manager

On the Flip Side

I did have a manager who did all the things I described in the first two paragraphs who was very sincere in their discussions and greetings, who truly valued their employee’s input, collaborated often to make decisions and generate ideas, and empowered their team to be responsible, creative, hard-working, and have fun.   Paying attention to HOW she behaved, not just WHAT she did, made this obvious.

I have even been this positive manager myself over a number of years in managing teams… but more on that in another entry.

Now, I would like to hear from you!

Have you worked with or for someone who is a dictator-type who thrives on working with ‘Yes’ Men?  What has your experience been like?  Were you able to find a way to work with them, or to deter their behaviours?

Please share your stories!

Bob had a -2 prescription.

“That’s nothing!”, I said.  ”I have -5 and -6!”.

A little jaw-dropping ensued, with comments around how seriously compressed my lenses were.  And yes, that combined with a bad astigmatism means my glasses cost a small fortune.

Needless to say, I was surprised when Mark piped in with “My prescription is -10!”. He wears contacts though, which cost half what I have to pay.  Horrible eyesight, but somehow easier on the wallet.

We quickly start to share experiences with optometrists, and then what can we see without our glasses or contacts on.  There were a number of comparison points to which we all had different results, such as:

• How far away can you ready something like font 36 text?
• How close do you hold a book to read it?
• How abstract a painting would you create without wearing glasses/contacts?
• How long does it take for your eyes to focus on something together?

The answers and differences aren’t particularly important here.  They did lead to some information though:  Our perspectives, as a result of our eyesight, were different.   Well, we already knew that our perspectives were different, so this wasn’t earth shattering by any means. It was an interesting reframing and reminder though.

Having had a good connecting conversation over similarities and differences, we move to get back to work. Then Mark commented, “I used to tell my optometrist that if I look through only my left eye vs. only my right eye, I see a different colour cast over objects.  He said that wasn’t possible.  No one has that.”

I whip my head around, and exclaim “No way!  Me too!”.

It turns out he has been thinking he’s a weirdo in some way, as per the optometrist his experience with the difference in colour-cast is something that isn’t possible.  He feels much better that there is someone else who experiences the same thing.

As for me, I thought all these years that this was normal, so I never brought it up with anyone before. Now I wonder why I didn’t.

As we are both experienced software testers, this is a bit amusing to us.  I was able to derive a few important reminders for things to do (and not to do) as software testers based on this conversation.

Learning #1:  If you know something is true, don’t let anyone convince you it isn’t.  Depending on the situation, find ways to convince them, or let it go (here is a great discussion point on when to do which).

• Mark was told that something he saw was not possible.
• He knew it was not true, but thought maybe it was just him.
• After a little insistence, he didn’t do much more with it.

Software testers experience this a lot!  How many times have you seen an unusual software defect that no one else can reproduce or see?  And then you were told that you didn’t really see it, you must have imagined it!  Knowing that you really did see that defect, what do you do?!

a)  Just leave it alone – you don’t want to upset anyone.  Maybe they were right.

b) Agree to disagree, but vow that you will do further investigation to prove that the defect is real.

c) Discuss the defect with the developer, show them the information you have to support your claim, and agree that you will work together to nail this issue down and get it resolved.  Getting to this point means that the developer trusts you – this is a very good thing!

I hope you pick option c in most situations.  It is important as testers that we are able to gain developers’ trust so they take the defects we report as valid issues, and work together to nail down those elusive ones.  You are a team after all!

Learning #2: Never assume that what you see is seen by everyone else – you may have experienced something unusual that is important.

• I assumed that something I saw was expected, even though I thought it was odd.
• I assumed that most everyone saw the same thing.
• So, I never told anyone about what I saw.

a) It doesn’t seem worth reporting on – so don’t!  Reasons:  It must already be logged, it must be a known issue as it’s so obvious, my expectations are incorrect so it must not be an issue, nobody ever fixes the bugs I report anyway, and so on,…

b) Discuss what you saw with a team member or developer to confirm whether it is a bug or not.

c) Report the bug straight away, every time!

In this case, option b is the better choice in most situations.  Checking with someone who may have more information than you about the feature, or building consensus with others as to whether something is a bug are quite valuable mechanisms for making this decision.  Work as a team to save time and effort on bug processes!

Learning #3:  Two or more people that seem to have experienced the same thing, didn’t.  Every experience is unique, and each person has different information to share about it.

• Mark sees different colour-casts looking through each eye separately.
• I see different colour-casts looking through each eye separately.
• We must see the same thing!

a) Compare and contrast your experiences, and see how they line up… are all characteristics for the experience in the ‘same’ column, or are there differences?

b) Reproduce the issue on the software together, at the same time, on the same system.  In other words, paired testing!

c) Assume that the experience was the same end-to-end, and report the issue jointly.

In my experience, I would suggest option b.  It is important to try to reproduce the issue together to ensure the same steps were taken, with the same inputs, which resulted in the same outputs, and watching the same screen/hardware, at the same time.  The only caveat is that even by doing this, you still won’t have the same experience!  Everyone’s brains work differently and will notice different things (which is one of the reasons why paired testing can be valuable).  It is still a valuable approach regardless.

…

Now here is your chance to think up other alternatives for the learnings above – I know they are out there!  You do see things differently than I, after all.  :)  Another good thought-exercise is what other learnings could come from the conversation noted above?  In any situation, a multitude of learnings can be derived for every person exposed to it.  I could think of a few more off the top of my head, but I won’t.  Take this as an opportunity to see what other ways you could view the experiences.  I would love to hear what you come up with!