Tag Archives: requirements

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 – I’ll Take Agile for $1,000, Alex…

A: 8-track tapes; sleeves on wedding gowns; heavy up-front requirements.
Q: What is nostalgia?

A: Data storage costs; mortgage industry headcount; development project documentation.
Q: What is downsizing?

A: Two face cards; Oliver and Hardy; driver/observer programming team.
Q: What is a pair?

A: Roy Rodgers; Dallas gridiron star; irresponsible coder.
Q: What is a cowboy?

A: Multi-trillion-dollar-national; post-ninety-day-unpaid bad; I’ll-go-back-and-clean-it-up-someday technical
Q: What is debt?

Agile Humor: More Agile Jokes

Did you hear about the Spanish Inquisition web analytics tool?
It tortures the data until it says what you want it to say.

What’s the difference between Agile and the Supreme Court?
There are women on the Supreme Court.

Why is daily scrum like a shot in the backside?
Either way, you won’t be able to sit down for 15 minutes.

Why is a code release failure like the Meadowlands after a Springsteen concert?
Someone’s staying all night to clean up the mess, and it probably ain’t the Boss.

Why is are poorly drafted business requirements like a vampire movie?
The stakeholder ends up getting it in the neck.

[rimshot] I’m here all week…try the veal…don’t forget to tip your waiters and waitresses.

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

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 – The Balance of Power Part 2

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 – The Balance of Power Part 1

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 – “Welcome Changing Requirements?” Who Does That?

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.