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.”

AGILE HUMOR – Top Ten Reasons Why the Zombie Apocalypse Isn’t Agile

1. Zombies don’t iterate well.

2. A zombie can declare a project dead and move on.

3. Scrums aren’t productive because the answer to every question is the same. “Brains.”

4. Pair programming…well, trust me, it just doesn’t work out.

5. Viscera and keyboards aren’t a good mix.

6. You don’t have to a bribe a zombie with overtime pay to join a death march.

7. Their requirements never change. Oh wait, that’s why the Zombie Apocalpyse isn’t like Marketing.

8. You can’t go to a 2-day certification course to become a zombie.

9. Zombies only have one velocity – the relentless shamble.

10. You can’t get a zombie to grasp the concept of continuous improvement.

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.

Agile Humor – The Definition Of Done

The CMO: When the new functionality reduces the bounce rate from 40% to 4%.

The CIO: Done? When’s the release, 11:45? 11:46.

The PR Director: 11:45? I told ClickZ and TechCrunch it went live last Tuesday.

The Product Owner: When our new video has been viewed more times than that Evolution of Dance guy.

The Product Manager: It’s not done until the ten missing original requirements make it back into the functionality.

The Developer: It’s done. Remember we dropped ten of the features from this sprint when you told me it couldn’t be coded in Flash? Now they’re enhancements scheduled for Sprint…um…Omega.

The Analytics Manager: Done? It hasn’t started. You won’t have any data until they get the WebTrends tags working in Sprint…um…Omega.

The Scrum Manager: When the last hot fix deploys. What day is it? Never mind, bring me a Red Bull.

The Social Media Manager: Until Zuckerberg changes his mind again.

The Director of Sales: We changed the website? Oh yeah, look at that.

General Counsel: It’s done. I mean really done. The animal rights people are picketing on our lawn over that edgy new “Exploding Koala” logo. Take it down.

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.

A Marketer’s Guide to Agile Development – How Your Company Would Have Ruined the iPad2

co-written by Rick Butler

THE LOOK

“Isn’t it thin enough? Nobody’s complaining about the thickness, are they?”

“Just put some faux carbon fiber on the shell. It will cut costs and nobody will notice the difference.”

THE SYSTEM

“Our competitors are Flash compatible – we need to concentrate on fixing this deficit so Android doesn’t beat us on features.”

“We’re the fastest tablet out there already – why fix something that ain’t broke? Spend the resources making it Flash compatible.”

“Retinal display is great – but we don’t need it. Our core demographic is 18-25, and they can see just fine.”

THE CAMERA

“I already have a camera, why would I take photos with that? I don’t see people using it.”

“Just farm it out. We can save resources if we don’t have to design it ourselves.”

“Alright then, put the camera in, but don’t go wild. Nobody’s buying a tablet because they want to be the next Annie Leibovitz.”

THE COVER

“Our core competency is technology, not bags. License our logo out to a reputable sleeve manufacturer and let them do what they’re good at.”

“Our research says most users would probably hold the tablet in their left hand and type with the other. Put a strap on the back.

A Marketer’s Guide to Agile Development – Why Technical Debt is Your Problem Too

Close your eyes.

It’s Wednesday. Mom is coming for dinner Saturday night. More than 3 days away – plenty of time to clean the house. Then, the babysitter was out sick 2 days, then your middle-schooler announced Thursday that she just remembered the paper mâché model of a velociraptor was due to the teacher on Friday. And, oh yeah, it had to have a working mandible. And purple glitter. And the houseplants are listless – gotta make a run to the garden store.

Now it’s Saturday afternoon. The place is a mess. You’re out of time. So you heap up the leftover supplies and detritus from the velociraptor project into a shopping bag – you’ll sort through it later. You stuff it into the hall closet. You toss in the toddler’s coloring books and your work papers from when you were working from home. And the plant food. And wedge in the golf clubs that didn’t get put away last weekend. And throw in the waffle iron still caked with batter from this morning. Hearing the waffle iron clatter past the nine iron and thud for a landing, you force the door shut just in time to hear Mom’s car pull into the driveway.

Now it’s Monday. Instead of 5 minutes to feed the plants, it takes 30 to find the plant food in the last place you looked; the golf bag. And the next school project will be delayed while you sort through the shopping bag to identify usable supplies from trash. The golf bag glitters purple – not the look you were going for, but it will have to do. Waffles? Not so fast, you have to unearth and clean the waffle iron first, then add the time to actually make them. New rule – nobody gets waffles.

Now imagine the closet is your website, and the stuff in it is the “get-you-there” code. It’s hastily, sloppily written code that gets working software up and running under code complete deadlines. This cowboy code is a lot more likely to manifest when requirements are added at the last minute. The effort required to clean up after it is technical debt.

In a perfect world, developers write elegant code, which is liberally peppered with explanatory comments to guide others who amend or enhance that code later on. It doesn’t need constant tweaking to continue working, such as changing hard-coded dates every month. But a developer’s world is not perfect. For one thing, you’re in it. Remember your own contribution to technical debt when you hand in requirements late, or try to expand the scope mid-sprint.

Technical debt is why a seemingly simple change request may not be so simple to get into the code base. The same reason it will take 2 hours to produce a waffle next time someone asks for one.

A Marketer’s Guide to Agile Development – Scrum Roles

The Kvetcher – Your theme song is “Nobody Knows The Trouble I Seen.” Yes, progress can be hard-won. It’s not that we don’t care about your petty frustrations — oh wait. Yes, it is. We just want to know if the baby’s delivered – not a full description of each labor pain.

The Platespinner – Your theme song is “Piece of My Heart”. You’re calling into the scrum — but not all of you. You not only have us on mute – you’re on a second conference call on the other line, switching back and forth. Plus, you’re talking to the Sears dishwasher repairman. Pick a lane, buddy.

The Late Night FM Radio Host – Your theme song is “Papa Can You Hear Me?”. Um, no we really can’t. That low, meandering, mellow murmur, the “uhhhhs”, the long pauses, may be sexy and ultra-hipster on midnight community radio. Now it’s 8 am and you’re at work. Speak up – you’re telling us how your tasks are progressing. Not about how “Dark Side of the Moon” was mixed.

The Perennially Surprised – Your theme song is “What’s Going On?”. The scrum happens every day, same time, in roughly the same order. Not exactly a pop quiz, is it? Don’t put us through three and a half minutes of your mental journey that eventually ends at “no new updates”.

A Marketer’s Guide to Agile Development – The Ten Commandments for Marketers

Agile is thy methodology – the way, the truth, the absolute shiznet to thy development team. Thou shalt not use any other methodology – at least not here.

Thou shalt not bitch about the lack of up-front requirements – neither shalt thou commit scope creep.

Keep holy the release day. It’s ain’t movin’. It especially ain’t movin’ for thee.

Honor thy development team. Seriously. Some morning Dunkins, a toy, a damn pizza wouldst not kill thee.

Thou shalt not kill the development schedule with late requirements.

Thou shalt test. And test some more. Thou art not a representative sample of thy user base. Truly I say unto you, thou art not.

Thou shalt provide feedback when needed rather than when convenient for thee, lest thine development team proceed without it.

Thou shalt not hire a contractor to circumvent thy development team. Remember thou art part of the same tribe.

Thou shalt remain in scrum for its duration and not bugger off once thy project was discussed eight minutes in.

Thou shalt not covet your colleague’s project’s prioritization on the sprint by seeking to bogart the development cycle for thyself.

A Marketer’s Guide to Agile Development – A Rose By Any Other Name…

I came across something intriguing in my blog’s analytics dashboard. Somebody came to cathycarleton.com from Google yesterday on the keyword phrase “agile development minus the lingo”. Hmmm. Sorry visitor, you probaby didn’t find what you were looking for.

I wrote a couple of articles about agile lingo last year, meant to help non-technical business types understand the development teams that build their ideas into reality. But those articles assume the organization is using familiar Agile terms like scrum, sprint, backlog, various types of programming, etc.

My visitor’s search phrase brings up a good question – what if they don’t? Is it still Agile?

Rapid deployment, continuous improvement, and collaborative building all embrace the spirit of Agile regardless of what they’re called. Organizations that use these methods walk the walk, even if they don’t talk the talk. But what about philosophy? Can a repertoire of Agile-friendly practices by itself qualify a group as an Agile shop, even if they don’t specifically pledge fealty to the Agile Manifesto? Can they be Agile without formally declaring themselves to be part of the worldwide Agile community?

Sure. Agile is as Agile does.

So go ahead – call the scrum “morning progress bagel nosh”. Hell, call the release Tila Tequila if you want. Alistair Cockburn, who’s smarter than all of us put together (including Tila Tequila), has advocated scrapping the term “requirements” altogether and using the verb phrase “deciding what to build“. That’s actually better, isn’t it? Who wants to slog through requirements? But people will wait in line to help in deciding what to build. They’ll even bring the bagels.

Marketing Meets IT