This post stems from a conversation at http://www.codeproject.com/Insider.aspx?msg=5279002#xx5279002xx in which I suggested that we should come up with a new developer led methodology to frame IT projects. Of course, my remarks were somewhat tongue in cheek but they got me to thinking…
I have been in IT for over 25 years and have worked at every level from developer to managing large teams both onshore and off in both large and small organizations in several countries and have used most of the development methodologies that have been available to me during that time such as ESD, RAD, Extreme, Waterfall, Agile, etc., etc.
It feels like we have been striving for, but not quite achieving, the one perfect system that will both describe, document and guide the development process.
The problem is that without a slavish adherence to the principles of the chosen methodology, none of them really work and even with that adherence, I have seen projects collapse under the weight of the bureaucracy that has to be created to keep it on course. Entire industries have arisen to support the smoke and mirrors that we use to constrain our work.
I should point out that I have no particular axe to grind here; I’m simply articulating my experience and, hopefully, pointing us to a future methodology that will provide us with a workable framework for software development.
Which leads to why am I writing this now: simple, I am a long-time regular on Code Project and the subject of Agile is raised quite often and always leads to the inescapable conclusion that it a) does not appear to work and b) introduces yet another layer of management/techno-babble to an already overly burdened industry.
For me, there are parts of each methodology that work some of the time and other parts that don’t really work at all. My thrust here is not to say that we should take all of the good parts as we’d just end up with a curate’s egg of a methodology built upon the combined curate’s eggs of every other methodology.
Rather, I feel it’s time to let those that operate at the bleeding edge of software development design a framework for our industry that is both flexible enough to entertain systems of any size and projects of any duration but also does not rely on child like terminology to enable us to discuss the component parts that describe and document the process.
Some months ago, I was offered a position at a large financial organization as the “Scrum Master” (not quite the role I went to interview for – go figure). Apparently, it would be my role to evangelize the process and introduce it across all of the departments that would entertain it. I did think about it but realized I simply did not believe in the process 100% and, therefore, would not be able to approach the job with any enthusiasm.
And since then I have thought about Agile quite a bit. The organization I am at now uses Agile and employs daily standups, stories, epics, foo, bar, fluffy kittens and all.
It’s a fripperous nonsense that does not forward the process; instead introducing sticking points and road blocks that interrupt the flow. Yes, of course there are projects and fixes that fit neatly into a 2-week sprint or whatever duration you choose but there are just as many that, for any number of reasons, do not. So why would we try to shoehorn them into a process that forces a discipline that simply does not help?
We need a system that takes into account the complexity of the job that we do at the same time as allowing our overlords the ability to plan and budget. But it must be the development that is king in this deal, not the process itself.
So, what should that process be? That is the purpose of this paper; to elicit and encourage discussion amongst us. I expect flames, I invite them – they will lead to a better solution than that which drags us along now.
I will leave you with one last thought: I have yet to meet a developer who was demonstrably happy mired in agile; rather we all just seem to accept it as if there are no alternatives. Time was, I awoke every day fired up and ready to enjoy another day’s coding. Now I have to think about stand-ups and stories and artifacts and epics, etc.
Way to suck the soul out of development.
