1. Home
2. Blog
3. SAFe. Continous Delivery Pipeline

At this point we can we can already highlight the fact that the core target of all the configurations provided by SAFe is to create highly efficient factories with real production pipelines delivering a sustainable and continuous flow of value with the best economic output, in the shortest lead time with a constant attention for eliminating wastes and delays.

 

This is best visible if we look at the Program configuration where the Agile Release Train is organized exactly around the idea of implementing the Continuous Delivery Pipeline concept with its four sub-processes:

 

• Continuous Exploration
• Continuous Integration
• Continuous deployment
• Release on Demand

 

The Continuous Exploration element is mainly driven by the PMs who are collaborating with the customers to gather their needs, are looking at market and trade studies and other sources of information. They are also collaborating with the architects in order to define the best technical solution for implementing those needs and are synthesizing all this work into the Vision, the Roadmap and the prioritized list of Features to be implemented by the teams in the trains.

 

The Continuous Integration process is the work done by the teams in order to split the Features into User Stories, implement those stories, integrate continuously every vertical slice of new functionality, test it and also integrate it with the work of all the other teams in order to re-aggregate the Stories into Features. A this point the PMs can validate the initial assumptions. A huge contribution is brought by the automation of running test suites on staging environments emulating production.

 

Related to Continuous Deployment, SAFe takes a different approach from the previous common understanding which, shortly put, meant that you should deliver to production continuously no matter if either you or the clients like it or not, or are prepared for this. In SAFe the deployment is completely separated from the release.

 

Continuous Deployment is the process which handles the validation of the new system increment on environments which are a 100%, if possible, similar to the actual production environments. These deployment environments can be in some instances exactly the production environments but this doesn’t mean that the new deployed features are available immediately for real usage.

 

The new Features are validated on these environments on their own, in conjunction with the rest of the new added things and checking that they don’t break older functionality as well. If the deployment happens on real production environments there are techniques like “feature toggles”, “canary releases” and “dark launches” which “hide” the new functionality from the vast majority of users while allowing for testing in the real world but under controlled conditions.

 

Working on very complex systems means that releasing is in fact sometimes a step which requires a visible amount of work to be performed like building the package, updating the documentation, training the users, getting approvals for aspects like compliance and so on. This means that continuous delivery is not achievable in most of the cases.

 

Every organization, however, must be capable to trigger the release process when the request comes. So modeling the “Release on demand” sub-process is a must have for all organizations and all the previous three sub-elements should support this capability and make it as smooth and efficient as possible.

 

One of the main goals of every SAFe Program should be the complete automation of the Continuous Delivery Pipeline related to every aspect, from integration and testing to environment provisioning and deployment.

 

 

Release Train Engineer and Scrum Master role in SAFe

There is a long discussion about the role of the Scrum Masters in Agile. All of the responsibilities, characteristics and functions are valid in SAFe as well. And because an Agile team is almost never independent, in SAFe this is even more obvious. A team should be capable of working autonomously most of the time, but constantly having in mind the dependencies with the other teams in the train.

 

So the function and responsibilities of the SM have connections extending outwards to almost every other role, ceremony and process in SAFe. And because someone needs to make sure that the train “mechanisms” are working at the highest capacity a new role has been defined specifically for doing the Scrum Master work but at the level of the Program. This role is the Release Train Engineer acting as the Chief SM for the whole train handling the processes of the Program. This guy is the main point of escalation for the SMs of every team, is a master facilitator for the ceremonies at the program level, helps with removing the impediments for the whole train, acts as a SAFe coach and so on.