Agile 10 years later: Dogma vs Doctrine

It seems like every few years a new software development methodology comes along. Frequently it’s a rehash of an old methodology, like object oriented programming’s rise (again) in the 90’s. Sometimes it’s a formalization of existing ideas and techniques, and sometimes it’s something completely new. Invariably the new toys excite a group of people who will promote them ad nauseam. Many of them become a flavor-of-the-month (or year) and then are never heard of again. Despite that, some of them end up being interesting and manage to survive their 15 minutes of fame.

The funny thing is that you can usually separate such ideas into two key components. One is the actual technology (ideas, tools, techniques, etc) and the other is the philosophy or religion. In other words, the “why” behind the whole thing. I prefer to think of it as religion because it tends to provoke the same kind of arguments and behavior as religious discussions and disagreements.

Agile development is a clear-cut case of such a problem. There are some wonderful, useful ideas embodied in the Agile Manifesto. If you apply them judiciously with an eye toward constant improvement and productivity, and where necessary take into account the evils of financial viability and mandated compliance overhead (such as aerospace, FDA, government, etc), you can start producing better software more quickly, and with less cost.

However when a group of people start doing Agile for Agile’s sake, you can have a disaster on your hands. I have witnessed this personally at some large companies where an Agile team had an interpretation of agile development that was at odds with the company’s needs.

I say interpretation of Agile, because different people have widely different opinions about the degree to which Agile alters their world. In one case a company building very specific hardware/software products has a very strong need to meet particular deadlines, and to deliver very specific features because they release a matched blend of hardware and software. In this company, the Agile team claimed that asking them to definitively schedule feature delivery was a ridiculous request. The team felt their company’s request was “ignorant” and beneath them. Not surprisingly, such an attitude doesn’t work well at companies who simply cannot have an agile release schedule.

For web-based organizations like Google or Amazon, the timing of feature delivery can be more or less whimsical. They can produce what they want, when they want.

On the other hand, companies building smartphones or heart-monitors face a very different reality. There are deadlines, requirements, scheduling, documentation, etc., all of which have to be met and coordinated.

The sad thing is that the dogma fueling the religious war (We can’t be expected to produce a schedule, we can’t write comments, etc) is counter-productive, which leads people to avoid Agile altogether, thereby depriving themselves of potential and probable productivity improvements.

In my experience Agile, like other methodologies before it, works best when followed in a contextual manner, mindful of product needs, organization (corporate) needs, and other issues surrounding the software in question. If you pick and choose the doctrines that can help your team and your product, you’ll be an Agile fan. If on the other hand you dogmatically adhere to “Full Agile,” without regard to the environment you’re in, you can cause project failure, put people out of work, and potentially kill a project or even a small company.

So Agile is 10 years old now. Should you use it? Will it make a difference? In my opinion if you separate the dogma from the doctrine you can definitely benefit. But beware the pitfalls. If you’re careless, you’ll waste time at best, and money, people and perhaps even more at worst. If you’re careful, the benefits from increase quality and productivity can be enormous.

Resources

Account Security and Gmail

Given the recent rash of web break-ins I thought it would be interesting to talk about personal security. Here are some steps you can take to keep yourself secure. The basics of course are simple things, IE use good passwords that are at least 8 characters, are combinations of upper and lowercase letters, contain special symbols and numbers. Make the password as long as the site will allow and you can reasonably remember.

Another simple basic is to not use the same password over and over again. For example, when Sony was hacked back in June, a lot of people had their usernames and passwords published on the internet. If you use the same name and password everywhere, it’s just a matter of time before someone hacks one of those sites and you’re compromised. Take the effort and do something unique for each site to keep yourself safe.

I was recently playing with Gmail, which I haven’t used much until lately. As I was setting up my account, I noticed they have a two-step authentication option. You should be able to see this on your settings page. If it’s not there, it’s probably because you’re using Google Apps and you need to talk to your domain administrator – it’s worth it.

So if you set this up, it basically does a phone text or voice message at the point when you try to login. For example, if I go to gmail.com and login, it will send a text message to my cell phone, and I get a unique code I need to login. I always have my phone, so it’s not inconvenient, and someone trying to get into my account needs to know my username, password, AND have my cellphone on them. At that point, I’ve got bigger problems.

Given the number of people who use gmail, this is probably something you can do yourself right now. Go ahead, give it a try. If you’re using other Google services, this can be critical. For example, the Foss Patents blog that I follow was shutdown because the author’s gmail was compromised. Using two-step authentication will help you avoid such problems.

What other simple tricks have you run into? Let me know.

Ranting about Software, Security and Tech