Here's the thing about methodology magpies: there's nothing special about a method for systems development. As Betty Dorsey said back in the 1980s, "A methodology is a way of thinking, not a substitute for thinking." Skipping over some disagreement about the initial term, I would expand on that to assert that as long as you're thinking, you're probably headed in the right direction.
It's when you abdicate thinking in favor of blind adherence to process that the trouble begins. Hence my own creation, the Belgian Gambit.
FYI, the magpie epithet comes from my experience that methodological mendicants tend to chase the latest trend, accumulating certifications as they go, assuring you that whatever you're doing, you're doing it wrong and they alone can lead you into the promised land. For a fee, of course.
I tend to regard the modernization mayflies similarly; whatever technologies you're using, regardless of how suited to task, and certainly if you're using anything mainframe, they're the wrong technologies and you should use the patented mayfly mechanism to automatically convert to the right technologies and then all will be well with the world. For a fee, of course.
Now, I've had a go at the mayflies, but it's worth re-asserting that they represent the second kind of fool, always barnacled to the Next Big Thing(tm) and whose primary skill is blinding you with the rosy scenarios of their artfully crafted presentation graphics.
Stop being taken in by consultants claiming to know the one true path to enlightenment and prosperity and so on and so forth ad infinitum and frequently ad nauseam. For a fee of course.
I'm aware I'm being unkind here, but where literally decades of reason have failed perhaps outrage and insult will prevail and, among other benefits, we can consign the Most Bloody Awful degree to the outhouse fire of history.
Management's greatest trick was convincing itself that assembly line techniques are appropriate in all cases. (Apologies to Charles Baudelaire)
Feel free to attend the mandatory manager's training, and the off-site retreats and getaways and seminars where the suits commiserate and wonder who will rid them of these turbulent developers. For a fee, of course.
I spent decades trying to keep management informed, to be the one keeping an eye on their blind spots, to manage upwards. Success was limited, but I learned a few things along the way.
Here's some of it, for free:
- Process is not a substitute for good people, good people will get the job done regardless of process so get out of their way.
- Sometimes the greatest barriers to success are our own procedures. Don't be that manager.
- Good technical people can't not solve problems, it's how they're wired. Great success results from giving them a problem and getting out of their way.
- Compensate your people fairly, or they'll go somewhere that does. Provide a training budget as part of the compensation package.
- Cargo-cult computing doesn't work, stop trying to imitate what successful IT shops do whilst ignoring why they're successful.
- Certainly analysis, and most often development, are creative endeavors, marked by inspiration; don't try using an assembly line to create art.
- There is no silver bullet, stop paying magpies and mayflies for snake oil.
- Read1 a2 damn3 book4 once5 in6 a7 while8.
- Don't mistake stability for stagnation, activity for progress, or change for innovation.
- Santayana was right.
Thus endeth the lesson.
1 Software failure: Management Failure, ISBN 0-471-95113-7
2 Software Runaways, ISBN 0-13-673443-X
3 Great Software Debates, ISBN 0-471-67523-7
4 Computer-Related Risks, ISBN 0-201-55805-X
5 Computing Calamities, ISBN 0-13-082862-9
6 Facts and Fallacies of Software Engineering, ISBN 0-321-11742-5
7 The Deadline, ISBN 0-932633-39-0
8 Why Does Software Cost So Much?, ISBN 0-932633-34-X