• The relationship between DevOps and agile can be readily observed by looking at the Agile Manifesto principles and DevOps best practices.
• DevOps can be used for any kind of software - not only cloud, but on-premise too.
• Using DevOps for early detection of vulnerability and open source license-related issues is a best practice you can apply.
• To make DevOps easier to use, try to provide one single glass of pane which provides a consolidated view to its users.
• Create your SAFe trains so they can deliver as independently from each other as possible, using DevOps to enable different delivery cycles.

There can be no agile software delivery without the right DevOps infrastructure. In this article, we would like to share our experience in our DevOps and agile transformation journey. We have a big and distributed team structure and we are delivering an on-premise software that makes the delivery different from cloud practices. We have been using many tools that are almost standard in the agile world. The challenge was bringing all the teams together in a pipeline for faster delivery. Our first release we managed to do in 3 years! After establishing SAFe, we were able to release in semi-regular intervals 3-4 times per year. And currently, we are laying the groundwork for even faster delivery, basically trying to do the “release-on-demand” defined by SAFe, delivering a feature as soon as it is ready to be delivered.

We managed to create 2 release trains so far, and are currently working on dividing it into more pieces to help enable faster delivery. This isn’t as easy as it sounds, because it’s not just about technically creating the trains and thinking about their domains, dependencies, etc. It is also about people and teams. The team members are used to working with each other and sometimes can show resistance to join other teams and work with different individuals. There is no silver bullet for this situation, only clear, transparent, and bi-directional communication can make things move.

Like other software development teams, we have been using many different tools for our DevOps. The fragmented DevOps landscape resulted in a lack of visibility and difficulty in dealing with problems. These problems were blocking us from releasing because we were observing the problems too late, and resolving them took time which delayed the delivery further.

Build Relationships and Network with a Global Developer Community. Attend QCon Plus (Nov 4-18) and Connect with Your Peers.

The main issues we dealt with in speeding up our delivery from a DevOps perspective were: testing (unit and integration), pipeline security check, licensing (open source and other), builds, static code analysis, and deployment of the current release version. For some of these problems we had the tools, for some, we didn’t and we had to integrate new tools.

Another issue was the lack of general visibility into the pipeline. We were unable to get a glimpse of what our DevOps status was, at any given moment. This was because we were using many tools for different purposes and there was no consolidated place where someone could take a look and see the complete status for a particular component or the broader project. Having distributed teams is always challenging getting them to come to the same understanding and visibility for the development status. We implemented a tool to enable a standard visibility into how each team was doing and how the SAFe train(s) were doing in general. This tool provided us with a good overview of the pipeline health.

The QA department has been working as the key-holder of the releases. Its responsibility is to check the releases against all bugs and not allow the version to be released if there are critical bugs. As standard as it sounds, this doesn’t follow the agile principles. We have been trying to “inspect quality in”, instead of building it in. This is why we followed DevOps principles to enable the teams to deliver quality in the first place as well as getting help from QA about expectations and automation to speed up many processes. This is taking time but the direction is clear and teams are constantly working toward it. When we analyze our release cycles, we can see where we spend the most time - it is on Staging, and this is what we are working on reducing.

Finally, we are enabling the release-on-demand concept in SAFe, because we want to release any feature, bug resolution, tweak as soon as it is ready if the Product Owner and the team say it can be released. This is a big paradigm change compared to the very long staging times for releasing a fixed scope, which was usually huge, where just to ensure everything worked required a long testing time.

#agile #safe #agile manifesto #software development #stories & case studies #culture & methods #devops #article