Tag Archives: marketer

A Marketer’s Guide to Agile Development – When Your IT Department Pushes Back on Digital Tracking Tags

1. “Tracking tags will slow down our site.”

In my experience, tracking tags are often the first thing developers blame when sites load slowly. But even in the bad old days before asynchrony, tracking tags were rarely the real culprit. It’s even less likely now with tag management systems like Google Tag Manager and Tealium. So why does tagging get blamed instead of image formatting/sizing, java script minification, widgets, etc? Because IT is busy, and IT usually doesn’t own tagging. So, they kick the can to you. So, make sure the page tag is placed properly, prove through metrics that tag weight is negligible (it usually is), and kick the can back.

2. “We don’t have time to add tracking.”

IT departments in an agile development environment may classify tracking as an enhancement rather than a launch requirement. Remember, your IT buddies are graded on (a) coding and launching a digital asset on time, (b) adding enhancements and (c) making sure the asset continues to function well. Their bonuses do not depend on your ability to track. So take your favorite Finance Department buddy to lunch, sigh heavily, and opine about how much more efficient your budget could be if ONLY you could track right from launch. You’ve just gained political clout to move tracking from “nice-to-have” to “must-have”.

3. “Tracking tags can interfere with site functionality.”

Well, they could. But they won’t under your watch. Because you will make it your job to ensure tag library names are unique, and tracking is placed correctly on the page. Tags will be tested in the dev environment before going to production. Those are typically developer competencies, but your tags aren’t top-of-mind to your developer buddies. So help them help you. Once your developers reach a comfort level that your tags won’t break anything, the road ahead gets a lot smoother.

4. “It’s a waste of time to track all that stuff.”

Maybe so. That’s why you will have use cases – something like “If I knew “X”, I could do “Y”. For example:

“If I knew [which tools visitors from partner sites used], I could [optimize content to those visitors to increase engagement]”.

“If I knew [user article view sequence], I could [suggest ‘you-may-also-enjoy’ links for each article].”

Track what’s actionable now and in the future, and be prepared to justify each tag you add.

5. “Don’t tell me how to code.”

“Here’s what we’ve found works best” or “Here’s how other sites usually do it” can go a lot further than “Code it exactly the way we tell you.” I’ve found that patience, persistence and emotional intelligence can help Marketing and IT build a culture of measurement pretty quickly. At first, IT organizations may feel their autonomy is at risk when subtle code changes are needed to accommodate Marketing’s tracking. That happens. I knew we’d gotten past that hurdle the day a developer called me and said “Hey there’s no tag plan on this new functionality they just gave me to code – think we should we tag it?”

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 – 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 – 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 – Embracing the F Word

Marketers don’t use the F word very often. It makes them peevish and erodes their self-esteem.

No, no, no, I don’t mean that F word. Marketers use that one a lot. Like omigod, like verbal hot sauce they sprinkle over everything – more frequently than “and” or “the”. Oh wait, that’s me. But I digress.

I’m talking about F for failure. Failure is a dirty word in some organizations. You’ve all heard some of those old canards at some point in your careers:

“Failure is not an option.”

“I don’t want to hear about any problems, only the solutions.”

“The success of this project is critical to our ________ (financial goals, department’s ability to get budget dollars next year, new product launch, long-term strategy, next bonus payout, continued employment, yadda, yadda, yadda.)

“I can’t go into that conference room and tell my _______ (team, boss, department head, rival department head whose project was deep-sixed for this one, Exec VP, C-Level, board, shareholders, blah, blah, blah) that _________ (it’s too buggy to go to market by the launch date, we worked feverishly on a flawed assumption, the strategy was sound but we fell down on execution, the consultants recommended scrapping the project and starting anew, yak, yak, yak.)

“We’ve spent too much ___________ (money, time, resources, political capital, wah, wah, wah.) on this project to cut bait now.”

Failure is part of nature and part of life, but you’d never know it in some of these misguidedly rah-rah organizations that banish anything that doesn’t smell like success. People in these business environments learn quickly what’s required for self-preservation. They won’t say out loud that they tried something that didn’t work. Why is that?

Fear.  They’re afraid they’ll look stupid among their colleagues, and that will make them vulnerable. Ironically, they end up throwing stupid money at doomed efforts just to avoid looking stupid.

So they deliver an app that’s already obsolete by its release date instead of regrouping and redirecting the money and resources toward the app the company really needs.

Allowing people to admit failure is critical to success. It isn’t an excuse to be lazy, to embark on half-baked or vanity initiatives, to avoid accountability. The person in charge of a failed project is accountable to figure out what went wrong and how the business can use that learning to move on to better things. One never sets out to fail. In fact, if you have nothing but string after string of failures without a winner every so often, there’s a systemic problem. Maybe it’s a resource issue, maybe it’s politics, maybe overall company goals need some realignment. But if you’re never failing, you may be playing it too safe. There’s an old adage in auto racing “If you’re not crashing once in a while, you’re not racing hard enough.”

Some thoughts on avoiding this no-failure-allowed trap:

Be realistic about your odds of success – most businesses don’t have enough time or people to bring everything they want to do to fruition. Working smarter has its limits. When you can only push out a finite amount of product, every initiative becomes critically important – and it’s an easy mistake to mandate that each has to be a winner. That’s just not reality. Some will be black truffles, some will be turds. Making your people call the turds truffles… well, you don’t really want to go there, do you?

An Agile development environment will help you. Its iterative deliverables can help you discover that you laid an egg faster than other development methods – allowing you to rethink, retool, or move on.

Test. Test. Test. You engaged in initiatives on the hypothesis that completing them would improve some business results. Robust and disciplined A/B or multivariate testing will show quickly if your hypothesis is true or false. User testing (real users – not your lunch buddies) will tell you if you got the architecture and design right. Of course, you determined what the success metrics would be before the initiative began, right? Right? (tap, tap – hello, is this thing on?). And you would never be that guy who agrees on the success metrics, and when the test doesn’t support his hypothesis, attempts to discredit the test, right? (tap, tap, tap…)

If the testing shows that the initiative makes things worse and not better, then yes, you may have to throw out some completed work. Yes, it means your idea wasn’t a clear winner. Yes, it means that your development team may not get the validation of seeing their code come to life in production. We’re all grown-ups. If we didn’t have to make tough choices, it wouldn’t be called work and they wouldn’t have to pay us. Okay then. Let’s learn from this and try another idea.

So you didn’t find the black truffle this time. The truffles are out there. And you won’t find them until you pick another tree.

A Marketer’s Guide to Agile Development – 3 Lessons from Today’s Workday

Lesson: Even if you have a Dremel rotary tool hanging in the garage, sometimes that old putty knife in the drawer can still come in handy.
Today I took my department offsite to grok out a complicated analytical task. It had a lot of moving parts. After examining all the analytical and sharing tools at our disposal, SPSS, SQL, Meetingplace, Sharepoint, Wikis, KJ technique….I confidently selected the right tools for the tasks. The winner: MS Excel and a screen projector. With the addition of some comfy chairs and quality snacks, it got the job done.

Lesson: Know the difference between minutiae and details. You can probably get away with ignoring minutiae – not so much on the details.
The facility at which we held the session failed again and again to sieze opportunities to help us work efficiently. They sent us up to a room they said was open and wasn’t. Fifteen minutes lost there. The whiteboard and phone were there as promised, and the comfy chairs too. Good. Uh oh, electrical outlets 12 feet from the table, no power cords anywhere. Twenty minutes lost there improvising a new set-up. Tasty lunch, all the orders gotten right, on their seventy-five minute pacing instead of our forty-five. How many times have I seen my beloved Red Sox hit the ball well enough, but rack up enough errors to lose the game? It felt a little like that today.

Lesson: The most unlikely things can make the difference between victory and defeat. Despite the challenges, we got it done. Why? We’re professionals. We’re motivated. We genuinely like each other. We kept the process simple enough so we wouldn’t get lost in the weeds. And we had snacks. One place this facility overdelivered on was the cookies. Okay, they overdelivered them twenty minutes after we finished lunch, but they were better than… a lot of things in life. They injected the sugar rush that got us to the finish line. Who knew? Well, I did. Cookies and Excel. Sometimes it just works.

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.