Agile Development in Real Life

First, let me be clear about one thing: I love Agile development. I ran a software company for 10+ years and we exclusively did Agile development. I have trained multiple teams on how to be Agile and love to talk about it. I absolutely don’t think that Agile is bullshit.

That said, I think that 90% of what’s grown up around Agile is total bullshit. Call it the Agile-verse. The Agile-verse includes all the Agile consultants, books, keynote speeches, events, conferences, agile software, and the endless list of Agile-centric processes that people keep inventing. It’s just too much. It’s even become fashionable to blog about the Agile bullshit carnival, or how Agile is a scam (irony mine).

So What’s Real About Agile Development?

The methodology of Agile, as described by the Agile manifesto, is real. The essential elements that comprise Agile are a profound paradigm shift from old-school development. An abridged version is below:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

These are valuable and meaningful statements, to say the least. The Agile manifesto, however, doesn’t tell us much about how to execute an Agile project, and that has left the door open for a whole lot of, well, crap.

Agile Is Different For Everyone

Having participated or observed hundreds of Agile projects, I’ve arrived at two truths:

1. There is no “right” way to do Agile. Each organization is unique and must adapt the nuts and bolts of an Agile process to their needs. Agile anticipates this type of flexibility.
2. Since there is no ‘right’ way to do it, just about anyone can call themselves “Agile” and start consulting or advising everyone else about how to do it right. There is no barrier to entry; everyone can be an expert.

When you combine these two points, it’s easy to see why a bullshit firehose has been unleashed on the software community.

So What’s Bullshit About Agile?

Simply put, most of the culture, articles, research, infographics, blog posts, reports, opinions, consultants, books, events, etc. surrounding Agile.

Be wary of these different shades of Agile brown (in no particular order):

1. There are many flavors of Agile development, but most of them taste about the same. Try searching Google for different types of Agile and you’ll find a convoluted mess of discussion about it. Ignore this — most of them are so similar that it won’t matter much for your organization. Just try to understand Agile concepts, and maybe scrum and kanban, and ignore the rest.
2. Agile doesn’t work for everyone. It’s not the end-all, be-all and it’s certainly not a good fit for many organizations. A big percentage of the bullshit comes from people who want to apply Agile to domains outside software, like Agile government, Agile marketing, or Agile education…or even silly mashups like Agile education marketing! Agile government? Please. I’m sure there are some valuable tidbits, but mostly this is a waste of time and should be ignored.
3. Agile consultants suck. Not all of them, but close. It’s a circus out there, and anyone can grab a scrummaster certification and repeating talking points for money. Over the years I’ve only met a few Agile consultants who really brought value, and none of them called themselves “Agile consultants.” Worse yet are the Agile consultants who feel compelled to blog about their tired insights. Ignore anyone who promises to teach you how to be more Agile.
4. Arguing over the best way to do Agile is a total waste of time. Once you have a process that is working for you, it’s not going to help you to dig into the big “what is true Agile” debate. It’s Agile enough if it’s bringing productivity or quality gains to your team. Ignore these esoteric and useless debates. Resist the urge to find that perfect path to Agile bliss and forge your own path.

That all said, there are great Agile-related resources out there. I spend much of my days looking at Pivotal Tracker and Jira or reading articles by the great Martin Fowler. I’ll put more of these together into a future blog post.

Pragmatic, Real-World Agile

If you take care to remain reasonably true to the Agile manifesto while ignoring the other 90% you should be just fine. It doesn’t matter if you are more on the kanban side or the scrum side, or if you have a quasi-Agile approach with a few necessary Waterfall elements. If you are applying Agile concepts to your organization and seeing value, you’re doing it right. Make no apologies.