DEV Community

loading...

Release cycles in agile projects

elmardott profile image Elmar Dott πŸ‡©πŸ‡ͺπŸ‡ͺπŸ‡ΊπŸ‡³πŸ‡ͺ ・2 min read

Agile project management techniques these days are not just common. They are essential for the software industry. In this context doesn’t matter if your project is driven by Scrum, Kanban or any other agile method. The main goal of a fast feedback for all of them is similar. It will help to reduce the risk of keep going whit something the client don’t want. This means the project have to delivered quit often - with a defined functionality set for the test and feedback cycle. In this way you are be able to detect problems very early, before a lot of time and money is wasted.

Here is a brief overview what it means agile release cycle and how it could work in practise. For example after a two weeks sprint the project need to delivered into a test stage. If some functionalities are not finished, the sprint will not extended. The missing implementation just got skipped for the next sprint. And of course every delivery is a full release, with his own release version. No build numbers are required. This fact is important to distinguish the artifacts and enable a well working bugfix process including a less complex branch strategy for your SCM system.

In between all those activities you have to aware that not every release have to push into production. It could be useful to plan every 3 or 6 months a well defined roll out. Huge and difficult functions moved to the beginning of such a cycle. Then will be enough time to complete and reach a good quality. Around two sprints before the cycle for a production roll out, is also a good time to review architecture and implementation details. This will secure maintainability for the future.

This process also implies a strong deploy pipeline, otherwise it could bind a lot of human resources. Manual activities are also error prone. This is why they should avoided. Following this simple conventions is also more important when you work with offshore teams. This requires an experienced project manager. A good recommendation to the product owner. If your project manager say something like: I am not a technical person. Kick him out. He will not understand basic problems and drive the project to fail.

Discussion

pic
Editor guide