I need help to improve the release process

[samgville]

Hi everyone, I recently took a position as a CTO and I've been enjoying my time while improving the work the team has been making. My biggest struggle right now is how to better release features in production, the team doesn't have a standardized way of releasing features into production and the sales and marketing teams never find out when things are release. I tried to implement release notes but I'm still struggling with the releases because I never know what's ready to be released and what's still on QA process. I've asked the team for their help but I don't think they know what to do. Could someone point me towards the right direction of improving this process? Thanks!

[dglass]

Hard to say without know how your team cuts a new release, but my guess is you'll want to track all these changes in your project management software. How do tickets move through your system from planning -> analysis -> dev -> QA -> production?

Your release process should in theory only be picking up changes for tickets that have made it to QA and are tagged as QA or passed QA in your project management system.

[samgville → dglass]

Thanks for your help, this does make a lot of sense. Going to try to fix some stuff and then will reply to everyone who offered their advice.

[kernelmode]

Looks like you lack visibility on what's happening on a day-to-day basis. Try setting up a task tracking process, daily status meetings where everyone can look at the task board and report their progress. Set up a lightweight Kanban-like feature delivery process. This will give you tools to understand the development pace and some useful information for the release planning as well.

[samgville → kernelmode]

Thanks for your reply! We're already doing daily's and using the project management board but still not working for us. Any other ideas?

[durub → samgville]

Can you expand on "still not working for us"?

We had the same problem here. What we implemented is:

1. Have a separate step on the project management board describing "In Review" (QA) and "Deployed" (in production)

2. Interested parties (sales and marketing teams, for instance) should have "Observer" access in the ticketing system and follow relevant issues

Alternatively, you can ditch the Observer access and do the release notes based on what was "Deployed". If learning how to navigate the ticketing system generates friction for your interested parties, this can work better. Not an issue for us as everyone uses the same system to track their tasks.

[samgville → durub]

Thanks this makes a lot of sense. Going to try some things out and will let you know about the results.

[durub → samgville]

Glad to help! Feel free to shoot an email if you want to chat or throw ideas around about this or other issues you may be facing as a new CTO. The address is on my profile.