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?

A Marketer's Guide to Agile Development

A Marketer’s Guide to Agile Development – the Definition of “Working Software”?

Leave a comment

It seems so simple -“working software.” : What’s not to like? Way preferable to that other kind of software that – you know, doesn’t work. Between the Agile Manifesto and its twelve principles, that phrase is used three times. Working software is not the cheese on Agile’s macaroni – it is the macaroni.

What’s not so simple is getting consensus on how to define that phrase. Enter “definition of working software”, with the quotation marks, into Google, and you’ll see lots of opinions on how it should be defined. And who should define it. Here are some potential definitions

The reasonably Agile marketer – test-proven iterations of software with functionality and results consistent with my requirements and agreed-upon changes.

The sort-of-not-really Agile marketer – test-proven software with complete functionality as per the requirements document (the whole enchilada, pages 1 through 117 plus the appendix) and results consistent with my original vision two Aprils ago.

The cowboy marketer – I don’t know much about working software, but I know what I like. What I’m saying is I’ll know it when I see it. Oh, and p.s. — that ain’t it.

The responsible Agile developer – test-proven software with functionality and results consistent with my business owner’s requirements and agreed-upon changes.

The sort-of-not-really Agile developer – Who the hell knows? It will be working in Phase…9? 10? Actually, I’m kinda in the weeds, bro. Ask me next Memorial Day.

The cowboy developer – It worked last Tuesday. It looks freakin’ awesome. Competent users will figure out the navigation.

The definition of working software is a contract between the business side and the development side. Are you working without a contract?

A Marketer's Guide to Agile Development

A Marketer’s Guide to Agile Development – Hello Cleveland! If You Can’t See Them, Is It Still Agile?

1 Comment

The scrum or stand-up meeting is a major part of Agile methodology.  Ideally, everyone works in the same area (called co-location), and talking in person is considered the most effective way to work.  In fact, face-to-face communication is considered so important to the effectiveness of the methodology, it has its own line in the Agile Manifesto: The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

But there’s a wrinkle – it’s estimated that over 25% of American workers now telecommute, and that’s increasing.  Others work in offices located states or even oceans away from their co-workers.   How does this new state of affairs affect the future of Agile methodology?

Well, the simple answer is that it makes it harder and potentially less effective.   The line actually refers to communication between the developers themselves, but business owners, SME’s, and other key players in a project are affected as well.  What are some ways around that?  

CONFERENCE CALLS –  If the scrum is truly 10-15 minutes long like it’s supposed to be, it isn’t so awful if it’s a conference call.   But the problem with conference calls is that they take sometimes take 10-15 minutes to start.   The conference bridge has a glitch that makes everyone sound like they’re speaking from the Field of Dreams cornfield (oddly, sometimes with the same dialogue).  The scrum master says “Who just joined?” eight times after eight beeps because we all know only rubes say their name when the Webex robo-facilitator asks you to.    You all wait a few minutes for the lead developer who it turns out is taking a personal day.  Her boss would have told you that, if he hadn’t overslept the 8am EST call because it’s 5am in Seattle and he got home from the Muse concert at 2:30.  Then you have to ask Monty the mouth-breather to put it on mute, IM Jerry to quit answering emails because his keyboard tapping is making the microphone cut out the first two words of everyone’s sentences, ask Sandy to mute as well because you just heard the last call for two US Airways flights as well as her Starbucks order….that’s the bad news.  The good news is that on a conference call, you can’t see the developers’ eye-rolling when the business people speak.

VIDEO-CONFERENCING

Ha!   Teleconferencing is a cruel hoax.   Remember how disappointed you felt when you were 15 and found out Bill Gates wouldn’t really send you $149 for forwarding that Microsoft email?   I feel that way every time someone suggests a teleconference.  People say it’s real, but no one you know has ever had it pay off.    Some still try.  This usually requires plugging, unplugging, replugging, stabbing the f8 key repeatedly, giving up and locating one of the two people in the whole company who know how to set up teleconference, the guy comes in and performs the A/V equivalent of alchemy and then tells them they just had to hit f8.  By that time, the office you’re trying to remote with has dispersed and the next meeting group is knocking on the window because they need the conference room.

Here are links to a couple of decent articles about the effect on Agile process when teams can’t be in the same place at the same time.  The consensus is that Agile can be done when co-workers aren’t together, but it’s just not quite as good as when they can smell each other’s coffee.  Or Red Bull.

http://www.smartagile.com/2007/11/agile-tips-when-co-location-is-not.html

http://news.oreilly.com/2008/08/is-telework-the-face-of-the-ag.html

A Marketer's Guide to Agile Development

A Marketer’s Guide to Agile Development – The Balance of Power Part 3

1 Comment

In Part 1, we had a marketer seemingly off his meds mistaking the development team for short order cooks.  In Part 2, we had a developer drunk on cowboy code, smugly delivering what marketing would have asked for if only they had his superior vision.

There could have been a third scenario where the hyperactive marketer and the arrogant developer were in the same scene, but that would be too divisive.   Here goes:

Marketer (played by Bette Midler):   Yo, Poindexter – this is not what we talked about.   This landing page looks like my ferret sicked up.  What the hell is this?

Harried Business Analyst (played by Philip Seymour Hoffman):  Okay guys….   Wait – you know what?  This is not going to end well.  Maybe I don’t want to be in this scene.  In fact,  I’m calling in sick from this scene. (exits)

Developer (played by Shia Lebeouf):   Your RHN was a little light on details, so it was necessary to iterate some continuous improvement on that bad boy.  

Marketer:   My RHN?

Developer:  Requirements on Hooter’s Napkin.

Marketer:   That napkin was so freakin’ agile, my friend  – and more documentation than I’ve ever seen come out of your shop.  But this call to action makes it look like we want them to renew their truck registration at the DMV.  THIS ISN’T WHAT I ORDERED – er, I mean wanted.  

Developer:  What you wanted didn’t match my vision of deep cool.   You said they had to be able to submit a webform on the page, and they can.   And preview all the products.  And personalize them with virtual logos they design on the fly. 

Marketer:  Customers don’t want that.  What makes you think my customers want that?

Developer:   Because it’s cool.  Deeply so.   Customers want cool.  It’s not our fault you blow into work every morning 30 minutes after scrum ends.  Non-attendance means acceptance.  No feedback means acceptance.  So does arguing with any code that’s already through QA.

Marketer:   What are you guys, the Borg?

Developer:  Hell, no.  The Borg was too centralized to be Agile.

Marketer:  Screw it, I don’t need you.  I’ll just have the agency build it.

“Us vs. Them” mentality exists in every business.  But maintaining and nurturing the chasm just isn’t – well, Agile.  I love this quote attributed to Alistair Cockburn, an original Agile Manifesto signatory: “Always remember, there is only us.”

A Marketer's Guide to Agile Development

A Marketer’s Guide to Agile Development – The Balance of Power Part 2

Leave a comment

Non-Collaborative Agile is really an oxymoron – but here goes:
“Non-Collaborative Agile –  the Motion Picture”

Wary Marketer (played by Gary Shandling):   “So I’ve reviewed the prototype, and I’ve got to tell you, it’s not really what I thought we talked about…”

Harried Business Analyst (played by Michael Cera):    “Well yes, it looks like a few enhancements were made along the way…”

Wary Marketer:  “Enhancements?  Come on now.  The call to action is in the footer, and what’s with all those navigation bars, and…

Hotshot Developer (played by Russell Brand):    Step away from the waterfall, Abe Vigoda.  This is 2010, babe.  You marketing types just don’t get it, do you?    Agile empowers us to take your vision and make it into an even better vision.    We felt users wouldn’t want to see a web form right in their face on prime real estate.  So we moved it – and that is some badass Ajax slideshow right there above the fold, am I right sir?

Harried Business Analyst:   “Look, guys, why don’t we talk this through…

Hotshot Developer:   Not unless you can prove to us the original way was better.  What we did was a vast improvement over the requirements we got.  If marketing isn’t willing to embrace our process, I’m not sure what else we can do.

Wary Marketer:  “Hold on right there – this is my page supporting my campaign.  The call to action is –

Hotshot Developer:   Oops.  Later, dudes.  I’m late for my team-building exercise.

Stay tuned for  – The Balance of Power Part 3

A Marketer's Guide to Agile Development

A Marketer’s Guide to Agile Development – The Balance of Power Part 1

1 Comment

An old boss of mine used to have a small wooden plaque on his desk.   It said “JDI” – “Just Do It”.   Not in the Nike “you go, girl”, self-empowerment sense.    More in the “just because I’ve finished talking doesn’t mean you get a turn now” sense.   Anything short of “right away!” and he would silently nudge the plaque in your direction.   Good times, good times.   Marrying up that imperious client attitude up with Agile development would probably be a big mistake.   But here goes: Agile –  The Motion Picture”

Hotshot Marketer  (played by Alec Baldwin):   What up dawg?  Ding dong ding dong, yo!

Harried Business Analyst (played by Ben Stiller):  Dude, nobody talks like that anymore.   And you’re from, like, Duluth, aren’t you?   Anyway, what are we building today?

Hotshot Marketer:   “So here’s the logo – it’s going to go here, and you’re gonna make it blink and jump out of the frame and turn into rocket fire and then Yoda from Star Wars.  Or maybe smoke then Harry Potter.  Or those Top Gear guys – anyway, we’re still hammering out the talent rights, I’ll get back to you on that.    And be sure to code it in Flash, just to stick it to Steve Jobs on that iPad thing – you gotta get it done, too, ‘cause I already bought the media – and…

Harried Business Analyst:    Well, that’s a risk, we sort of have to nail down who’s jumping out of the frame if we’re going to finish…

Helpful Developer (played by Paul Rudd):   Hey, I have a suggestion – if we change just a few things, move this over here, let us handle the coding, we could gain the flexibility of…

Hotshot Marketer:   “Yeah, thanks bro, I’m totally not hearing that.  I want what I want.   Whose page?   My page.  Who’s the customer?  I’m the customer, right?   Whoa – I’m late for the links.   I got your requirements right here on this napkin – ignore the Hooters logo, of course.  Just do it, babe.”

A Marketer's Guide to Agile Development

A Marketer’s Guide to Agile Development – We Don’t Need No Stinkin’ Meeting Minutes

2 Comments

I once read a blog post that said there shouldn’t be any meeting minutes in the world of Agile because:
1) the absence of minutes will force people to attend meetings
2) every moment a developer is forced to document is a lost opportunity to write code.
3) meeting minutes will undermine collaboration by – you guessed it – enabling people to miss meetings.

So if it weren’t for those pesky meeting notes, developers and business owners would go to the meetings instead of watching their kindergardener’s holiday plays, attending funerals, taking a sick day, going to the dentist, or waiting for AAA to fix the flat tire?
So, following that logic, you take them away, and folks willl straighten up and haul their sorry kid-applauding, condolence-spewing, virus-harboring, floss-neglecting, side-of-the-road-loafing asses to the scrum meeting where they belong. Assuming they don’t trip on the hubris on the way to the meeting room.

Come on now. Lighten up. People miss meetings. Eliminating meeting documentation doesn’t make it happen less often. It just magnifies the loss in productivity when it does happen.

But no one really reads them. Really? I just read some today because I had to – uh – miss a meeting. Plus, I wrote some meeting notes last week. That act prevented needing another meeting when a colleague was asked to present insights from that meeting to his boss. Would writing them on his hand be more Agile than having a brief, cohesive synopsis of what we discovered? There are wikis, Sharepoint, MeetingSense – it need not take more than a few minutes to document.

Scrums are supposed to be progress meetings, but they’re frequently more than that. Opinions are sought. Decisions are made. Commitments are pledged. They deserve to be quickly recorded. Don’t want to take the extra few minutes? How long is a “we need to get Brad up to speed” verbal briefing take out of a 15-minute scrum? How long does a call-and-response chorus of “but you said…”, “no, I believe I said” take to resolve?

Write it down already.

A Marketer's Guide to Agile Development

A Marketer’s Guide to Agile Development – “Welcome Changing Requirements?” Who Does That?

10 Comments

Yeah….maybe “welcome” is a strong word. Then what’s the right word? Tolerate? Humor? Laugh and point? If welcoming changing requirements, even late in development, is a key tenet of the Agile Manifesto, why does the marketing team feel about as welcome as Keith Olbermann at a Tea Party rally when they try to get changes done?
Here’s the thing. Say you’ve got a six-week release schedule. The backlog priority meeting was three weeks ago, and Release 5 is scheduled 3 weeks from now. You’re getting mucho static when you try to convince the development team that your new McGuyver Social Media functionality absolutely has to be part of Release 5. You say there’s three more weeks – plenty of time to squeeze the change into the schedule. They say they’ll get it into a future release. “So much for welcoming changing requirements!” you say.

But here’s their view. They’ve got to get Release 5 out, and the deadline for completed code is next Friday. And another tenet of Agile is to “deliver working software frequently”. So they keep working toward the sprint instead of implementing your change so they can make the delivery. That’s what their boss is grading them on. If your enhancement is important enough, it will get into the next sprint, right? So they’re not saying “no”, they’re just saying “yes, but later’. Right?

No. This ain’t your first time in the rodeo. You know that “we’ll include it in a future release” is the IT equivalent of “the check’s in the mail”, “I’ll fight for you in Washington” or “Facebook values your privacy”. You know that once the original version is coded, there will be zero interest in plucking the enhancement out of Backlog Purgatory. “Iron Man VII – Recycle or Die” will be in theatres before you see it implemented.

The problem isn’t one of process but of trust. Both Marketing and IT need to trust the standard of requirements and appropriate use of backlog.

Requirements are a funny thing in Agile. Some requirements, even in an Agile environment, still go “thump” when printed. Extreme Programming proponents say that a requirement should fit on an index card. Others have questioned the very nature and necessity of requirements. Consider this quote from Scott W. Ambler: “Is something really a requirement if it evolves over time? Is something really a requirement if it gets deprioritized and as a result never gets implemented? Is something really a requirement if it gets reorganized into smaller pieces and then only a subset of the pieces is implemented?”

Marketing and IT have to align their expectations. Whether requirements in your shop can fit into a single tweet, or they’re wav files in a database, or they’re printed, bound and given a Library of Congress number, figure out what’s method is right for the business and set realistic protocols on how change should happen within that method. If you don’t, this conflict will happen in every sprint. As for the backlog, its effect on the perception of requirements change will depend on its reputation. When a requirement goes there, is it considered bound for the bullpen or the showers? Fix the way the backlog is perceived and you’ll fix a lot of this conflict between marketers and developers.

Marketing Meets IT