Tag Archives: agile

Agile Humor

A Marketer’s Guide to Agile Development – What They Mean…

Leave a comment

What they say: “Help me understand this requirement.”
What they mean: “Drop this requirement. I’m launching a Kickstarter campaign to fund the bribe I’ll offer you to drop this requirement.”

What they say: “Let me confer with the team on the feasibility of that request.”
What they mean: “Maybe if we had a time machine… LOL. No seriously, you’re delusional.”

What they say: “By close of business.”
What they mean: “By the time our office closes. Our Honolulu office.”

What they say: “Late in the week.”
What they mean: “Friday at 4:49 pm.”

What they say: “Sometime next week.”
What they mean: “Next Friday at 4:49 pm.”

Data Analytics

Data Analytics – The Myopia of Estimates – Part 2

Leave a comment

Curiosity Wasn’t Priced In

Curiosity is a good thing. It’s vital when it comes to data. It uncovers the “why” behind the “what”. Failing to price in curiosity can be the difference between “servicable” and “wow”. Good analysts will follow their curiosity anyway.

Timelines Allowing No Mistakes or Delays

Someone will screw up and code will need fixing. Someone will come to work with the flu and infect 3 people. Machines will break. Approvals will be delayed. People will change their minds. Optimism isn’t your friend when it comes to estimating.

Death by Meeting

How long will it take to code this? About 8 hours.
Estimate: 8 hours
8 hours of coding plus 2 hours of meetings = 10 hours
Boom! You’re 25% over on the job.

The Myopia of Estimates Part 1

A Marketer's Guide to Agile Development

A Marketer’s Guide to Agile Development – A Tale of Two Christmas List Apps

Leave a comment

Last year I downloaded an app to help me keep track of my Christmas shopping. I paid the small fee for extra functionality and no ads. It did all the things it said it would do. But it annoyed the crap out of me every day I used it.

This year I downloaded a different app to accomplish the same task. The design is clunky and uses gaudy colors. It’s done up in some kitschy font – looks like Comic Sans on a bender. It also does all the things it said it would do. And I like it much better.

Why? Both apps track budgets, recipients, gifts and costs. But here’s the difference. This year’s app lets me think like a Christmas shopper, while last year’s app forced me to think like a DBA.

Let’s say I bought my nephew Alex a Tom Brady jersey for $48.

Last Year’s App:

Step 1: Click to the Recipient area
Step 2: Enter my nephew Alex’s name.
Step 3: Click “Save”.
Step 4: Click to the Gift area.
Step 5: Enter “Tom Brady Jersey” in the Gift field and $48 in the Price field.
Step 6: Click “Save”.
Step 7: Click back to the Recipient area
Step 8: Find Alex in the Name drop-down.
Step 9: Find “Tom Brady Jersey” in the Gift drop-down.
Step 10: Click “Save”.

I had to repeat these steps for every recipient, and almost every gift. It did have a feature where I could choose multiple recipients for the same gift. Useful if I was giving all my nephews the same Patriots jersey – which I wasn’t. So using it got pretty old, pretty quick.

This Year’s App:

Step 1: Click to the New List area.
Step 2: Enter Alex’s name.
Step 3: Enter “Tom Brady Jersey” in the Gift field.
Step 4: Enter $48 in the Price field.
Step 5: Click “Save”.

And we’re done. It probably creates the same tables as the other app. But it lets me enter the data using a shopper’s thought process instead of a programmer’s. So it’s a keeper. I guess now I have to pay $1.99 so I don’t get an ad every 30 seconds begging me to play Candy Crush.

A Marketer's Guide to Agile Development

A Marketer’s Guide to Agile Development – UX: Don’t Try This At Home

Leave a comment

Calling one segment “A” and the other “B” doesn’t make it an A/B test.

You are not a representative sample. You have skin in the game and you know too much.

Your typical user is not a programmer. Don’t force him or her to think like one.

Designers rule at Apple. Programmers rule at Microsoft. One created the iPod. The other created the Zune. UX matters.

If you can’t find the relevant copy on the site, it doesn’t matter how cool the font is.

A Marketer's Guide to Agile Development

A Marketer’s Guide To Agile – Top 7 Reasons Why Your Data Is So Crappy

Leave a comment

How and when data is captured is a vital part of decision-making in call center scripting, digital architecture, sales presentations, just about everything that touches a customer. There are things you can do to help make it better, but some issues will be always with us. So, here’s why your data is crapola, in no particular order…

1. TEXTING (yes, TEXTING)

In the data world, spelling counts. Whether data is being entered by professionals or by the customers themselves, text fields will be rife with errors. That is true no matter how clever you get with the drop-down boxes or type-ahead functionality. The proliferation of text-speak has made this worse, and spelling is rapidly becoming a matter of personal choice. That doesn’t bode well for text-mining. And no, spell-correct is not the antidote. Entire websites are devoted to how that can go horribly and hilariously wrong.

2. IT WORKLOAD

“Why can’t the digital dev folks just put another box in the online form so the prospect can enter their promo code?”

They can! They will! Just as soon as that work order rises up to the top of the priority list. Right now the project manager has it in the backlog. Where work orders go to ripen, get covered with brown spots, and die.

3.BAD DROPDOWNS

The data was shocking. Month after month, nearly a third of all disenrolling customers were dropping service due to bankruptcy. Nationwide. All segments. So I planted myself in the call center for a few days. In the CRM system, the drop-down box marked “Reason for Leaving” had 35 choices. “Bankruptcy” starts with a B, so it came up at the top of the drop-down. Too bad “Alien Invasion” wasn’t one of the choices, it would have been caught more quickly. So, yeah, that happens. In my experience, 12 choices is the limit for an effective drop-down in a call center. Any more than 12, and boom – 30% of the country mysteriously goes bankrupt.

4. POOR REQUIREMENTS

The marketer: “This email address is blank – it should be a required field.”
The analyst: “Someone input their mailing address in the email field.”
The email vendor: “Lots of these email addresses are undeliverable.”

Coding an email field with an input mask requiring a “@” character and a period will solve the analyst’s problem. Making it a required field will mean 100% of records are populated, which will satisfy the marketer (at least temporarily). Coding an email field with that input mask plus making it a required field will get you a lot of bad email addresses like “noneofyourbiz@buzzoff.com”. That can get you blacklisted with ISP’s. It can also spike your abandonment rate on the digital form page.

But marketers – it’s not the developer’s job to know that – it’s yours. He or she will code to your requirement specs. Think through the ramifications of stakeholder requirements – and make sure the requirements reflect a considered decision.

5. USER EXPERIENCE

First, let’s get one thing straight. UX and good data capture are NOT mutually exclusive. But what’s great for data capture isn’t always great for the user experience, and the two must be balanced. I once had an HR stakeholder tell me that data was vitally important to her, so it was a requirement that users submit 10 fields of personal data into a web form before they could browse jobs on the company’s career site. I told her that strategy would get her the best data and the three most committed job seekers she ever saw. The rest would bail.

6. COMMUNICATION

The promo postcards start hitting consumer mailboxes at 8am, and the TV ad blitz started airing at 9am. The campaign is a hit! Responses galore! Great! Except Marketing forgot to notify the Customer Service Manager that the promo schedule had changed, so she isn’t staffed up for the traffic onslaught. The unfortunate reps that are schededuled today can’t keep up with the volume. Calls are going unanswered. Their priority today is not great data capture. Their priority today is to take as many calls as possible and make it through their shift alive.

7. INCENTIVES

Sales reps’ income largely depends on how many sales units and revenue dollars they bring in. For customer service reps, bonus criteria often include average handle time, time-to-answer, off-hook time, etc. Sometimes data accuracy is part of the incentive formula, but it’s almost never the lion’s share. Generally, when short-term incentives are introduced for better data capture, data capture gets better. And when the incentive period is through, the gains recede, although hopefully to a little higher than baseline.

A Marketer's Guide to Agile Development

A Marketer’s Guide to Agile Development – Big Data Envy

2 Comments

Marketers are becoming as insecure about big data as they already are about mobile. It’s like the middle school dating scene – you think everybody else is doing it but you.

Don’t buy into the hysteria. Relax. Big data is real, alright. And, its potential really is quite vast. But its buzzword-du-jour status right now causes marketers unnecessary angst. Nobody wants to be perceived as anything less than cutting edge, and it’s a status thing to say you’re “doing big data.”

Before you hire the Hadoop gurus, ask yourself if your operation is ready to use big data. Are you already wringing enough insight out of your existing customer databases and retention data to move the attrition needle down a few ticks? Are you mining data out of your existing digital analytics tool sufficiently to inform decisions about content?

If the answer is no, then queuing up big data could be like buying your kid a new Escalade when he’s still learning to drive the 2003 Honda Civic.

As I said, big data has great potential – yet data won’t become insight until you ask questions and use it to get the answers. Let’s make sure that paradigm is working on the regular data before rushing to harness big data.

A Marketer's Guide to Agile Development

A Marketer’s Guide to Agile Development – The Myopia of Estimates

1 Comment

As I semi-reclined in the dentist’s chair this morning, my dentist told the hygienist a story. Seems his businessman brother-in-law suspected his employees were taking advantage of him by taking entire afternoons off when they had dentist appointments. Since the man had never needed a filling himself, he asked “How long do fillings typically take – all afternoon?” My dentist replied that it’s usually closer to 30 to 90 minutes to fill a tooth, which he said confirmed his brother-in-law’s suspicions that his employees were sandbagging.

“Hold on!”, I interjected, trying not to let my sporty paper bib, the drool escaping from my left lower jaw, or my Sylvester-Stallone-on-a-bender Novocaine drawl detract from my authority. “That’s how long it is for you. We patients usually choose our dentists close to our homes, not work. For an afternoon appointment, we have to drive to where you are (45 minutes to an hour in my case), do the “let’s have you fill out this form again and take a picture of your insurance card” ritual with the ladies in your office, then sit in the waiting room if you’re running late, then sit with you for 30 to 90 minutes of filling(s), then spend more time with the office staff to settle up the co-pay and schedule the next appointment(s), then drive back to office. We’ll be slurring in Novocainian dialect until dinner time, so we can’t call anybody – and the office closes in 20 minutes. Still think taking the afternoon off is unreasonable?”

So keep this story in mind when your Dev team is giving you an estimate of completion. It’s not just the coding time that goes into it.

“Yeah, I didn’t consider that.”, my dentist admitted. Hope he calls his brother-in-law back.

The Myopia of Estimates Part 2

A Marketer's Guide to Agile Development

A Marketer’s Guide to Agile Development – Ten Reasons Your Business is Fighting Agile

1 Comment

1. They’re not comfortable with change.

2. They don’t feel their voices are being heard over those of the development team.

3. They, or someone they know, didn’t get what they wanted in an agile development project.

4. Documentation is the go-to method for butt-covering, and lean requirements make them feel exposed.

5. They’ve learned to anticipate emergencies on release days due to poor version control.

6. Real-time decisioning is inconvenient when paired with all-day conference calls, wall-to-wall meetings and heavy travel schedules.

7. They’ve been preached at by a well-meaning Agile zealot.

8. They’ve afraid it’s flavor-of-the-month, like other “revolutionary” new processes that blazed in and sputtered out over the years.

9. They’ve lost faith in the backlog – it’s the place projects go to live with Jesus.

10. They think “collaboration” is Latin for “I don’t get to drive”.