Tag Archives: backlog

A Marketer's Guide to Agile Development

A Marketer’s Guide to Agile Development – Ten Reasons Your Business is Fighting Agile

1 Comment

1. They’re not comfortable with change.

2. They don’t feel their voices are being heard over those of the development team.

3. They, or someone they know, didn’t get what they wanted in an agile development project.

4. Documentation is the go-to method for butt-covering, and lean requirements make them feel exposed.

5. They’ve learned to anticipate emergencies on release days due to poor version control.

6. Real-time decisioning is inconvenient when paired with all-day conference calls, wall-to-wall meetings and heavy travel schedules.

7. They’ve been preached at by a well-meaning Agile zealot.

8. They’ve afraid it’s flavor-of-the-month, like other “revolutionary” new processes that blazed in and sputtered out over the years.

9. They’ve lost faith in the backlog – it’s the place projects go to live with Jesus.

10. They think “collaboration” is Latin for “I don’t get to drive”.

Agile Humor

Agile Humor – Why Did the Chicken Cross the Road?

1 Comment

THE BUSINESS ANALYST

I have twelve meetings today, I don’t have time to get into the whole user story. But I can tell you it involves a rooster on a distributed team.

SOCIAL MEDIA MANAGER

So the chicken can check in and oust the Mayor of the Other Side of the Road.

THE AGILE PROJECT MANAGER

The chicken is just not going to be able to cross the road this month. Crossing requirements were due last Friday. She will have to take her place on the backlog. Maybe the chicken can cross the road in Sprint 9.

WEB ANALYTICS

We’ll need to get some tags on that chicken to be able to tell you that.

THE BUSINESS OWNER

Because I have three other business initiatives riding on the chicken being on the other side of the road that were supposed to start six weeks ago. You’re killing me.

UX

The question isn’t why the chicken crossed the road. The question is why the chicken felt she had to cross the road. If a coop’s usability issues won’t allow chickens to complete their egg-laying tasks, they’ll bail that coop and find another one that will.

THE DEVELOPER

Because the requirements said so. The trebuchet was the most efficient method. Oh, she had to get to the other side alive? Where was that in the requirements?

SCRUM MANAGER

Let’s iterate, people. Let’s get the chicken to the center line today, and we’ll talk about the rest of the way tomorrow.

More Agile Humor – Why Did the Chicken Cross the Road (2)

A Marketer's Guide to Agile Development

A Marketer’s Guide to Agile Development – Wait…So Following a Plan is Bad?

Leave a comment

The Agile Manifesto is quite clear about how much it values following a plan – not so much. Response to change gets the love instead.

Therein lies the marketer’s dilemma. CMO’s notoriously have a hot nut for project roadmaps – but Agile development teams often don’t welcome detailed plans – ooh, ick, they’re so Waterfally. So how do you assure your sort-of-Agile-not-really leader that you are executing on a marketing project plan that’s not being sequentially followed by the folks who are actually building the software?

Show him or her your backlog items.
It may be hard to get your C-level comfortable with a list of tasks that you have no guarantee will be done by the next sprint. You could add in the kanban, which is more of an operational aide than a executive presentation medium. But at least you can prove that you understand and have presented to the tech foks what needs to be done.

Demo the latest iteration of working software.
Sure – but beware of expectations. Marketing and Technology executives can define “working software” very differently. The apps dev team delivered a screen for the April 16th sprint release that slowly brings up week-old data from the dev server when you click the “submit” button. Server call performance will be addressed in a future sprint. The CTO: sprint mission accomplished. The CMO: my order history doesn’t come up – this thing doesn’t work.

Some advice – if the current iteration isn’t yet optimized for performance, don’t show it to the CMO. Sometime between pressing the “Let’s Get Started” button and the 112 seconds the app takes to complete the server call, you’ll lose trust. If the current iteration works with reasonable speed, but is missing some non-essential functionality, it probably won’t hurt to show the progress being made, with the proper caveats and disclaimers.

Pretend it’s still waterfall.
Show the wireframe of the screen in active development, and say “they’re working on this part now”. Hey, that worked for years.

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