Agile Humor – Evidence That Downton Abbey is an Agile Shop

The Dowager Countess regards the telephone as an instrument of torture, too.

Even if all hell’s breaking loose, the dinner release deploys promptly at eight.

The gown Lady Sybil puts on before coming down to breakfast is only the first iteration.

The Downstairs department scrums for 15 minutes every evening over Mrs. Patmore’s mutton stew.

The Upstairs and Downstairs departments collaborate seamlessly when crises arise. Like, say, if a foreign diplomat croaked in Lady Mary’s bed or something.

Velocity is important. When Lady Cora rings that bell, O’Brien has to haul ass through eight rooms and up three staircases to answer it.

Mary and Matthew continue to overcome impediments to achieve their goal – marrying and inbreeding to carry on the Crawley line.

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

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.

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.

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 – 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 – Testing…Testing…

I don’t know if this is a universal trait – and I’m not entirely sure why – but my experience with Agile dev professionals is that there is a tendency to resist testing. I’m not talking about standard software Quality Assurance (incredibly, that’s not always a given either). I’m talking about A/B or multivariate testing, and true UX testing. These are things I have actually heard in my career as a marketing professional from dev groups.

“We don’t have the resources to do A/B testing – it would double development time.”

This person that said it misunderstood what A/B testing is. In most cases, you’re testing something new against your existing site – which is already developed and in production. So you’re only developing the new thing – and you were doing that anyway. Where’s the extra work?

If you’re introducing multivariate testing, developing multiple versions of something new would create extra work for a dev team that is used to allowing development of only one version at a time. But that’s the right way to do it for maximum iterative improvement.

“We are strapped for time – we don’t have time to develop things that won’t make it into production.”

You’re saying you don’t have time to find out if the change you’re working on to enhance click-thru rates will ratchet up the bounce rate instead. That’s dangerous to your website’s health. It means the whole enterprise needs to guess right 100% of the time – which just doesn’t happen. You’re also essentially saying you only have time to develop and deliver something once – and that’s it. Not very iterative, is it?

“Our dev team/marketing team/product manager would be demoralized if all their hard work never saw the light of day.”

That’s why they call it work. That’s why they have to pay you to do it. Certainly, we can make it fun. But ultimately, decisions on what does and doesn’t go into the final software release MUST be based on how that software accomplishes business goals. Team members who only feel validated by having their work seen can start a blog. Or therapy.

“Doing UX testing on only six people isn’t statistically significant.”

The same person who told me this also told me that he wanted a study on the top 1% of revenue-generators because that would be enough customers to be statistically significant (but surely you understand that the top 1% isn’t a representative sample for…aw, screw it, where’s my propeller hat?). UX testing is not the same as quantitative testing – five or six subjects are plenty. If you’re not sure why, read Jeff Sauro’s great blog post about user testing and sample sizes.

“We don’t need to test – we have a good feel for what users want.”

Robust, qualitative user testing tells you where you need to tweak to enhance your software’s usability. User testing is necessary, in part, because you may be too much of an insider, too in love with your own work, or too defensive about your work to identify the usability problems that can torpedo software adoption. It is also necessary because it helps remove our own biases and opinions (the dreaded “I think users would want”) as impediments to truly successful software. Skip it and you’ll risk shipping software that works but that users won’t use.

I had my frat buddy/luddite office mate/mother test it, and they said it was great!

User testing can’t be successful with insiders. Or insiders’ friends. Or insiders’ mothers. Real users won’t forgive you if it worked on your machine but doesn’t work on theirs. Users won’t let you explain the jargon that makes no sense to them and perfect sense to you. UX is a professional discipline – and no, you can’t do it just as well.

Agile Humor – Top Ten Rejected Agile Taglines

1. Accelerate Success But Let’s Not Get Crazy About It

2. Aggression In Its Most Passive Form

3. Delivering Your Lame-Ass Ideas Faster Every Day

4. We’re Not Arrogant – We’re Winning

5. We Put The “Um” In Scrum

7. Visualize Your Stakeholder’s Blank Stare

8. Thinner. Lighter. Faster. On A Good Day, Anyway.

9. Creating Velocity Without Personal Lives

10. Transforming the World Of The Lazy Marketer