User Tag List

Thanks Thanks:  0
Likes Likes:  0
Dislikes Dislikes:  0
Results 1 to 2 of 2
  1. #1
    Join Date
    Feb 2008
    Hong Kong
    Post Thanks / Like
    0 Post(s)
    0 Thread(s)
    Total Downloaded

    Release Cycle vs on-demand

    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?
    ISTQB Certified Test Manager & Test Analyst, Certified SCRUM Master, Chartered Financial Analyst (CFA) Charterholder, GARP Certified Financial Risk Manager, IBM Certified RUP Specialist, ClearCase Administrator, WebSphere Deployment Professional, DB2 Administrator

  2. #2
    Join Date
    Nov 2011
    Post Thanks / Like
    0 Post(s)
    1 Thread(s)
    Total Downloaded
    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.



Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
Search Engine Optimisation provided by DragonByte SEO v2.0.36 (Pro) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
Resources saved on this page: MySQL 11.11%
vBulletin Optimisation provided by vB Optimise v2.6.4 (Pro) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
User Alert System provided by Advanced User Tagging v3.2.8 (Pro) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
vBNominate (Lite) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
Feedback Buttons provided by Advanced Post Thanks / Like (Pro) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
Username Changing provided by Username Change (Free) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
BetaSoft Inc.
Digital Point modules: Sphinx-based search
All times are GMT -8. The time now is 06:38 AM.

Copyright BetaSoft Inc.