Recently joined an interesting organization, where we used to be implementing on-demand releases, meaning if the user request a certain feature, they go directly to developer and ask them to make the fix, release to UAT, then to production. The problem is that we have around 30 SOA components and there is often a long release queue to work with, some not all features turned over really fast.
I am asking them to do a release cycle, so every developer get to release their product every 2 weeks. Most developers didn't like this idea, and think this is blocking them from delivering their work. On the other hand, support likes it, helping them to plan ahead what to work on each day in terms of release and support.
Have on-demand releases worked for you before? Any suggestions on how to make the release cycle more welcomed by the developers?
I've been in a hybrid system where some releases were scheduled and others were on-demand - the major releases (desktop application suite with associated web application) would be scheduled, and patches would be done on-demand. In addition, the target features for the major releases were largely customer-driven.
I'm currently in a situation where the web application releases are for the most part on-demand (very mature web application built in classic ASP) with large changes scheduled. The PC application releases are somewhere between scheduled and on-demand (again, very mature if elderly application with few large changes).
As I understand it, your basic problem is a "clumpy" process: you have bottlenecks rather than a smooth flow of changes through the system.
I'm guessing at least part of the developer resistance to your suggestion is inertia: they've always done it this way. I'd suspect there are other reasons that possibly they can't articulate because typically they are so deeply embedded in their own area of expertise they can lose sight of the wider business needs.
I'd suggest that you hold off on any changes for now. Instead, look at documenting the entire process from the arrival of a customer request through delivery. Then ask your developers and other involved parties what they see as the pain points in the process. You say that you started at this organization recently, which means you don't have the experience with the organization process that others who have been there for a long time do: if they trust you, your developers will be able to tell you about any failed initiatives (this is often a reason for resistance - when every attempt at doing something has failed, those who remember those attempts will be reluctant to try again). They will also be able to tell you about the real process - which might not be the same as any documented process (I've been down this road - people want to do a good job, and when something blocks them that doesn't seem resolvable through official channels they will quietly route around the blockage. This can lead to the actual process bearing no resemblance to the official process. If you see this, you can guarantee that the official process failed at some point but was left in place due to a lack of responsiveness from management).
Your goal from what I can see isn't necessarily to *change* how releases are handled. It's to smooth out the process so the backlog is ticking over continuously and you don't have some people overloaded while others are looking for something to do.
If a major change to your release process is needed to do that, it's better for you to guide your developers to this discovery for themselves than for you to impose it on them.