A Marketer’s Guide to Agile Development – A Rose By Any Other Name…

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 – Does Agile Have Time for Research?

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.”