Agile software development introduced principles like continuous testing, continuous integration, testing during the sprint, automated whitebox developer testing and striving for testable code as a primary concern. The inspiration behind all this was to support more recurrent deployments and more rapid change. This resulted in baking the concerns of testability into code and boosting the probability of shippable pieces at the end of every sprint by augmenting the quality earlier. This approach turned out to be a success and these practices are quite prevalent now.
Agile couldn’t say much about downstream concerns like putting an SDLC around infrastructure and configuration, improving and automating deployments, testing operability and infrastructure concerns earlier in the process and baking concerns of operability into the software. The consequence of this is that many teams of development can deploy regularly to a lower test environment. However, they are still trapped to bring it at front because they cannot garner enough confidence that they can securely deploy a reliable piece of software.
In a mature environment of DevOps Consulting, one would aspire to move towards cross functional teams who are completely responsible for testing, deploying, running and developing their own code. Some people call it ‘You Build It, You Run It’, the greatly publicized Netflix and Amazon way of working. For this way, one is required to bring skills of operations into the teams. Such skills include deployment, scripting, middleware, DBAs, sys-admin and even network skills. As each of these skills enters into the team, the team’s autonomy enhances.
It involves organizational reorganization like changes to budgeting lines, reporting lines, etc. These are tough, though can be toned down in multiple ways.
You need to increase headcount as you diminish the size of these shared service teams and shift some people into teams focused more on product.
You need to alter the operating model and the processes of the organization.
DevOps teams are responsible for creating and managing test tooling and development building. The teams possess these tools and the path to production and then have the consent to assist the product aligned teams onboard onto the tools and utilize them efficiently to quickly ship their code.
It is crucial that the DevOps team does not become a bottleneck and work on behalf of teams. Efficient teams do not work for people; they assist them in doing their own work. And since the delivery teams are empowered with operations and deployment, they are pretty much prepared to utilize the optimized path to production which the DevOps team is creating for them.