Consider for a moment, if you will, the delicate balance between robust, thoroughly quality assured code and the amount of time it takes to put that code into production. I ran hard into the brick wall of 'development process' this week - an obstacle numerous people in our business had been complaining about, but I'm not sure how many people on the IT side of our organization understood.
My story went like this. We have some feedback from one of our applications that gets displayed in another in office application that was getting truncated. This truncated information was deemed valuable by the SME's and so a fix was requested. I looked into the fix, and it turned out to be a one character change in a cold fusion file. Getting this change implemented in production would not even require a server restart. After getting the changed entered in our bug ticket system and socializing the change with the appropriate stakeholders, it seems that our development process requires that I wait a full month before my change is actually implemented in production... and we're (supposedly) an Agile shop. What (on earth) is wrong with this picture?
This isn't the first time the organization has run into this issue. There have been other similar issues in the past - an email address needed to be changed. Could you please wait 2 weeks? If fact, this has turned into a major issue with upper level management (read execs), to the point that an entire system rewrite is being considered using a totally different technology with the main purpose being to cut in half (or more) the time it takes to get from requirements to production.
Personally, I do not think that the business and management is going to find their silver bullet in implementing a different technology for development. I think the problem lies in our development process being too rigid. 'We have one release a month - your changes go in that release and if you miss getting your change in by the code complete date, too bad'. Different technology will expose other problems. For example, a lack of appropriate hooks (or a complete absence thereof) for proper unit testing. Or, an inability to version and automate the configuration and deployment of the new technology stack.
Save a few million bucks on 'new technology' (it would really only be new to the company). Seems to me that it wouldn't be that difficult to set up a small, very part time team of a senior developer, a senior qa analyst, a senior ba, and an rm dude to assess these 'changes' that don't fit into agile's bug definition, but should be made in production quickly. If the change is deemed relatively innocuous by the team, put on your cowboy hat's and let's have five minutes of fun. Maybe that's going a bit too far - you want to capture the change in your build system. Communicate the risk to your client (very likely the same person or close to them) whose asking for the change, and then make them happy.
Please, don't make them wait a month for their change.
No comments:
Post a Comment