Tag Archives: sprint

A Marketer's Guide to Agile Development

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

Leave a comment

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

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

Leave a comment

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

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

Leave a comment

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 Marketer’s Guide to Agile Development – Why the Numbers Still Don’t Match

Leave a comment

So you got a business intelligence system. It’s gonna be great! No more frustrating meetings where you spend half an hour wrangling over whose sales number is right! One source of truth, pure and simple! Suckerrrrr. Like Oscar Wilde said, the truth is never pure and rarely simple.

For instance, your BI system will have selectable date ranges – Harry will pick Monday through Sunday, Sally will opt for Sunday through Saturday, and they’ll both label it as “last week” on their slides. And then, there’s the problem of departmental myopia.

The data:

The Simple Question: How many widgets did we sell last week?

BUSINESS INTELLIGENCE TEAM

Ten. You put ‘WDGT’ in the prompt box. There’s ten of those. Where did the other two go? I don’t know, but feel free to put in a ticket and we’ll look into it after the tomorrow’s sprint 5 release.

FINANCE

Four. The ones with the MarginBuster promo are zero margin, so they aren’t really sales. Damn those Marketing guys…

MARKETING

Eight. Our MarginBuster promo code brought in eight sales. Gotta run, getting my chest waxed this afternoon.

WEB ANALYTICS

Three. WebTrends says three. Offline sales? Uh, geez, I seem to have left my abacus at home, bro. No taggie, no countie.

OPERATIONS

Eleven. One canceled. Sales guaranteed him the widget would get him first position on Google for the term “cool”.

FULFILLMENT

Four. We don’t count the load if it ain’t in their abode. If it ain’t come to fruition, you don’t get your commission. If it ain’t off the truck, it’s not worth a…well, we don’t count it yet.

SALES

Twelve. Gimme my bonus.

A Marketer's Guide to Agile Development

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

Leave a comment

In a previous column, we reviewed some reasons why some marketers give Agile the stink-eye. Let’s review why developers may be sending that stink-eye right back at ’em.

They’re annoyed – by short attention span theatre.
Marketing is all about the art of the possible. Brighter, shinier, cooler possibilities assail marketer’s brains constantly – it’s relentless. Those deep thoughts surface at inopportune times – like when their original, slightly less cool vision is in testing phase. Intellectually, they may know the enhancement should wait for the next sprint. But emotionally, this new cooler version becomes their vision of the finished project. So they become serial badgerers, imploring the PM and the developers to make “this one little change” here, “a small tweak” there. Hey marketers – a little discipline please. If you catch yourself uttering a sentence that begins with “keep it exactly the same, except….”, snap the elastic on your wrist and go back to your desk.

Sure, some marketers argue that Agile environments are supposed to welcome changing requirements. They do, in theory. The GOP welcomes healthy bipartisan debate in theory too. Theories are like that. Unlike the GOP, Agile doesn’t filibuster – it simply pushes the change to backlog. Or depending on the rank and title of the badgerer, stays late and does it, and harbors resentment.

They’re misunderstood – most marketers are clueless about sprint process.
Many marketers do actually think that if their request is not yet in production, they can still make changes, even if it’s 3 in the afternoon and the release is at 5:30. They’re not really trying to be jerks, they simply don’t know better. But they should. Responsible marketers, with the help of the project manager and/or scrum manager, learn the rhythms of the development organization that brings their ideas to life. When they do, they understand that recalcitrance isn’t the only reason behind a refusal to accept a change. But development teams take notice – once a marketer has taken the time to understand and honor your process, you’ll have to stick by your process too. No more blue smoke and mirrors.

They’re resentful – they’re the ones staying til 8:30 on Friday night.
Let’s just say it. Marketers have a reputation of not working very hard. Full disclosure, I’m in Marketing. That Dilbert cartoon with the sign that says “Marketing – 2 Drink Mininum” hangs on my wall. But trust me, most of us work our share of nights and weekends – usually individually instead of communally. Maybe because we’re not visibly toiling away night after night as a department, development teams can sometimes assume that they’re doing all the heavy lifting while Marketing lounges on divans eating bon bons while watching Oprah. That’s a myth. We only eat bon bons if the mailhouse vendor sends them at Christmas. And we only watch Oprah when we’re home sick. Some of us not even then.

They’re apprehensive – Marketing can declare all their work a failure.
A pet peeve of mine is when I’m in a meeting where someone justifies a decision with “well, I think users would want…” I just want to cut off that sentence with an air horn. Good marketers test. Good marketers declare success metrics for their initiatives, and Agile teams should abide by the same set of metrics. In my experience, when Agile teams reject Marketing’s analytics in favor of their own metrics, usually their own analytics tell them they don’t need to change their code. Objective, dispassionate measurement makes continuous improvement possible. It doesn’t matter if a developer missed his high school reunion to code the new product page, or the Angel Gabriel handed the style guide down from the sky to the CMO on an iPad. If Marketing Analytics results show that it’s decreasing rather than improving conversions, that page is going bye bye until they figure out why.

They’re jealous – Marketing gets all the cool swag.
The new branding campaign launches. Marketing gets the leather bomber jackets with the new logo on the sleeve. The developers get logo coffee mugs that can’t go in the dishwasher. Marketing celebrates the launch at Le Chateau Tres Cher. The developers stay back at the office with a Quizno’s platter to code the hot fixes. This dynamic is actually changing in some organizations. Marketing budgets aren’t what they used to be. And IT executives can order swag too.

A Marketer's Guide to Agile Development

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

Leave a comment

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

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

Leave a comment

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

A Marketer’s Guide to Agile Development – Backlog Bingo

Leave a comment

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?