Category Archives: A Marketer’s Guide to Agile Development

Agile Humor – Evidence That Downton Abbey is an Agile Shop

The Dowager Countess regards the telephone as an instrument of torture, too.

Even if all hell’s breaking loose, the dinner release deploys promptly at eight.

The gown Lady Sybil puts on before coming down to breakfast is only the first iteration.

The Downstairs department scrums for 15 minutes every evening over Mrs. Patmore’s mutton stew.

The Upstairs and Downstairs departments collaborate seamlessly when crises arise. Like, say, if a foreign diplomat croaked in Lady Mary’s bed or something.

Velocity is important. When Lady Cora rings that bell, O’Brien has to haul ass through eight rooms and up three staircases to answer it.

Mary and Matthew continue to overcome impediments to achieve their goal – marrying and inbreeding to carry on the Crawley line.

A Marketer’s Guide to Agile Development – Fumbling In the End Zone

Some Agile Marketing projects will wither and die. Oh, they get finished – they just won’t be used. Why?

A SOLO RUN DOWN THE FIELD

Sometimes a developer or team unilaterally decides Marketing’s had enough turns, it’s their turn – they’ll build their own vision. Seriously, I’ve seen it happen. Maybe it really is a great idea and Marketing just won’t green-light it. Maybe the two teams aren’t getting along. Whatever. The point is that deliberately skipping collaboration can allow departmental myopia to take over. It works out occasionally, if there’s a serious UX wonk behind the keyboard. But more often, a tech-only result favors the technical accomplishment – the user CAN complete their task – but the process is so annoying that users want to kick holes in their monitors doing it. And if the style and nav are to the specs of someone’s vision of cool, unmoored from the brand’s, users can bail thinking they’re on the wrong site.

DELAY OF GAME

It’s finished – or rather THIS CLOSE to being finished. Except for that bug that keeps coming back after each build. Except for the two months it went on hiatus to accomplish the Exec Pet Project Du Jour first. Except the requirements changed (bigtime) during those two months it was put on ice. Except the priorities have shifted again and it’s postponed again. Greece will be solvent again by the time it finally gets released.

TOO MANY PLAYERS ON THE FIELD

You know what they say about opinions – everybody’s got one. You’re on the last stage before release. Suddenly the CMO fancies himself a copywriter. The Steering Committee can’t agree on the font. The legal team makes last-minute design suggestions. The data team is suddenly all about the user experience. And the ops team notices three critical steps are missing from the flow – a week after they already signed off on it. There’s only one thing they all agree on: “WE CAN’T LAUNCH IT LIKE THIS!”

CLIPPING

The CTO has issued a directive. Get it out this sprint. Deliver it already. Ship the damn thing. Schnell! Schnell! It will get delivered – even if the features that make it truly compelling got clipped out of the sprint scope to make the release. Those features are no longer iterations on the way to global launch – they’re enhancements in sprint 15. The pressure for delivery is over, so who knows when those will get prioritized? This brings up the definition of “done”, which I’ve covered in earlier posts.

It happened in waterfall. It still happens in Agile – but hopefully with less development time wasted on the clock.

A Marketer’s Guide To Agile Development – When a Turf War Is Justified

Marketing and Technology both play for the same team – the organization that employs them. Turf wars between the two departments sap efficiency and impede progress. Turf wars are bad. Turf wars should be avoided. Except in the rare cases when they need to be fought. When’s that?

ONE TEAM’S WRITING CHECKS THE OTHER CAN’T CASH

If a non-technical executive is buying a tool that will impact server capacity and performance, the technical side of the house must have some say in the purchase. Even if IT isn’t paying for it. It’s not reasonable to expect the tool to work properly if you’re crunching ten pounds of data into a five pound server. Or if IT unilaterally makes the decision that 24-hour latency is sufficient when Marketing research shows real-time processing is essential, IT has some ‘splaining to do, and Marketing may have to fight for a better outcome.

THE OTHER TEAM’S GLACIAL PACING IS RACKING UP BIG OPPORTUNITY COSTS

Watch it on this one.
1) Is the delay actually hurting the company — not just hurting your reputation with your boss or your bonus?
2) If it’s genuinely hurting the company, can you quantify the damage caused by waiting?
3) Is the damage substantial?
4) Have you exhausted all attempts to present this evidence to the other team to goose them into action?
The answers to all four questions must be “yes” to justify the disruption and unease caused by wresting a project from a too-slow colleague. But if all four are “yes”, tell your counterpart that you have to act. Then do it.

YOU KNOW SOMETHING THEY DON’T KNOW

For instance, UX is an area worth a turf war. Email is another. If someone without deep knowledge of best practice claims ownership of either area, deep damage can result. This can come from both sides. IT can claim they own design architecture and UX’s recommendations are just an opinion they can take or leave. Or Marketing can pound their chests about how they own the messaging and no one has the right to tread on their First Amendment rights as they carpet-bomb the populace with inbox impressions. Either of these situations demand an intervention to preserve the commonwealth, by the most knowledgable grown-up in the room. Who is that grown-up? The one who can back up his or her mouth with the best evidence.

Play nice with the other kids, now. No shoving. Or, no unnecessary shoving.

Agile Humor – There Goes That Damn Lightbulb Again…

How many CTO’s does it take to change a lightbulb?

Two. One to screw in a new lightbulb and the other to retroactively declare it a planned outage.

How many help desk engineers does it take to change a lightbulb?

Three. One to tell you they can’t help you unless you can tell them the wattage and serial number of the lightbulb, one to bump it up to the supervisor, and one to inform you that they stopped supporting incandescent on the 30th.

How many web designers does it take to change a lightbulb?

One, I guess. But let me ask you, are we married to that lightbulb concept?

How many developers does it take to change a lightbulb?

None. They closed out the ticket, the lightbulb worked just fine in their fixture.

A Marketer’s Guide To Agile Development – Translated from the Original Marketarian

Marketarian: “Hot! Hot! Hot! This project is so amazingly important it absolutely has to be squeezed into the next release!”

Geek: “So this project is so amazingly important it has to squeeze out the amazingly important project you came to me with yesterday that absolutely had to be squeezed into the release?”

Marketerian: “Of course I understand and embrace Agile Process – why do you ask?”

Geek: “No reason. I’ve just never seen requirements delivered on a hand-truck before.”

Marketerian: “Hey, Trevor, I know Code Complete is tomorrow, but check out this idea, wouldn’t it be cool if we streamed a video of users’ faces using the app, maybe in a rich-media banner? Not real users, we’d use actors of course, but…hey no, no wait!! OMG, we could show real users if we added an upload feature, or maybe a combination of the two…”

Geek: “Squirrel!”

Marketer: “You need me to review it and approve it today? Does it have to be today? I’ve got an outing – er, meeting thing this afternoon.”

Geek: “You need me to build it and deliver it this month? If the answer is no, have fun at Six Flags!”

Marketerian: “I don’t want to be pinned down. I’ll know the right look and feel when I see it.”

Geek: “Yeah, you know, I’m not going to bet the rent on that.”

A Marketer’s Guide to Agile Development – Translated From The Original Geek

Geek: “That bug? We’re looking into it.”
Marketerian: “That bug fix has been prioritized just behind retrieving the Nerf dart out of the atrium soffit.”

Geek: “Put it on the backlog – perhaps it will be prioritized into the next sprint.”
Marketerian: “Perhaps it will be prioritized in 2013 assuming the Mayan Calendar doesn’t end the sprint early.”

Geek: “Trevor couldn’t reproduce that bug – the software ran fine on his machine.”
Marketerian: “If we can get all our customers to fly to our city, take a cab to our office, ride the elevator to the sixth floor and use Trevor’s laptop, we won’t get any more complaints about the software crashing.”

Geek: “Trevor did point out that the interface design does assume a minimum level of user skill.”
Marketerian: “Trevor thinks our customers are knuckle-dragging Luddite mouth-breathers who couldn’t be taught to use an interactive tool with a seven-hour webinar, Siri, and a mime.”

A Marketer’s Guide to Agile Development – Requirements

CRANIAL REQUIREMENTS

You’re too busy to sit down with the BA. You’ve blown off the last four scrums. You haven’t returned the PM’s calls. You can never remember how to get on that Wiki thing. Yet you whine, because the Dev team doesn’t build what you want? Developers are hired for their coding chops, not their clairvoyance. Jot it down, friend. When the requirements they must have to start coding are still in your head, what do you expect them to do? Drill a hole in your cranium to pry them free? They can’t do that. But they’ve thought
about it.

OOH LOOK, A SQUIRREL! REQUIREMENTS

Tuesday: You sign off on the prototypes.

Wednesday: You see an awesome video player on your favorite band’s site. You post the band page link to the requirements documentation, saying you want to change your video player to be more like that.

Thursday: You listened to a Jared Spool podcast and realized a 14-step login process to download a whitepaper may confuse the user into thinking they accidentally stumbled into the DMV site. You tell the PM on the way to lunch that you need that login reduced to 6 steps – no, wait, maybe 3. Maybe we need to rethink the login process altogether…

No, maybe you need to settle down and rethink your goals.

LEO TOLSTOY REQUIREMENTS

You keep your requirements in your trunk as ballast for improved traction in the snow. If you shredded them, you’d have enough confetti for a Kardashian wedding. Your requirements are the War and Peace of the project world. Did you really read every page of that book in school? Nah. Neither will the Dev team next week.

FIELD OF DREAMS REQUIREMENTS

“If you build it, they will come.”
“Go the distance.”
“Make a menu-like page.”
“The vibe I’m looking for is sort of, like, Middle Earth meets IKEA.”
“Make it exactly like that other page, only with a database.”

Lean is not synonymous with vague.

“I need a landing page for our promotion that will show alternating product photos from our image library, a couple headlines, and some call-to-action copy areas that link to our standard form.” is lean. “I need somewhere users can go to check out our promos and maybe buy one.” is vague. Go for lean.

p.s. IKEA would never make it in The Shire. Two Words. Round doors.

THE CIO/CMO RELATIONSHIP – A Marketer’s Guide to Agile Development

Some observations from the Forrester CIO/CMO Conference last week:

A COMBO CIO/CMO – LONELY AT THE TOP, BUT AT LEAST HE HAS EACH OTHER

Ponder the possibilities of one person serving as both CIO and CMO of the company. I have heard of two examples of executives doing this so far, one of whom I met at the conference. Leadership of both Technology and Marketing is a formidable reponsibility to shoulder on one’s own, but it does yield some advantages. For one thing, if you need to bogart some budget dollars, you don’t have to strongarm or cajole your counterpart. You just reach into the other pocket.

The CIO/CMO I met said that one of the secrets to avoiding getting overwhelmed was requiring all projects to have a 5-year cost/benefit plan. This weeds out a lot of ideas that don’t have strong legs from ever reaching the backlog. And, it weeds out a lot of “hey, wouldn’t it be great if….” mavens who don’t want to do the hard work of figuring out a project’s worth to the enterprise. And Agile development practices ruled the day there.

THE IT DEPARTMENT CHARGEBACK SYSTEM IS SEEN BY SOME AS A WORST PRACTICE

I heard an executive from a well-established company complain that, at her shop, the estimate for her Technology department to load a single marketing database table is three months and $50K. She swore it was not an exaggeration.

For many of us, it’s all we’ve known – the IT department as a cost center. You initiate a project, the hours the technology team spends building it gets charged to your project. Sometimes the hours it spends estimating the hours it will take to build your project are charged, too. It can be a catalyst for an adversarial relationship.

Let me know if this sounds familiar. Marketing battles it out and wins a place on the sprint. The project is built, but Technology had to jettison non-essential but user-friendly features in order to make the release on time. Without those features, it’s a clunky user experience. So adoption sucks. Marketing says that’s because the project’s not done – original features aren’t in there yet. But Technology says it is done – Marketing agreed to the changes in order to make the deadline, now those original features are enhancements which need to go on (cue ominous music…) the backlog. The CMO explodes when she hears this – she’s getting graded on customer adoption, which sucks right now. With arm-twisting, the features get crammed into the already-tight current sprint. Nights and weekends. Overtime. Enough times on that merry-go-round, and eventually IT starts sandbagging the estimates to protect themselves. So now it takes three months and $50K to load a table.

Some companies have combatted this broken system by making the CIO and the CMO equally accountable for metrics like adoption and customer satisfaction. The CIO and the CMO then have a really good reason to agree on the definition of done – their wallets. Another way companies have remedied this is for the CIO and CMO to work as partners – literally, not figuratively. Meetings several times during the day, offices next door to each other, one executive is never without the other in important meetings. They’re Butch Cassidy and the Sundance Kid, only with separate posses.

BEST PRACTICE COMPANIES DON’T ASSUME THEY KNOW

“If I were a user, I would want.”

“I just know.”

“Users liked this, so they’ll probably like that.”

You’d never hear these phrases in some shops. Best-in-class companies wouldn’t dream of mass-marketing or going live with something new they haven’t rigorously tested with users. In fact, one example in one of the keynotes was the application of technology specifically toward making testing easier, quicker, cheaper, and more nimble. These were big-money projects, but there was not even a question of whether they were going to test – the only question was how efficiently. Testing isn’t exactly sexy – but it’s necessary, and often skipped by less committed shops. But robust testing is what happens when the CIO and CMO are equally committed to producing outcomes and not just projects.