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

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 – “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.