No, it’s not the end of Agile for LIMS but the reasons why aren’t necessarily positive ones.
The End of Agile?
First of all, I was just reading an article on the potential “end of Agile” which has good points. For anyone interested in reading it, here is “The End of Agile.”
The End of Agile for LIMS, ELN, LES or LIS?
Years ago, we read articles that claimed that the Waterfall methodology was dead. After many years, it’s still not dead. People are still using it. If it was dead, it wouldn’t still be around. And, regardless what anyone says, many people are using the Waterfall methodology but they just don’t call it that because they’re afraid the rest of us would call them uncool.
But, in and of itself, there’s nothing wrong with the Waterfall methodology and, if it works for you, then it’s a good methodology.
The Secrets of Methodologies
The secret of using any methodology is that it requires two major truths:
- It’s appropriate to your situation.
- You can make it work for your situation.
If you don’t have those two elements then any methodology is a bad one for your purposes.
Back to Agile
As I’ve many times mentioned, we continue to hear of Agile projects with sprints that produce nothing, sprint after sprint. Agile isn’t the problem. The problem is the application, the people using it, or both.
And, as I’ve also said, before, Agile might be the latest and greatest software implementation methodology buzzword but it doesn’t mean it actually applies to your situation nor that you can properly make it work.
And there are many people who claim that almost no-one is actually using Agile. There are many claims that everyone wants to claim to use Agile but who will then admit that what they’re using is really “modified” Agile. In addition, the claims are that most “modified” Agile applications are extremely removed from being Agile. They’re so much removed that they’re Agile in name only.
Why We Do This?
So, why is it that we insist on using or not using certain methodology titles? Why do projects insist on using the word “Agile” when that’s not what they’re doing? Why do they insist on NOT using the term “Waterfall” even if that’s correct? Here are a few reasons:
- They’re afraid to either admit they’re not using the “latest and greatest” or admit what it is they truly are doing. They’ve let all the hype make them insecure.
- They don’t understand what the methodology choices are all about. Once, again, they hear all the hype and select something that’s just based on that hype, not actual understanding of the choices.
Basically, all of this is a kind of denial. People want to use Agile and be successful so they just claim that’s what they’re doing, even when their sprints show hard facts to the contrary.
I Don’t Wish For the End of Agile for LIMS
To me, I’m not interested in the end of Agile for LIMS, ELN, LES, LIS or any other product. I’m not that invested in using any particular methodology. If a customer can properly use Agile and be successful with it, I’m happy to work with that.
But what does bother me is that we use methodologies as excuses for failed projects. As projects continue to fail, we cannot then just jump on the next new thing and claim that’s going to solve our problems. It rarely does. Project issues are complex and usually not solved without careful work.
On the other hand, if we admit to failure, does that mean we get fired? Does it mean we don’t get promoted? Believe me, I see first-hand why so many people look to their methodology as a scapegoat for project failure.
Project Management’s Coming of Age in our Industry
I remember being one of few people who thought systems such as the LabWare LIMS needed project management and software lifecycle management. After all these years of purshing for all of this, it’s why I call myself a LabWare LIMS Expert and can keep a straight face about it. These days, I’m just one of the many, fortunately.
In addition, we’ve seen many more PMPs, PMOs, and run into more people taking college courses in project management. More people take project management seriously, today, than years ago, of course. We’ve progressed quite significantly.
Yet, in our understanding of issues such as methodologies, we still see plenty of projects that fail. Or, we see projects that are so glacial that they’re only barely able to escape the label of “failure.” That will remain the case for anyone who still insists on grabbing at whatever the flavor of the day fixes seem to be rather than looking for root cause.
So, for those of you who can’t understand why, sprint after sprint, you still can’t get anything done – if you now still don’t have an inkling why, then you’re doomed to keep repeating that failure.