Agile and Other Methodologies: Fads or Otherwise

Yesterday, I received a newsletter I subscribe to that had two opposing articles regarding whether or not Agile methodology is a fad or not. I thought both the pro and con article were worth passing along to those of you who are interested in Agile or any other methodology because they made good points that are relevant. Also, I’ll comment on methodologies, in general. By “methodology” I’m talking about software development/implementation stratagies for laboratory informatics projects, especially LIMS and ELN.

The Articles
It’s a fad:           http://www.batimes.com/kupe-kupersmith/agile-is-a-fad.html
It’s not a fad:     http://www.batimes.com/robert-galen/kupe-agile-is-not-a-fad.html

Using a Methodology for a Customer or a COTS (Commercial Off-The-Shelf) System
When you create your own system, you need a software development methodology. When you implement a COTS system, you might also need a methodology. Most new customers to our industry don’t seem to realize that “COTS <> No Programming.” If there’s programming, you need a methodology. Regardless what anyone says about how you “can” do little programming to implement a system, the reality is that any system that can be programmed ends up with enough programming to need some amount of management to it.

The answer to this is to select a methodology that fits your situation. Anyone that gives you a standard methodology, a one-size-fits-all solution, is potentially helping you to failure. There is no methodology that works for every size or project and every situation. That is why, even in these days when quite a few companies are interested in the Agile technology that some say they’re using “modified Agile.” This is because Agile isn’t appropriate for every situation.

Modifying a Methodology: Don’t Do It!
The problem is that you need an expert who can modify a methodology. Too many times, someone will modify a methodology because it appears inconvenient, but in their lack of understanding of managing software and implementation projects, they “take the teeth out of the tiger” leaving their project with a methodology that still won’t take them to success. Thus, what I really mean is that you shouldn’t modify it unless you really know what you’re doing and, truly, there are too many people that think it looks easy and do it, anyway.

These days, I hesitate to use a named methodology. For example, and this is a common situation for me, but a potential customer asked me what methodology I’d use for their project. I told them that I don’t have a set methodology – that I look at a customer’s situation and sometimes will go along with a customer’s methodology if it’s standard to their company and seems appropriate. Instead, I ended up describing some of what I thought they’d need based on what they told me about their project.

Think of this another way: do you have a hobby or something you’re truly an expert in? Have you ever told someone new to it how to do it? You tell them the strict steps to follow but you happen to know there are places you can modify because you’ve done it so often. Thus, as an expert, you know where to adjust things. Methodologies are just like this – those who don’t have experience don’t know which parts are applicable and important and are prone to disaster if they change things. Unlike a hobby, we’re often talking about projects worth hundreds of thousands or millions of dollars. We can’t afford to play around with them.

As an example, too often over the years, I’ve heard people talk against Waterfall and for Prototyping, while understanding neither, and ending up with a failed project or one that is a nightmare to maintain for the long-term.

Finally
Project managers promote “lessons learned” which is a way to learn from each other, meaning that no-one is a novice because there’s a huge body of experience out there if you’re willing to tap into it. Take this seriously. Learn from the experience of others and your project is more likely to succeed. Of course, lots of people claim to be experts in this, so it’s not always easy to find the right advice but, once again, anyone that claims one methodology is the solution to every project doesn’t understand methodologies enough to call themselves an expert in anything but their narrow silo.

Gloria Metrick
GeoMetrick Enterprises
http://www.GeoMetrick.com/