JIRA Shenanigans - @mentions are better than Email

One feature that has drastically changed the way we use JIRA among a geographically distributed team is the @mention feature.  This allows one to specifically notify someone: "hey I think this is important you should read this."

We all hate the telephone game and accountability is pretty important.  This is enforced in a strong way from Alice in this Dilbert comic:

The thing is that there are a couple issues with E-Mail.  The main thing is that it only resides in the inbox/outbox of the recipients/sender, preventing any normal person from taking a look at the conversation later on.  You'll get the whole "oh there's a thread floating around I'll forward it to you" scenario.

Especially when an email is just between two people, you run the risk of some valuable communication being lost when both are not around for whatever reason that may occur.

Enter JIRA Comments.  Having the conversation there provides a couple things.  It's a public forum so people tend to be a bit nicer there.  It's query-able, as all Issue fields are, and they persist so long as nobody deleted the issue.

There's this nifty @mention feature that you can use to direct a comment at someone.  This provides a notification to someone (usually in the form of a an email) with the comment.  However, this adds the context of the JIRA issue and the rest of the conversation.  Some annoyances from this feature comes when you're in a thread with multiple people and you want to ensure that everyone gets a notification.  In this situation, Watch Feature can be used to then keep up with the conversation as well as other changes.

After I wrote up all that (and most of the next post) I stumbled upon this blog post by +Dan Radigan that concisely describes using @mentions and Watchers effectively.  In addition, it also has some nifty queries to help people find posts that they were mentioned in as well.  Definitely check it out.

This post is getting long and I want to talk about how @mentions only allow you to notify one person at a time.  Wouldn't it be nice to quickly and easily notify a bunch of people at once?  Well, as of this post, JIRA doesn't support that, but there's a pretty nice workaround.  I'll get to that next time.

KineticJS on Chromecast

Pretty lame looking video of my getting that Idlewild Boat Race Clone on Chromecast, but I thought that was cool.

Why Story Points are Cool

Sure.  Dilbert Comic.

So to carry on the conversation where some people are saying that estimates, in general, are a waste of time, I'd like to cover some situations where having Story Points are particularly useful.

Do we agree on the requirements?
You really shouldn't need an excuse to drag product/business end users, qa, and developers to have one last sanity check on some requirements.  Getting everyone to agree, at the very least, what the requirements ARE and taking the next step to cover some technical detail as to what the effort would be.  You definitely don't want "the expert" to do the estimation as this is a method of risk mitigation of "expert getting hit by bus."

Do I have enough ready-to-work Stories in the Backlog?

As a product owner, you need to know whether you have enough stories pokered and agreed upon by the team for the next sprint.  This is dependent on knowing your team's average velocity, whether people are going to work vacation days, etc.

Also, depending on your team's process, a Product Owner can ensure that the backlog consistently has a decent amount of low point stories that the team can incorporate into their own sprint.  This is for teams that have the rule that a developer can bring in a story after the sprint start only if they think they can complete the added story within the same sprint.

When are we done with Planning?
Pretty much exactly the same thing as the previous point.  More importantly, when can you end the planning meeting?

Where Story Points don't help:
One scenario where Story Points may just be superfluous, and that is when a team typically breaks a story down to the point where they are all essentially equivalent levels of effort.  This exercise is particularly useful for teams with extremely short sprint times.  This all depends on what your team wants to accomplish and how they want to accomplish things.  However, if just about all stories are broken down to 3 point stories, you are still running through the exercise of Pokering, but rather than asking the question "what's the level of effort for this story," you're asking "is this story a 3 or not?"

... but don't get too focused on those Points

It's really easy to latch onto some quantitative value and to start drawing conclusions.  People are going as far as to asking "why are we FAILING our COMMITMENT?!"  In the end, Story Points are just a tool to help us answer the following, but not used as the ONLY metric to answer:

• Are we meeting customer expectations?
• Is there any action we can take to improve?

This is really hard to drive home for a lot of people and you're likely going to have a couple "electrolyte" conversations but it is truly worth it.

... but what about our commitment?

Either way, I hope this will provide some ideas for Product Owners in particular in using Story Points to help manage not just their own day-to-day work, but also drive home that it's just a tool to aid in efficiency and identify potential areas for improvement.  We should never become slaves to our estimates.

Whatever Happened to Risk when We Went Agile?

There seems to be some sort of rallying cry that Story Points and, in general, estimates, should be gotten rid of entirely from any sort of software development process.  I think this is, generally, a very strong kneejerk reaction to some pains through the development and release process in terms of managing expectations.

Usually said pains come from someone managing expectations in the following manner:

• A Release is planned with a set number of User Stories define
• Said user stories are pokered 
• Project Manager compares the sum of the user stories against the team's velocity and converts that into sprints - let's say they determined that it sums up to about 4 sprints.
• Project Manager sets a release date approximately 4 sprints from now.
• Project Manager attempts to hold team accountable to the Release Date.  The word "commitment" seems be the word of choice, lately.

The most glaring issue with this situation is something that doesn't get mentioned a lot in the agile process: accounting for risks when managing expectations.

We've all probably seen various different risk charts that show likelihood vs. impact with mitigation plans associated with each.  These have all but disappeared.  Granted, I'm not saying that a team should get back to long drawn out risk powerpoints, but it's the team's responsibility to bring up these risks.  It's usually the project manager's responsibility to communicate these risks out.

I get the impression that a lot of agile teams have lost sight of actively tracking risk and reflecting it back to project stakeholders.  It's not like they've gone away because you're doing Scrum.  

Here's my unscientifically backed opinion on medium to long term estimates: shoot from the hip estimates in terms of resources and man-hours from an experienced manager, in conjunction with a development leader or two, is just as good as a thoroughly pokered out backlog.  You take a look at it from a high level, identify some risks, and based on what you know from the team, manage the expectations of the stakeholders.  

Some may argue that more vague stories with point values far exceeding your sprint threshold are just as good.  I actually don't have much direct experience in trying that, but it would also be something to think about.  When you get story points that are as high 100 points, to me that's pretty much the same as a shot from the hip.

The last thing you want, however, is to attempt to define all the lower level user stories at the beginning.  You will find yourself spending an arduous amount of time at once to try to estimate something months in advance and opening yourself to the challenges that impact Waterfall.

In the end, it all boils down to plain ole communication, including the appropriate people in the decision making process, and getting buy-in for the final decision.  At the very least, you didn't spend an ungodly amount of time holed up in a room trying to think of every single thing for the next couple of months.

So why poker at all? Well, there are a boat ton of uses where pokering, with Story Points in particular, is very useful.  This post is getting long so I'll talk about how they help smooth out the process from sprint to sprint in the next post.

JIRA Shenanigans - Attach Screenshot Feature

If there was a feature in JIRA that was both awesome and not-awesome at the same time is the Attach Screenshot feature.  For an organization whose culture, for some reason, has been imbued with pasting screenshots into word documents, and then attaching the word documents in ALL of their tools, the attach screenshot feature can be both a time-saver for both the one reporting the Issue and the one consuming it.

ಠ_ಠ

Of course, one can point you to JIRA Capture, which, I'll admit, is a super awesome tool for testing web applications and contains a slew of features to aid QA in recording their test sessions and providing visual aids to others of what they're observing.  

Convincing an organization to drop more money on a tool is very hard, so let's get back to why the Attach Screenshot feature can be a pain:

Chrome and 64-bit Java + other Java Shenanigans

Here's one of the issue documented with this Java Applet (oh right, it is a Java Applet).

So straight out of the box, if you like to use Chrome and if you only have 64-bit Java installed, the applet will not work.  If you're not the admin to do the solution I'm going to describe below, you're going to have to do some configuration.

JIRA has historically been a tool directed at more technically minded users, but this specific limitation is extremely tough to get some people to A) find a fix on their own and B) actually be able/willing to fix it. 

Additionally, you can easily get the question:

"Why should I work so hard to get a tool that we PAID for to work the way I want it to?!"

My answer to that is that most people don't realize other comparable tools cost way more without the customization capability, but nobody wants to hear that.  It then isn't surprising that this very same culture will lead people back to the word doc attachments (without even considering that they can attach saved images).  It is quite the endless cycle of violence.

I didn't pay for Linux so it's OK that I have to
spend hours to make it do what I want!

So is JIRA going to fix this?  Indeed they are!  As of this posting the issue is "In Progress" so I'm hoping it shows up in their next minor version.  

JIRA Issue: "Rewrite screenshot applet using not-java"

Fortunately, we don't have to wait for the next version of JIRA to get this feature.  Atlassian Labs has a plugin in the Marketplace that isn't dependent on any 3rd party installation.  

Better yet, if you have troubles in your organization with making upgrades to existing tools (aka you're not going to make an upgrade to JIRA even if this feature is availble), you can install this plugin on older versions of JIRA.

Ripped off the Marketplace page

Getting a feature that works right away for all users is the best way to get adoption and can aid in quashing that Broken Window affect that may be plaguing your cultural processes.  

While you're at it, definitely check out other features that Atlassian Labs has developed that may go into future versions.  Find the appropriate feature request in JIRA, watch it, and upvote it.  The more you use Atlassian's JIRA as a user, the more you can figure out how it can help your organization.

Random JIRA Shenanigans #1 - Development Panel

I've decided to start putting in random JIRA configuration notes in here that may be of use to some people: JIRA's 6.2 release has a pretty sweet feature called the Development Panel with a lot of great features if you're using Stash and other git tools.

Unfortunately, we're not using any of those tools.

 BUT, we are using Fisheye 3.3.1 and the big bonus with this feature is that it explicitly shows us the branches an issue is being worked on. Technically, because we're using Gitflow, it shoooould be one branch...

Either way there were a couple of finicky things that we had to do that wasn't explicit in the documentation to make existing integrations with Fisheye/Crucible continue to work as expected.

Initial Configuration

• Fully Trusted Applications Links between JIRA and Fisheye
• All Users in Fisheye are in JIRA (but not the other way around.)  Fisheye uses JIRA User Directory for Authentication

Final Configuration

• Edited Application Link between JIRA and Fisheye
• Disabled Trusted Application Link
• Enabled 2-Leg OAUTH
• Impersonation Enabled.

The first finickiness was that I didn't have Trusted Applications disabled in the Application Link.  This prevented the Development Panel to show up to begin with.  A quick hit on Atlassian Answers gave me an answer:

Atlassian Answers Question

The next thing, however, was a little odd.  I did not have Impersonation Enabled with 2-leg OAUTH.  In hindsight I don't even know why I didn't do it, but when people were attempting to close their code reviews in Crucible, they were seeing this guy:

Fisheye was having an issue getting specific data for an issue in JIRA.  Enabling impersonation did the trick to allow users to transition the appropriately linked issue if so desired.  Specifically, because Fisheye's user base is entirely based off of JIRA's user base, we didn't have any issue with Fisheye utilizing this feature when interacting with JIRA.

Idlewild Boat Race Clone

Sure. I'm going to say that Atwood's Law applies here.

Things We're Exposed to as Children that We Forget for Work

Oh Bert'n Ernie.  I'd like to think that I am Bert most of the time, but I'm sure I'm guilty of being Ernie when describing the rationale for requirements to others.

If you didn't catch Harrison Ford make a reference to this with Glenn Close you need to watch Air Force One NOW.  But seriously.  Expectations management is hard.  Scope creep is a bitch.

This was the best Telephone game video that I could find on Youtube.  It's surprising how often you see everyone in the room take little notes in their note pads to take off to their teams on what happened.  Heck, I've seen this happen when people enter things in a spreadsheet, and then someone else has their own spreadsheet, and they work together to make one AWESOME spreadsheet!

User Stories - Asking some Questions

If you're looking for me to spell out what specific elements a User Story should have, I'll just point you to test framework called Cucumber where you write "Cukes" to describe the behavior you're testing.  When thinking about how you're going to test something, the User Story becomes pretty apparent.

http://cukes.info/

But rather, when Business Analysts, Developers, Product Owners, whoever is writing user stories, there are a key questions to ask that can drive what your User Story should look like and more importantly, what supplemental information may aid in the development process.

Whose problem are you trying to solve or alleviate?

If this isn't the first question you're asking, you might as well go home.  Now.  You're home?  Step outside.  Walk a block.  Ok.  Go home.  Look at cukes again.  I'm not saying you should be using Cucumber for your test framework, but they have very good ideas.

How can someone validate this?

See the cukes.

Who's Going to Consume Your User Story?  Who participates in the release cycle?  Who are responsible for validating your implementation against the User Story?

To me, these are all the same question.  However, you may get different answers to these questions, depending on who you're asking.  This is something that's very specific to your project and organization.  However, all the people that may be identified as answers to these questions can benefit from reviewing the User Story.  Why is that useful?  How often do you find yourself having to demonstrate a feature to someone to explain to them what the feature is?  How often are THEY then demonstrating it to others to explain to them what the feature is?  Your organization can have a slew of handoffs where a clearly defined User Story can save time and reduce the Telephone Effect.  Here's an overloaded example:

Product Owner -> Developer -> QA -> Training/Documentation -> Support

In a conversation the other day, an IT manager that supports a huge bio-research organization mentioned that the largest challenge towards their adopting Scrum was that [non-developers] think that it's "just for developers."  Without diving any further into the specifics, I feel that this is due, in large part, to some organizations not disseminating User Stories out to non-developers.  In a more Waterfall environment, you may have a very extensive requirements and design document... that nobody reads.

One potential pitfall for a User Story when it's "just for developers" is when someone, in reality, is simply writing a technical task to be done.  With that, I simply point back to Cukes again.

Do you need buy-in for your User Story?

This heavily depends on your organizational culture and how much trust everyone puts into the Product Owner.  However, when seeking feedback, identifying potential gotchas, or simply being able to come up with a better design, answer the following as part of your supporting material can greatly provide food for thought.

• What's the current behavior?
• Why is it not optimal / desired at all?

When working towards buy-in for your User Story, it not only helps people feel more valued, but also increases the organization's trust in your being able to identify the overall direction of the product.

With that last sentence, if not to be more efficient, increase organizational cohesion, and increasing clarity in the process, just simply thinking about these questions when writing User Stories can make your life easier when people trust you more.

User Stories - How they're Useful

All too often, organizations spend a stupid amount of time talking about what information should go into User Stories and how their content should be structured.  They forget to ask the question, what do we want User Stories to do for us?

Typically, people see Users Stories as a tool to answer one question: "What do the developers need to code?"

In a TDD oriented environment and, surprisingly to a lesser extent, when there is a separate QA team, User Stories, people use User Stories to answer the next question: "What needs to be validated to accomplished our goal?"

One question that doesn't get asked, though is "How do we keep the Product Owner accountable for what we produce?"

"That's not what we talked about."

When demo happens, what's demoed may not match what the Product Owner may have in mind.  When this happens, the conversation can quickly devolve into a "well you said..." conversation where there is no record.  This both negatively impacts the team's relationship with the Product Owner and wastes valuable time.

Stories provide a snapshot of requirements at a given sprint.

With a recorded User Story, the team and Product Owner can review the Story, review what was discussed in the story (ideally relatively close to when work started), and move forward.

• What was ambiguous in the Story?
• What Questions did we not ask?  What did we not write down?
• How can we improve on our stories the next time?

By improving the story development process, a team can greatly reduce rework and avoid contentious conversations with the customer.

"Is this behavior by design or is it a bug?"

Far into the future into production support, the User Story can further aid in answering the super contentious question: "Is this behavior by design or is it a bug?"  This is a pretty overloaded question.

• When was this feature originally developed?  
• What was the expected behavior at this time?
• Does the observed software behavior meet this?
• Do current customer processes meet these?

The longer this question is discussed without any hard answers, the greater the negative impact it can have on the Team/Product Owner relationship.  This question also greatly impacts whether the solution will be an End User behavior change, a bug fix (typically paid for by the Team budget), or a new feature (typically paid for by the Customer's budget).

Without these scenarios in mind, User Story development can easily have a Fire and Forget mentality.  This can lead to a lot of avoidable costs and negative impacts on customer/team relationships.  Next time I'll talk about more questions people should think about when performing User Story Development.

Cost Beyond Code #2

Some quick feedback on my rant mainly wanted some examples of a costly situation that is a result of poorly managed requirements.  I'm going to use a lot of "probably's" and "likely's" so just bear with me :P

The Project

• Requirements are maintained in word docs on a shared drive (not Sharepoint) where the filenames are along the lines of "Release - June 2007" that nobody's opened in years.  Essentially, they're practically un-browseable and un-searchable in any decent amount of time.
• These requirements were never formally reviewed by anyone.  People would show those groups like QA and End User Trainers "how it should work" in a 1 hour meeting.
• Developers tend to "own" things where one feature set is entirely done by a single guy.  No recorded code reviews.

The Costly Situation

• Some piece of software has a feature that has been working in production for a couple years.
• An odd behavior comes up it is keeping an order from being Billable.  For arguments sake, it is a scenario that hasn't come up in an extremely long time and there's no documentation in the IT Ticketing system of how this was resolved the last time.
• The guy who coded it is no longer with the company.
• None of the "expert" users know how the software SHOULD react in the given scenario.

Cost #1: Operations

The earlier you have that money in the bank, the earlier you're making more money for you.  If this is visible to the customer, you run the risk of their simply cancelling and going with a competitor.

So let's say this IT ticket rises through the different levels of support and reaches you, the developer.

Question #1 - Have we ever encountered this scenario before?  What did we do last time?

• If you're pretty immature about your requirements maintenance, chances are you're pretty immature about your bug tracking too.  For me, this is a classic example of a Broken Window phenomenon in a software development project.

Question (set) #2 - Why is this happening? Is it a bug?  Did the requirements cover this when the feature was developed?

There's absolutely no reason for you to look up the requirements.  You're not going to try to wade through 10's or even hundreds of Word docs that were meticulously documented but whoever wrote them didn't really think about how to reference back to them.  If you're not a developer, the one thing left to do is at least dork around in the stage environment to reproduce the issue.

Cost #2: Support Investigation

Even if the issue is reproducible, without the requirements from when this feature was developed, you probably can't answer the question "is it a bug?"  "Why is this happening?"  Without the context of the requirements, reproducing the issue can be a significant challenge.

You're still going to need a developer to look into this.  However, it is extremely likely that in this scenario the first 2 questions aren't even asked so one could argue that this cost in labor isn't even accrued.  :P

OK DEVELOPER SAVES THE DAY.  Not Really.

Ok you're investigating the code to answer Question #2.  You're likely wading through code you're unfamiliar with.  At this point a lot of people will argue that this like ability of the investigator, coding conventions, and quality of code will impact how efficiently this investigation will be accomplished.

Question #3 - What is the context of this code?

Commit messages can help.  Code quality can help.  However you likely don't have any linkage from a commit message to the actual requirement.  That would come in handy, but like we said, that stuff isn't there for you.  So the differentiation between "this is by design" or "this is a bug" is close to impossible.  It's going to take you some time to figure out what's going on in the code, describe it to somebody, and hopefully have a solution on what the user should do to keep the Order moving forward.

Cost #3: Developer Support

What could have been answered from a requirements lookup has now extended to any other full-up bug investigation in reproducing an issue and passing it onto a developer.  You're going to have some back and forth between the developer and others in terms of trying to answer "why is this happening" question.

Question #4 - Is this by design?

You can't tell.  Chances are this will be dependent upon your opinion of the guy who wrote it.  Either way, it's going to be pretty hard to answer this question.  It will be up to some pointy haired person to decide that it is a bug that needs to be resolved right away in the code, that the business needs to update their procedures to be aware of this scenario, or that some behavior change is required to go through some other channels of funding.

Cost #4: Aftermath - Because you haven't come up with what the requirements were at the time the feature was implemented, you can't hold the business accountable for what discussed, reviewed, and implemented.  It is generally easier to get a customer to swallow the "this is by design" story if you have the documentation to back yourself up and simply update their processes.  

Some people will say that some email will be required to accomplish this but that's in lieu of a decent requirements tracking system.  Without this documentation, you're likely going to take up some time to discuss whether it's a bug (money from the IT Bucket) or a new feature that needs to be implemented (money from the Business Bucket).  

Either way, in order to move forward, the relationship between business and IT runs more smoothly if the conversation goes down the path of "ok now we know what the thought was when we implemented this, but we'd still like to submit a change request," vs. "we're going to just have to agree to disagree so what are we going to do about it?" 

There are a lot of pieces that need to be in place to reduce all the costs identified.  However, requirements that are clarified, reviewed, and traceable are key to making all those pieces be in place (and alleviate the cost of that too).

A common reaction of all of this is "Documentation is always out of date when the code is implemented"

This is what User Stories in a Scrum process are meant to alleviate.  I'll talk about this in some User Story post, but I'm already getting requests for describing the costs of getting a Release out after a Release Candidate has been cut so that might just be my next post.

Oh Hey This was in Draft for a Year

I had the opportunity to speak with someone who left the food truck business.  Food trucks are an interesting beast as they are just now becoming a pretty common in the St. Louis area.  Sure, there are some pretty well established hawker stands like that dude with the boombox at Olive and 6th, but the idea of getting your food off the street is still a new experience for a lot of St. Louisans during the workday.

Anyway.  I was looking at my blog stuff and saw that I still had notes for a post here.  I'm too lazy to see about actually putting these things into wordy-form so here they are.

The Idea

Provide a food truck meal with a gourmet twist.  Meals that included a side and a drink started a $7.

How it got Started

A loan for $50,000 from a combination of friends and family

3 partners - 2 ran the truck, 1 ran the business plans, supplies, and red tape.  The lady I talked to was #3 and would sub in whenever one of the other two wasn't available.

Making Money 

Stick with the city - County had way more red tape.  Only ventured there for single-day events like Stl County Parks

Sporting Events?  There were rules about the trucks that made it too much of a pain.

Tried to do catering events.  That seemed to go well but again, that only worked well in warm weather.

Competitors

Brick and Mortar - there is a rule that you can't be so close to a brick and mortar competitor.  That was annoying.
Other Trucks - Sure they tried to organize with each other so that they wouldn't cannibalize each other's business but a lot of times some of the other trucks ignored it.  You'd think you'd have a spot all to yourself and then boom.  Your lunch crowd just got cut in half because another truck showed up.

What happened at the end?

The Partnership ended when one of them just didn't want to bother anymore.  Business plan lady actually had a full time job so she didn't have time and they didn't feel like bringing in a new partner.

I personally thought the food was pretty decent and nowadays, lunch for $7 without a drink is pretty reasonable.  I really appreciated her speaking with me.

Costs of Software Beyond Code

So I might as well end my blog posting drought with a stupid gripe.

The software development cycle is but a small subset of the actual software product release cycle.

Sure, a lot of people are talking about Agile processes and getting a new release every sprint and whatnot but cutting a release for most software development teams means the following:

• We have some features developed!
• It's passed some sort of regression testing!

Especially in larger organizations, this is far from what's required to get a release out the door.

I work for a company where the developed software typically has 3 types of consumers:

• Developers within and outside the company
• A couple hundred marketing/accounting/operations folk who are in the same physical location as us
• Thousands of marketing/accounting/operations folk that are scattered around the country

Oh by the way, bullet two govern rules for bullet 3.

Coming from a large "systems of systems" integrator-esque company, it comes as a surprise to me how little care people take for delivering to another developer team.  Of course, they care when they're at the butt-end of the stick.

However, what's even more surprising is when a team isn't aware of all the work involved once a release has passed QA.

Especially for those thousands of folk scattered around the country, there's a boat load of preparation going on.  Training material, help documentation, videos, webinars, and conference demos are done to ensure that major features or even changes to existing features are flowed out and can be referenced in the future.

... and THEN there's the support and any issue investigation in production.  

The amount of personnel devoted to this is practically the same headcount as the development teams.

The absolute worst thing any team can do is simply provide these people some new features and say good luck!  No release notes.  No Requirements that fed into this.  Nothing.  Else.  Awesome.  You just tripled the cost of all the post-development work.  You probably tripled the cost of QA since you probably did the same to them as well.

I am of the firm belief that solid requirements that are reviewed early on by everyone in the release cycle is the key to efficiency in any software project.  The key words being reviewed and everyone.  It's pretty much everyone's responsibility to ensure that this happens as early as possible.  Unfortunately, what happens a lot is that everyone pretty much throws their arms in the air saying that it isn't their job and a combination of snowball and broken window effect happens.

I'll try to talk about a Shangri-la scenario in a Scrum perspective and also talk about what the overall deliverable set should be.

When I get around to it.

Coworker:  Hey.  (says something indecipherable)

Me:  Huh?

Coworker:  What?  You don't know?  (says it again)

Me:  I totally don't know what you're trying to say.

Coworker:  Awww c'mon...(takes a swig of orange juice, looking at me expectantly)

me: Are you trying to say Orange in Mandarin?

Coworker:  That's what I said.  (says that indecipherable thing again)

Me:  No, it's (Orange in Mandarin)

Coworker:   ?  (Says something closer but not quite)

Me:   (Whips out phone and open Google Translate) No... see?  (says Orange in Mandarin to the phone)

Phone:  Orange!

Coworker: (tries to say it to the phone)

Phone:  Meeting!

Coworker: (Tries again)

Phone:  Alley!

Coworker:  That phone is defective.

Gumbo Shop's First Facebook Ad

Ok so there are quite a few sites with how-tos about setting up a facebook ad... this one in particular is a little dated but is extremely detailed:

http://subliminalpixels.com/facebook/how-to-set-up-and-track-facebook-ads/

Rather than go into the mechanics of setting up an ad in general, I'm just going to talk about some of the rationale behind the very first ad created for the Gumbo Shop.

I'm actually pretty glad that it took me forever to write this post, because now there's a really interesting article discussing what people look at when presented with a Business / Brand page.

http://mashable.com/2011/12/14/eyetracking-facebook-brand-pages/#38865CocaCola-Visual-Attention-Level

My main takeaway from this article is that you need pictures and you need some decently compelling posts on your wall.  My goal for the very first ad is to get people to interact with your page, regardless of how populated it is.  Therefore, they'll populate the page and later on, people who WILL make their decisions based on the how populated the page is, will see a page with Likes, Posts, and Post Responses.

So what demographic will have people who not only know of the Gumbo Shop, but are the likely people who enjoy the place and will click that "like" button without a second though?

At first I thought of the regulars - people who work in the vicinity of the Gumbo Shop and come on a weekly basis.  The absolutely easiest way, of course, is to simply have a little sign at the restaurant "Like us on Facebook!" or something silly like that.  However, in terms of filtering on Facebook, the biggest problems with that were the following:

• Will have to get a listing of all the businesses in the area: even a decent representation would be pretty hard.  There aren't that many ginormous employers in that area where picking a couple will be good enough.
• Not that many people actually post where they work on Facebook anyway.

The next group of people that came to mind were people in St. Louis who likely sought out places like the Gumbo Shop: people who lived in states where Cajun food is much more prevalent.  Unfortunately, Facebook doesn't have a filter for "where people used to live," so education was the next best thing.

All the LSU guys I know in STL are Lawyers...

So after doing a quick Wikipedia lookup of  colleges where Cajun food is more prevalent, I went with pretty much all the Gulf States between Texas and Florida.  As for the ad, itself, I simply wanted to convey "Hey, remember the Gumbo Shop? We have a Facebook page now."  For that, I put up a pic of Gumbo Shop's logo and took my favorite Yelp quote on the place:

So I felt that this accomplished a couple things:

• Identify the Gumbo Shop.  Duh.
• Show a picture of yummy Gumbo.  The people this is aimed at, I'm assuming, have already had gumbo before.
• Point out that there's a positive review on Yelp.com by an (awesome) Lisa C.

Ok.  Now all that's left is to set a budget and maximum bid for clicks.  This means that every single time someone clicks on the ad and visits the Facebook page, I will be charged however much the bidding went down.  I don't really know how the mechanics all work, but essentially, the higher you place your maximum bid, the more likely your ad will be shown.  When there are many advertisers going after the same demographic you are, the more expensive this will likely to be.  I have recently found out that Women who are in a Relationship are quite expensive... but that's another post.

Self Explanatory.
http://sprott.physics.wisc.edu/pickover/pc/lifeexplained.jpg

At first, I set a daily budget of $3 and let Facebook have its way with my max bids.  In the end, I feel that this isn't the way to go.  I personally don't think that Facebook really does have a decent way of figuring out how to "maximize" the value of your clicks and it doesn't take any other input for your goals.  For example, your bidding and budgeting strategy can vary quite a bit if you goal was to get as many impressions (total times an ad is displayed) as possible in one month, as opposed to ensuring that you can get the best bang for the buck with at least so many impressions a day.

Also, the daily budget idea is a bit silly.  This severely limits how often your ad is going to be shown, as once that budget is hit, your ad won't be shown for the rest of the day.  Sometimes, on a Facebook heavy day (when people are home for the holidays, for example), you're going to hit that budget limit pretty quickly and then your ad will be pulled.  That's just pretty lame.  That, coupled with Facebook's relatively high automatic bidding, you're paying more for people to click on your ads while limiting how often your ad will be displayed.

So here're some of the metrics in the first month of that ad.

A "Social Impression" means that this ad was shown 1003 times where the target has a Facebook Friend who "likes" the Gumbo Shop.  Initially I was pretty satisfied with the results of this... with some fiddling we go through September's results...

WHOA what just happened... numbers are WAY higher for some crazy reason and yet my (yet undisclosed) costs were practically the same.  What the heck happened?  (aside from that fact that these screen shots are from Google Docs and Excel, respectively?)

Well... hopefully it won't take me more than a month to post the next post to explain some of that crap.

Angle of Attack

Starting out with a fresh Facebook page, you want as many fans as quickly as possible.  The easiest way to get that is let people who visit the Gumbo Shop to know that you, indeed, do have a Facebook page and that they should Like it to keep up-to-date on the goings on at their favorite restaurant ever.  These people are likeliest to not only Like the page, but actually maintain that interaction with the page.

But what about the people who don't already go to the Gumbo Shop on a semi-regular basis?  On the vast Internets, there are plenty of opportunities for one to come across your business online.

Search Engines
There are different ways you can try to ensure that your business shows up for a given search.  At the very least, however, you should be ensuring that the information is up-to-date and spend some time to add some media such as pics.  These guys are increasingly conglomerating more data from other websites as well to try to give as much information to people as possible.  Therefore, checking out search results for your business will show you what other sites people may come across as they're searching more generic terms like "Cajun" or "Fried Catfish."

Business Listing Websites
Speaking of websites that people may come across before they hit your business's website or Facebook page, there is a plethora of websites that index data from databases and allow users to update data and provide whatever information may be applicable to a business.  For restaurants in particular, there is an insane amount of Menu sites (SinglePlatform being a more recent one), review sites, or just meta sites collecting all that stuff together.

http://www.penny-arcade.com

Probably the biggest monster out there is Yelp.com.  They get so much traffic, they are almost sure to be the first couple hits if someone is searching for a particular item, or in the Gumbo Shop's case, a dish like "Blackened Catfish" in the St. Louis area.  Not only that, many people go straight to sites like Yelp or Urbanspoon without even bothering with the search engines.  These sites help people make conclusions whether they are going to check out a restaurant on their data alone, without even bothering to visit your website or Facebook page.  

Same with the search engines, keeping this data up-to-date is the least you should do.  Going all out on Yelp.com, however, means putting your own personal self out there to interact with those pesky Yelpers, but that's another post.

Online Advertising
Finally, what is perhaps the most obvious, is online advertising.  According to emarketer.com, Google has an almost 50% market share, where Facebook has below 10%.  So what would make one choose to advertise on Facebook than on Google?

http://www.the-cynic.com

To be honest, it takes far less effort to advertise on Facebook than on Google.  With Facebook, you create an ad, filter out some demographics because people put almost all their likes/dislikes/hopes/dreams on Facebook, and just fling it out there.  Google involves trying to figure out the actual behavior of the people you're going after and, on top of that, you actually need to do some photo-editing unless you're perfectly content with a plain text ad, and let's be honest, text isn't usually what draws you to an ad.

NEXT TIME, I'll finally talk about the thoughts that went into putting up my first Facebook Ad for the Gumbo Shop and talk about its performance.

Not-So-Random Gripe: Inaccurate Data on the Internets

Ok so while I was writing up the yet-to-be-finished post, I soon realized that a crap load of them menu websites are pretty much throwing in the towel and turned to this service called "SinglePlatform."

Now that's great because there's nothing more annoying than ensuring that things are updated on multiple websites, but I do have to gripe about the inaccurate menu that Single Platform did for the website:

Ok so the page is pretty blurry, but it's the same freaking menu for two restaurants, one being the Gumbo Shop in St. Louis and the other being ONE of the Gumbo Shops in New Orleans.  I'm sure this service is new and all, but at least have the quality control to simply say "we don't have the data for this restaurant."  It's understandable if you bought bad data from them business listing services (they really do suck), but I'm making an uninformed conclusion that this involves some silly assumption likely done by some code doing a massive data dump that matched a menu with said restaurant.

This is probably one of the most annoying things about Web 2.0 sites in general, as it's created a complacency of "we'll put up inaccurate stuff and the people will correct it" bullcrap.

Facebook Users are PIGS!

So what makes a Facebook Page better (or at least, more interesting) than other tools to aid in the Consumer Relationship Cycle?  It is one of very few tools where a brand can interact with consumers along almost all fronts of the Cycle.  The one thing that Facebook doesn't do is provide e-commerce functionality, allowing you to actually buy stuff on the site, but it comes pretty freaking close.  On top of that, almost everything is free.

http://verydemotivational.memebase.com 

I like bullets to list things:

• Avenues of Market Awareness
• Ads / Sponsored Stories (the only thing that really costs money)
• People's interaction with the Brand's page typically gets reflected on their wall and other's News Feeds:  Likes, Shares, Recommendations
• Methods to sway the flocks towards your brand
• Media (Photos, Videos, Links to external sites like reviews and news articles)
• People's interaction with the Brand's page typically gets reflected on their wall and other's News Feeds:  Likes, Shares, Recommendations
• Continuous Interaction
• Feedback
• News in a relatively non-intrusive way (Facebook News Feed vs. E-mail Newsletter)
• People's interaction with the Brand's page typically gets reflected on their wall and other's News Feeds:  Likes, Shares, Recommendations

Promoting interaction with a brand's page is obviously the most important aspect of managing a Facebook Page.  However, you can't promote interaction if people aren't "liking" the page.  Getting people to visit, like, accept your news feed, and interact is an entire Consumer Relationship Cycle in and of itself.  You're practically selling a Blog (really?) to promote the Brand.  

So let's think about just who we are targeting in order to raise awareness of the Gumbo Shop Facebook Page.  Warning: The following may seem extremely obvious, but as I've found, you sometimes have to go over these as people tend to not explicitly think about them... because... well, they're obvious.

Neo Geo's Obviously Awesome
http://keithapicary.bandcamp.com/

People Who Already Know of the Gumbo Shop and Like the Place

It will be pretty easy to get these people to visit the page and yet they are by far the most important.  This is because they are most likely to enthusiastically (and sometimes, emphatically) promote your brand as they interact with the page.  The Gumbo Shop has a pretty large work-lunch following.  If you're starting out extremely early, these people would pretty much be made up of your friends.  The usual points of entry to the page would be through Facebook Check-Ins or the fact that you just told them to visit the page in person (or with a sign on your cash register).

People Who Only know of the Gumbo Shop, but Haven't Ever Visited...

...or maybe at some point a long time ago.  At least they're aware of this place.  This is where the page content can tip them over into actually visiting the Gumbo Shop.  

Have no clue that the Gumbo Shop existed...

Honestly, I consider this group of people to practically be in the same bucket as those who haven't ever visited or haven't been in a long time.  This is because the starting point of interaction is the same for both groups: ads or news feeds from other friends on Facebook.  Of course, people could stumble upon your page from a link on your Website and from there a slew of other sources.... buuuuut we'll get to that some other time.

Next time, we'll talk more of these "points of entry."  There are many, much like in Deus Ex... which I've seriously been neglecting, lately...

Wait, so What Do You Do, Again?

I guess before I get into the actual crap that I'm doing, I should talk about the actual and ideas behind them.  My main goal is to increase foot traffic to the Gumbo Shop to help them sell more food and make money.  One additional side effect is to get more consistent foot traffic throughout the year, which can lead to significant cost savings and headaches.

I can try to accomplish that in a couple ways:  I get more people to recognize the fact that there is such a Cajun place called the Gumbo Shop at Manchester and McKnight in Rock Hill, MO.  I convince them that the Gumbo Shop, is indeed, the place to be and a place for good eats.  Lastly, I remind them that the Gumbo Shop really is some place they should visit at least once a week.

Honestly, the ideal customer is me, who isn't too far from that depicted in this particular Oatmeal Comic.

Replace the Pizza with Fried Oysters

To take another look at this whole thing, I'm turning to consultant-esque diagrams that you'd see at business school classes or meetings where people are trying to sell you on the idea that giving them $500 an hour is actually a good idea.  This thing can be called a variety of things ranging from "purchase cycle," "Customer Engagement Cycle," to "Consumer Relationship Cycle."

In my search for just the right diagram, I realized two things.  Firstly, there are all sorts of different points of view and little details that yield a shit ton of very different looking diagrams, but are very similar in nature.  It all depends on what direction you want to tackle the problem from.  Secondly, not one of them had a picture of a dog.

Notice the lazy eye...

For the sake of the fact that I'm too lazy to do a detailed flow chart, just believe in the following.

• A customer starts out not even knowing that the Gumbo Shop exists and therefore, out of the cycle.
• The first state of interaction is "Awareness," having the Gumbo Shop be somewhere near the front of their minds.
• At any point in this cycle (I guess somewhere on the arrows), a customer can drop out and the interaction has to start all over again ("oh yeah... I forgot about that place...").  

So let's go through these boxes:  

• Awareness:  Obviously people won't go to the Gumbo Shop if they don't even know it exists.
• Consideration / Comparison:  If people in general are anything like me, choosing what to have for lunch is an epic struggle for an hour starting at 10am on a daily basis.  Something's got to point out just how the Gumbo Shop should be at the top of the list on a consistent basis.
• Purchase and Evaluation:  Eating at the Gumbo Shop.  This is grouped together as this is an event that's going on practically simultaneously.  This is largely out of my hands... or is it?

FEAST

• Continued Engagement:  Usually, you only have the previous experience at the restaurant to ensure whether another visit is going to happen anytime soon.  This is where Continued Engagement comes in and where it can get sort of confusing.  I attempt to remind people that it's been absolutely way too long since they've been to the Gumbo Shop amongst many other things.

All Over Again?  

So just how can I keep this endless cycle of violence going?  My use of Facebook is the core part of Continued Engagement and Facebook Ads is by far the most invested method of increasing awareness.  The next posts that I'll put up will likely bounce around from topic to topic in this cycle, especially as new observations crop up.  I'll be tagging those with the appropriate term.

I totally expect Nestle Purina to steal my doggy diagram...

Why Facebook?

Eat at Joe's!

... and by Joe's I mean the Gumbo Shop...

So one of my life-long dreams is to own and run a restaurant.  One of my favorite things is to share the joy of good eats with someone, be it from something that I cooked myself or from a simple introduction to a new restaurant.  Each year I've been doing parties that have essentially been operational logistic exercises with crawfish boils and meats on sticks.

Unfortunately, I'm missing a certain something...

"... a set of these."

I am a risk avoiding coward.  There was absolutely no way that I'm going to drop my job to pursue any sort of risky venture.  So instead of actively pursuing my lifelong dream, I decided to try to learn as much as possible about the business on the off-chance that I am absurdly wealthy and the risk is diminished as much as possible or until I grow a pair.

Enter the Gumbo Shop.

I figured I'd spend some of my spare time offering the minimal skills that I do have to one of my favorite restaurants in St. Louis to accomplish a couple things:

• See how my skills apply to the restaurant business
• Learn whatever I can from the good people at the Gumbo Shop
• Have an excuse to visit one of my favorite restaurants more often

So earlier in the year I helped them set up a simple website and Facebook page.  Along the way I've cooked crawfish for them on Saturdays while it was in season and did some catering orders, both pickup and on-site.  Most recently, I've been bumbling my way through Facebook Ads.

I figured I'd take the chance to write some of my observations and experiences down from Customer Relationship Management through Facebook to this day when I dumped a total of 60lbs of crawfish for 80 unusually well dressed people.  As I think on this now it will likely be chock full of unfounded assumptions and too much thought going into something that's pretty obvious.  Either way, I get to share my experiences, those who care get to have my experiences shared with them, and the Gumbo Shop now has yet another avenue of an online presence.

Next: What AM I Doing?