Tag Archives: development

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

6. “Pssst…. hey, do you know how to do this web analytics stuff they’re talking about?”

Sometimes it’s because (a) they don’t know how to do it and (b) don’t want to admit to you they don’t know how to do it and (b) don’t think it ought to be part of their job to Google instructions on how to do it. This conversation may involve folks above your pay grade to get them to understand the importance of analytics and their role in it.  But have the conversation. Don’t give up.

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

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

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

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 – Ten Reasons Your Business is Fighting Agile

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

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.

Agile Humor – Words To Live By

Agilewashing – A waterfall shop that throws a scrum or two onto their schedule to seem cool. The Agile equivalent of a veneer, also known as “all hat, no cattle”.

Agillectomy – Removal of a development team’s efficiency gland by the new waterfall-loving CTO.

Hubristic Evaluation – When development teams assess usability by asking themselves what they would want if they were the user.

Documutation – Transformation of development notes from multi-page to post-it size.

Lame Theory – Mathematical constructs to predict how stupid decisions multiply in a group dynamic.

Kanbanista – Someone who is aggressively, revolutionarily passionate about colored tape on whiteboards.

Scrum of the earth – An Agile team that recycles.

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.