Tag Archives: marketing

A Marketer’s Guide to Agile Development – Cool New Jobs in 2011

Really enjoyed the great Derek Huether’s post about zombie meetings on his blog The Critical Path. And it got me thinking…perhaps our meeting-crazed corporate culture could actually spur some new job growth?

LAPTOP WALKER

Vacationing workaholics often chafe at their spouse’s demand to leave their faithful companion at home. So, offer your services as a laptop walker!

Assure your PM you’ll carry his laptop around the office to ensure it gets proper exercise while he’s away. The head of biz dev can rest easy knowing you’ll bring her laptop into meetings so it can be with other laptops. And thanks to your laptop grooming service, your scrum master will be greeted upon his return by a sparkling clean laptop fresh from its anti-bacterial wipedown, cucumber-melon scented compressed air bath and deep registry cleaning. Appreciation to Chuck Twining for the idea.

STEALTH SCRIBE

Thanks to Agile’s lean documentation tenets, meeting minutes in general have fallen out of fashion. They’re useful, alright (see my previous post on the subject). But some feel they’re a wasteful time-suck, that time saved not doing them can yield more time to write code. That means YOU have to waste more time verbally bringing last week’s absentees up to speed, and argue about what you thought you decided.

But you can have meeting minutes without risking being taunted with epithets like “Agile Wannabe” or “Waterfallooza”. Take the minutes in secret! There are lots of ways to do this. Pretend you’re answering emails while other attendees are talking – completely believable as Fred’s actually doing just that across the table anyway. Use the notes feature on your iPhone – your unsuspecting colleagues will think you’re texting your fantasy team picks while you’re really documenting what you agreed to track on the new landing page. Hah – pwnage!

MEETING BOUNCER

Let’s finally get serious about meetings – time to put the hammer down on equivocators, pontificators and serial opiners. As meeting bouncer, you’ll put attendees on notice that you’re prepared to throw their sorry asses out of the conference room/phone bridge for offenses like:

– Side conversations
– Beginning any remark with the words “In this tough economy”
– Checking into Foursquare – there is no mayor of Conference Rm #203 to oust
– Reading all the words off their PowerPoint slides verbatim
– Not knowing the function-key F8 trick
– Mouth-breathing so loud that call-ins think they called an x-rated chat line

A Marketer’s Guide To Agile Development – There Are No Dumb Questions – Oh, Sure There Are…

Hey Marketers – Admit it, you chuckled that time you heard your Dev team brethren talk about “sending out an email blast” and that other time they confused the terms headline and tagline. News flash — Dev’s laughing at you too. Get acquainted with Agile so you’ll know better than to ask these side-splitters:

Can you give me admin rights to my computer so I can install Agile?

Nope. It’s a process, not a product. You would no more “install Agile” than you would “install cross-branding”. Well, maybe you might need to be set up with rights to certain sharing areas, virtual meeting tools, perhaps a project tool such as Basecamp or GoPlan. But you probably will not need anything at all installed in order to get involved in your company’s Agile process.

That stand-up meeting is really messing with my schedule – can we make it weekly instead of daily?

Don’t be such a Marketer. I know, it’s early. Yes, it’s daily. But if your organization uses scrum, and you’re the business owner, you gotta be there. If you’re not, the iterations happen without you. And decisions will be made that you may not like.

Just email me that Kanban, okay?

Well, maybe. A Kanban board is usually an actual board. It can be photographed and emailed, I guess. But (a) it’s changing constantly, and (b) a key point of Kanban is the players being there to look at it. Not every Agile shop uses Kanban, but it’s useful to know what it is.

How much does one of those Agile licenses cost?

Nothing. Bupkes. Agile is a decision you make to develop software in a certain way. There’s no Agile division of Microsoft trolling around to sell you a license for it. Yet.

Can I CapEx this Agile installation?

No. If you buy special furniture to accomodate an Agile environment, you could probably take that as a capital expense. But you don’t CapEx thought.

But it’s only 2:45. The release isn’t until 4:30. Why can’t you squeeze the great new idea I thought of in the shower this morning for the splash page nav into the release?

Because. Lean requirements and documentation may make Agile seem casual, but it’s not a stream of consciousness – there is discipline in a healthy Agile shop. There is a specific rhythm to the release schedule, and that rhythm includes hard dates. Requirements have due dates, and so does code complete (which means just what it sounds like). If you know so little about the release schedule that you think this is a legitimate question, reach out to someone on the dev team to explain it to you. Or click my previous post to learn that “we welcome changing requirements, even late in the development cycle” carries a little fine print.

A Marketer’s Guide to Agile Development – Scrum Etiquette

Don’t all speak at the same time.
If the team members in your sister office wanted to dial into a daily cocktail party, they’d have transferred to Marketing.

Lose the attitude.
Don’t get all huffy and snarl “of course it’s on the documentation wiki!” at 8:03am when your wiki update is datestamped 8:01am.

Never refuse a breath mint if a colleague offers you one.
Sausage croissants smell great before you eat them. Afterward, not so much. Early morning, crowded meeting – I’m just saying.

Be on time.
Scrums are fifteen minutes long. That’s it. No wonder you’re always five minutes late for it. A grande half-skinny half-caf half-Equal split shot 1-pump mocha with room isn’t a coffee order – it’s an Olympic dive. Grab a Red Bull and make the scrum on time.

Be honest – but not too honest.
“I’m so hung over my eyelids are nictating” may be the most truthful response to the question “Do you have any problems preventing you from accomplishing your goal today?” But it’s TMI – just finish the widget, okay?

A Marketer’s Guide to Agile Development – Wait…So Following a Plan is Bad?

The Agile Manifesto is quite clear about how much it values following a plan – not so much. Response to change gets the love instead.

Therein lies the marketer’s dilemma. CMO’s notoriously have a hot nut for project roadmaps – but Agile development teams often don’t welcome detailed plans – ooh, ick, they’re so Waterfally. So how do you assure your sort-of-Agile-not-really leader that you are executing on a marketing project plan that’s not being sequentially followed by the folks who are actually building the software?

Show him or her your backlog items.
It may be hard to get your C-level comfortable with a list of tasks that you have no guarantee will be done by the next sprint. You could add in the kanban, which is more of an operational aide than a executive presentation medium. But at least you can prove that you understand and have presented to the tech foks what needs to be done.

Demo the latest iteration of working software.
Sure – but beware of expectations. Marketing and Technology executives can define “working software” very differently. The apps dev team delivered a screen for the April 16th sprint release that slowly brings up week-old data from the dev server when you click the “submit” button. Server call performance will be addressed in a future sprint. The CTO: sprint mission accomplished. The CMO: my order history doesn’t come up – this thing doesn’t work.

Some advice – if the current iteration isn’t yet optimized for performance, don’t show it to the CMO. Sometime between pressing the “Let’s Get Started” button and the 112 seconds the app takes to complete the server call, you’ll lose trust. If the current iteration works with reasonable speed, but is missing some non-essential functionality, it probably won’t hurt to show the progress being made, with the proper caveats and disclaimers.

Pretend it’s still waterfall.
Show the wireframe of the screen in active development, and say “they’re working on this part now”. Hey, that worked for years.

A Marketer’s Guide to Agile Development – What Agile Can and Can’t Do

Agile can’t: Make stupid people smart.
Agile can: Make smart people more efficient.

Agile can’t: Properly prioritize objectives if business owners can’t.
Agile can: Help business owners to properly weigh priorities.

Agile can’t: Fix a failing strategy with good process.
Agile can: Use good process to continuously improve a flawed strategy.

Agile can’t: Compensate for a profound lack of resources.
Agile can: Make the most of limited resources.

Agile can’t: Replace corporate vision with what’s cool and fun to work on.
Agile can: Inject cool and fun into the corporate vision.

Agile can’t: Be a business objective.
Agile can: Help business objectives become reality.

A Marketer’s Guide to Agile Development – Spanish Inquisition Analytics

CMOs say it all the time.  “The great thing about digital marketing is that you have hard data to know what’s working. Data doesn’t lie.”

Nonsense. Data does lie. Data lies all the time. Like a rug.

Spanish Inquisition Analytics means torturing the data until it says what you want it to say.  Reminds me of my youth when I was learning to drive a stick-shift in hilly New England – grind it till it fits.

I’m not talking about spin. If you completed 100 projects through April, then added 5 more in May and 10 more in June, you’re more likely to say:

“we saw a 100% incremental gain in month-over-month project completions in June” (June minus May, divided by May)

than

“we increased the number of completed projects by 9.52% in June.” (10 in June divided by 105 total at the end of May)

Both statements are factual. The first makes the project manager look better on a PowerPoint slide, and that’s okay – it’s just spin. Marketers frikkin’ love spin – having invented it and all.

Spanish Inquisition analytics aren’t mere spin -they’re deliberately crafted to mislead. While true analytics prove or disprove a hypothesis, Spanish Inquisition analytics assumes a positive position, then changes or eliminates data that doesn’t support that proof. Here’s an example uncovered in July 2010 by MediaMatters.org:

Fox News showed this chart to support a story that job loss was still soaring. But since the data didn’t support their premise, they tortured it by cherry-picking the quarterly results that fit their premise, and eliminating those that did not. Notice the timing of the data points. The first data point is December 2007. The second is 9 months later, the third just 6 months later, and the fourth a whopping 15 months later. The data they used is technically correct – but it’s showing cumulative instead of incremental data on an improperly paced timeline. The story? US jobs are still being dropped faster than 8am Foundations of Western Civilization. The reality? Here’s how the data actually looked – a decidedly different story.

It’s like picking out the cheese, tomatoes and croutons out of a salad and passing it off as pizza.

Another trick is to skew the research itself to support your aims. Target a marketing campaign solely to customers who have bought every iteration of your software on their release dates, and you’re likely to report a 95% take rate. But you better stay away from reporting the ROI -because you just paid to get people to buy who would have bought anyway. Test a targeted web product only amongst your allies and immediate circle, and you’ll get data, alright. But use that data to project satisfaction with your site, and you’ll be blindsided at launch when your target audiences don’t find it true to their vibe.

You want to look good? Get some Botox. You want to get some real insight? Let your data people tell the real story. Nobody expects the Spanish Inquisition.

POSTSCRIPT – February 24, 2011

Hey kids, here’s a brand new way to torture analytics from – you guessed it – your friends at the Fox News Academy of Creative Analytics. If Gallup Poll results don’t support your argument, just invert them! 61% of Americans oppose taking away collective bargaining rights? Presto! 61% of Americans now favor it!  Yup, this actually made it on the air. Here’s a link to the story.

Full disclosure: I lean left. Yet, my beef with Fox in these two cases are as a data professional rather than a liberal. Facts aren’t inherently truths. But facts changed to support predetermined conclusions are inherently lies – regardless of ideology. 

A Marketer’s Guide to Agile Development – Top 5 Reasons Marketers Hate Agile

DISTRUST – THEY’VE BEEN BULLIED BY A ZEALOT
Agile can be a revolutionary marvel when everyone keeps their egos in check – Marketers’ egos especially. But marketers feel burned when Agile development professionals, maybe drunk on empowerment, start delivering what they think the marketer should have asked for instead of what they actually did ask for. As said in previous posts, the marketer blames Agile practice for this arrogance, not the practitioner. Especially when they’re on the receiving end of the lecture on how there’s no need for turf wars because Agile is collaborative.

FEAR – THEY’RE AFRAID FOR THEIR JOBS
Some Agile teams mistake empowerment for omnipotence. User experience, email best practice, product demand and ROI, SEO impacts, call-to-action placement – marketers develop deep expertise on best practices over long periods of study and immersion. Do they feel threatened when an Agile developer two years out of school feels her expertise equals theirs because she read “Don’t Make Me Think” over the weekend? Affirmative.

FATIGUE – THEY’RE AFRAID TO TAKE A DAY OFF
The marketer’s project requirement was scheduled to take 2 hours of coding time, but the dev team hit a snag. In the land of Waterfall, marketers were rarely if ever asked to stop their daily activities to accommodate coding questions. No, they’d be asked if they had an opening on Friday, (sorry, golf event, how’s Tuesday?) to discuss the coding dilemma nice and civilized over an International Coffee Cafe Mocha in the conference room with the new comfy chairs. Then Agile comes. Suddenly, marketers are stalked on their way to the loo to make decisions NOW. No scheduling. No Cafe Mocha. Standing, no comfy chairs. And if the marketer or a proxy isn’t available, a member of the development team makes the decision for them. Yeah, tee off without me, guys. And pass me a can of Monster.

JEALOUSY – THEY’RE NO LONGER THE COOL ONES
Marketers always attended the cool events and conferences, controlled the cool swag items in the prize closet, wore the cool threads. Now the dev team gets the paintball outing, attends SES on the opposite coast, has the interesting desk toys and rocks matching team logo retro bowling shirts. Marketers who perceive loss of status tend not to embrace their usurpers with open arms.

CYNICISM – BEEN THERE, DONE THAT, BOUGHT THE SOUVENIR TEASPOON.
What does Agile remind some marketers of? Sweatin’ to the oldies. MBO. Process Re-Engineering. Six Sigma. Quality Circle. Knowledge Management. Total Quality Monitoring. The Ultimate Question. Peak Performance. One Minute Manager. Email blast. Greed is Good. Once these initiatives were that dreamy guy in the Lethal Weapon movies, now they’re just Mel Gibson. Many marketers don’t want to get all sweaty again for a fad that will fall out of fashion. So they simply stall and wait for it to be over. You know, like Prince says the Internet is.

A Marketer’s Guide to Agile Development – I Pledge Non-Allegiance

Sign the Oath of Non-Allegiance!

Oath of Non-Allegiance

“I promise not to exclude from consideration any idea based on its source, but to consider ideas across schools and heritages in order to find the ones that best suit the current situation.”

Love, love, love this oath – from our friend Alistair Cockburn. Why is it needed? To remind turf warriors and methodology zealots that “Us versus Them” intolerance robs the business of progress. The Oath has lots of uses, because projects unfortunately tend to spawn multiple factions: Continue reading A Marketer’s Guide to Agile Development – I Pledge Non-Allegiance

A Marketer’s Guide to Agile Development – The A Word

Marketers sometimes encounter Agile developers so full of themselves they’re leaking hubris all over the Kanban board. There is no part of the Agile Manifesto that says “It’s nothing personal – it’s just that we’re better than you”. But since most marketers are not that familiar with Agile principles, it’s not surprising that they blame the practice and not the practitioner when they encounter this behavior.

Does Agile breed arrogance? No more than ships cause barnacles. Agile in its best form fosters empowerment, and empowerment is very different from arrogance. It’s empowerment to use the best idea, not “I reject your reality and substitute my own.” In my opinion, arrogance is a perversion of Agile methodology, and an enemy of Agile acceptance and integration. The real evangelists of Agile are the ones who can communicate to the business what’s good about Agile in terms other than what’s good for developers.

But other Agile evangelists, in their zeal to bring the good news to those perceived to be waterfall worshippers, will assign Agile cult status. They then think they have license to shun and ridicule those who are not in the cult.

When a member of an Agile development team treats a marketer like a superfluous throwback, talks to him condescendingly, uses lean requirements as an excuse to build to their own vision instead of collaborating, and rolls their eyes and smirks when disagreements arise, the marketer blames this abuse on Agile. A product manager who works diligently with a team, sees her input ignored, then ends up with a product that technically works but users hate, concludes that Agile doesn’t work for product development. A brand manager who discovers shortly before launch that the development team was only pretending to work with him to prevent any interference in their workflow (via a process known as blocking), sees Agile as the justification for bad behavior. Things you might hear:

“I’m not changing my design just because UX said it’s not customer-friendly. That’s just their opinion.”

I don’t buy the premise that collaboration means that all opinions are created equal. I’m a database guy who is reasonably well-informed on user-centered interactive design and architecture. But branding myself a UX expert because I once listened to a Jared Spool podcast is as intellectually honest as saying I’m a nuclear expert because I stayed at a Holiday Inn Express. There are professionals that do UX for a living, and there’s a boatload of best practices that they know about and I don’t. Inclusion is great, and we’re all special, but neither my opinion nor the developer’s should carry more weight than the expert in the room. Nobody’s an expert on everything.

“We can’t take sprint time away from features coding to work on analytics – you don’t really need the data anyway.”

What the what? Do you build a car without a speedometer so you can get the leather seats just right? Do you refuse to take your temperature when you’re sick, because your intuition is better at detecting a fever? The business flies blind without success metrics, and the developer shouldn’t have line-item veto power over them. Of course, the analytics people shouldn’t be the only ones insisting on tracking. The business should be the ones to push back on any pressure to jettison analytics in order to cram more features into the sprint.

“You’ll have to prove to me that this enhancement is worth my time.”

Everyone who touches a project should know its purpose, its goals, its worth to the business, etc. If the business is not using proper discipline to prioritize projects, the development team may be within its rights to question whether an item belongs on a sprint. That doesn’t mean developers have unilateral authority to pick what they’re going to work on.

Agile can energize marketers and allow them to respond more nimbly and decisively to the needs of the business. But marketers must trust the process and trust the players to make Agile collaboration a success. If the trust is not there, or has been broken, it’s not a small “grumble at the watercooler” type of problem. It’s an emergency that must be resolved before real progress can be made.

A Marketer’s Guide to Agile Development – Backlog Bingo

My own requests to get on sprint backlogs are often analytical – that whole measuring success thing, for a variety of reasons: (1) enhanced analytics the business didn’t realize would be needed when a feature or function originally went live (2) basic tagging that should have been included when a feature or function went live but didn’t make it into the original sprint(3) tag modifications made necessary by site changes (4) repairs to tags that worked in test but for some reason broke in production.

Save your comments, I know Scenario (4) shouldn’t happen. Neither should petroleum-coated pelicans, decaf espresso or the Heidi & Spencer union, but hey, what can I tell ya?

Delivering working software is priority numero uno in an Agile development environment. Now analytical tagging is software, but it’s not the kind you can point to on a screen when your buddies are over and say “See that page? That was me.” So how will you get it prioritized over the other coding projects that result in something you can screenshot and put into a slide presentation? Or a developer’s resume? Or a fellow marketer’s resume?

Marketing has to lead the way in fostering a corporate culture that values the measurement of success as an integral and non-removable part of any website initiative. A healthy Agile environment begets continuous improvement – and continuous improvement requires baselines and monitoring to keep score.

If coding that enables measurement isn’t considered valuable software, then your analytical requests simply may not make it. Sexier coding tasks – the ones you can see, hear, click, monetize – will rise to the top of the sprint list – and your analytics request will go to shady, grassy section of the backlog to live with Jesus and Ronnie James Dio.

Tracking the success of what you build is not an enhancement or a feature or an add-on. It’s what marketers and developers need so they will know what to do next to dynamically enhance performance. And what could be sexier than enhanced performance?