Category Archives: A Marketer’s Guide to Agile Development

A Marketer's Guide to Agile Development

A Marketer’s Guide to Agile Development – How Your Company Would Have Ruined the iPad2

Leave a comment

co-written by Rick Butler

THE LOOK

“Isn’t it thin enough? Nobody’s complaining about the thickness, are they?”

“Just put some faux carbon fiber on the shell. It will cut costs and nobody will notice the difference.”

THE SYSTEM

“Our competitors are Flash compatible – we need to concentrate on fixing this deficit so Android doesn’t beat us on features.”

“We’re the fastest tablet out there already – why fix something that ain’t broke? Spend the resources making it Flash compatible.”

“Retinal display is great – but we don’t need it. Our core demographic is 18-25, and they can see just fine.”

THE CAMERA

“I already have a camera, why would I take photos with that? I don’t see people using it.”

“Just farm it out. We can save resources if we don’t have to design it ourselves.”

“Alright then, put the camera in, but don’t go wild. Nobody’s buying a tablet because they want to be the next Annie Leibovitz.”

THE COVER

“Our core competency is technology, not bags. License our logo out to a reputable sleeve manufacturer and let them do what they’re good at.”

“Our research says most users would probably hold the tablet in their left hand and type with the other. Put a strap on the back.

A Marketer's Guide to Agile Development

A Marketer’s Guide to Agile Development – Why Technical Debt is Your Problem Too

1 Comment

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

A Marketer’s Guide to Agile Development – Scrum Roles

1 Comment

The Kvetcher – Your theme song is “Nobody Knows The Trouble I Seen.” Yes, progress can be hard-won. It’s not that we don’t care about your petty frustrations — oh wait. Yes, it is. We just want to know if the baby’s delivered – not a full description of each labor pain.

The Platespinner – Your theme song is “Piece of My Heart”. You’re calling into the scrum — but not all of you. You not only have us on mute – you’re on a second conference call on the other line, switching back and forth. Plus, you’re talking to the Sears dishwasher repairman. Pick a lane, buddy.

The Late Night FM Radio Host – Your theme song is “Papa Can You Hear Me?”. Um, no we really can’t. That low, meandering, mellow murmur, the “uhhhhs”, the long pauses, may be sexy and ultra-hipster on midnight community radio. Now it’s 8 am and you’re at work. Speak up – you’re telling us how your tasks are progressing. Not about how “Dark Side of the Moon” was mixed.

The Perennially Surprised – Your theme song is “What’s Going On?”. The scrum happens every day, same time, in roughly the same order. Not exactly a pop quiz, is it? Don’t put us through three and a half minutes of your mental journey that eventually ends at “no new updates”.

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 – A Rose By Any Other Name…

Leave a comment

I came across something intriguing in my blog’s analytics dashboard. Somebody came to cathycarleton.com from Google yesterday on the keyword phrase “agile development minus the lingo”. Hmmm. Sorry visitor, you probaby didn’t find what you were looking for.

I wrote a couple of articles about agile lingo last year, meant to help non-technical business types understand the development teams that build their ideas into reality. But those articles assume the organization is using familiar Agile terms like scrum, sprint, backlog, various types of programming, etc.

My visitor’s search phrase brings up a good question – what if they don’t? Is it still Agile?

Rapid deployment, continuous improvement, and collaborative building all embrace the spirit of Agile regardless of what they’re called. Organizations that use these methods walk the walk, even if they don’t talk the talk. But what about philosophy? Can a repertoire of Agile-friendly practices by itself qualify a group as an Agile shop, even if they don’t specifically pledge fealty to the Agile Manifesto? Can they be Agile without formally declaring themselves to be part of the worldwide Agile community?

Sure. Agile is as Agile does.

So go ahead – call the scrum “morning progress bagel nosh”. Hell, call the release Tila Tequila if you want. Alistair Cockburn, who’s smarter than all of us put together (including Tila Tequila), has advocated scrapping the term “requirements” altogether and using the verb phrase “deciding what to build“. That’s actually better, isn’t it? Who wants to slog through requirements? But people will wait in line to help in deciding what to build. They’ll even bring the bagels.

A Marketer's Guide to Agile Development

A Marketer’s Guide to Agile Development – Does Agile Have Time for Research?

Leave a comment

Rapid development calls for rapid decision-making. Agile practitioners sometimes make the mistake of assuming that an Agile environment doesn’t have any spare time built in for research to inform those decisions. It’s not so. You’re actually more at risk for wasting time when you don’t research.

Research can take many forms, and a lot of insight can be gained very quickly.

Research is for grownups.

A big part of Agile culture is empowerment and self-determination. But developing software costs real money. The hard truth is that not every cool-sounding idea your brain spawns deserves to come to fruition. The ideas that should be developed are ones that research shows will advance your organization’s business goals – you know, the reason they pay you to come to work.

Research should be proactive.

It doesn’t matter what kind of software development environment you’re in. Which is smarter – a survey to find out if the Ultimate Extremely Cool Tool would solve a problem and/or delight users? Or a survey to find out why users won’t use the Ultimate Extremely Cool Tool your company spent four months developing? (If you’re unsure which one of these is smarter, you might want to take a personal day and read a couple of months worth of Dilbert comics to gain some clarity.)

Objectivity is a must.

Research should be done by people who don’t have as much skin in the game as the people writing the software. It needn’t – and indeed shouldn’t – be done by the development team itself, but by research professionals on staff or outsourced. Why? The same reason they don’t let judges preside over cases where their kid is a defendant.

Testing is a crucial form of research.

Don’t skip test-driven research – the lack of it could come back to bite you in the…area where you don’t want to be bitten. I wrote more about this recently. But don’t just take my word for it. Alberto Lumbreras has written some great blog posts about the subject, here. You know the old adage: “Act in haste, repent in Sprints 15 and 16.”

A Marketer's Guide to Agile Development

A Marketer’s Guide to Agile Development – Testing…Testing…

Leave a comment

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.

A Marketer's Guide to Agile Development

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

Leave a comment

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

A Marketer’s Guide To Agile – You Know You’re An Agile Wannabe When…

1 Comment

1. Your dress code prohibits hoodies – a key requirement of Agile.

2. You consider yourself an Agile centrist – that Manifesto sounds kinda socialist.

3. You keep a copy of the project requirements in your trunk for traction.

4. You hold a scrum every third Wednesday, whether you need it or not.

5. You favor Agile process – as soon as requirements, design, implementation, verification and maintenance are done.

6. The cafeteria vending machines don’t carry Red Bull.

7. You practice occasional iteration. Continuous iteration sounds so exhausting.

8. Your project manager is well-rested, takes long lunches, and golfs twice a week.

9. Your meeting minutes binder weighs the same as a small pony.

10. Stakeholders don’t want to know about coding progress – it would ruin the surprise.

A Marketer's Guide to Agile Development

A Marketer’s Guide to Agile Development – Three Degrees of Separation

Leave a comment

There are many types of seating arrangements you might encounter. Marketers new to Agile may be surprised that there’s actually office furniture specifically made for it. The look is modern, dividers are low, everyone can see and hear each other, and it’s great for fostering collaboration. Not so great when you need to call your doctor and describe that rash, though. A “caves” (private rooms) and “commons” (shared areas) approach can help when folks need more solitude than earbuds or noise-cancelling headphones can provide.

There are many configurations possible, with varying degrees of togetherness between the business and the dev team. Here are some examples:

REAL CLOSE – THE 2011 STATE OF THE UNION ADDRESS

The Public Relations Director sits next to the Scrum Manager. The Business Analyst sits next to the Email Marketing Coordinator. The Lead Developer sits next to the Social Media Manager. And they sip mochachinos and braid each others hair. Metaphorically, anyway. If (a) the dev team wants to commiserate about how clueless the business is or (b) the business wants to kvetch about how mean the dev team was for omitting the flash from the intro, each would have to get up and go somewhere to do it. Way too much trouble. If pair programming is in place, this configuration would be altered somewhat.

SORTA CLOSE – THE SEVENTH GRADE DANCE

The business folks on one side of the building, the dev team on the other side of the building. You share a stretch of carpet, maybe some common areas. Usually there’s a physical divider of some sort – a hallway, an atrium, conference rooms, elevators, a line of tables – something. You peer across the chasm curiously at each other. Bitching and eye-rolling at one another is kept on the down low – you could be caught. Come on, fellow Marketers. Grow a pair and cross over, it’s not that far. It’s dev – not Alderan.

SORTA CLOSE NOT REALLY – MARKETING IS VENUS, DEV IS FROM MARS

Separate buildings. Or cities. Try countries. This is where the commitment to collaborate really, really has to be there. Distributed teams are increasingly common, but here I’m really talking about dev teams separated from their business counterparts. Do the fly-ins – the team building events – the good video conferencing equipment. You’ll be fighting the “Us’ and “Them” syndrome. That battle isn’t the place to pinch pennies. Spend the money, and be vigilant.