Agile Development isn’t a Silver Bullet

Buzzwords are the worst. The absolute worst. They seem to be something that some higher up read about and decided to preach to his or her employees. Inevitably the buzzwords will end up on job requirements (even if the job has nothing to do with that buzzword) or talked about endlessly during job proposals and interviews. Honestly, it’s a huge red flag if someone repeats a certain methodology, process, or philosophy without justifying the context. “Agile” is just one such buzzword that seems to be really misunderstood and misapplied.

When Agile Becomes a Burden

What is this “Agile” thing? Supposedly its a software development methodology designed to react to a faster paced and rapidly changing form of software construction. Perhaps your requirements are in flux, or your customers don’t really know what they want until they see something in development, or you’re just really interested in that “scrum” word you keep hearing about on various tech blogs. Regardless, you really want in on that sweet, sweet Agile action.

You hire some scrum masters, software engineers (remote is OK), QA engineers, technical writers, and business analysts. You setup a scrum board. You preach the tales of development sprints, user stories, and research spikes. You do all the things that you learned during your 2-day Agile bootcamp in Silicon Valley. Oh man, you’re on a roll you think to yourself. There’s no way a project can fail if I know of all the problems in our daily standups!

Over time, some cracks start to appear in your process. Why are we revisiting a piece of code from three sprints ago? What do you mean you didn’t put in proper error handling and documentation? You had to meet your sprint deadline (which includes development + deployments + QA + code review + documentation + user acceptance). There’s no time for “clean code” and algorithms that “make sense.” Just get that stuff checked in and commit to your next sprint, damn it!

Maybe it’s a cultural thing. Maybe it isn’t the Agile process at fault here. Maybe you’re just misusing it.

Knowing Your Gaps

Agile is a process with many faces. There are a ton of variations, all or none of which may apply to whatever project you have on hand. The lesson here is that you shouldn’t mass apply any one Agile methodology to your project without careful consideration of what the project is, what the project’s goals are, and how the people on the project like to work. Take some time to analyze these facets and build a process around your projects, cultures, and environments.

Just because some other organization saw a billion percent increased revenue after adopting the most recent buzzwords doesn’t mean that the exact same process will yield the exact same results for you.

Look inward before you put that buzzword on your job requirements.