Your aim to deliver your software products faster requires you to adopt DevOps. Read on to learn how this impacts your teams and your team sourcing.
When your organization is to adopt DevOps to improve your business agility, you need to consider how this impacts your software development and IT operations departments. If you aim to automate your software products’ deployment, you need to break-down the silos between them and rethink your software development organization. This will not only impact your organization structure and culture, but also your approach for sourcing the team members in this organization. In this blog I will talk about the impact on the organization and the sourcing approach for your teams.
What is the relation between Agile and DevOps again?
Agile software development is the method for software development where the software requirements as well as the software application itself evolve through the joint effort of self-organizing and multifunctional teams and their customers end user(s). The approach advocates adaptive planning, evolutionary development, empirical knowledge and continuous improvement. The approach supports a quick and flexible response to changes in software requirements in response to changes in the needs of their customers/end users.
DevOps is a philosophy, a cultural shift that merges IT operations with development, security and QA and demands a linked toolchain of technologies and processes to facilitate collaborative change. Its intent is continuous and secure delivery, continuous improvement, automation, rapid functional release, and downtime minimization to enable business speed, agility, adaptability, predictability and competitive advantage.
Agile software development has a focus on the cooperation between the business organization and the software development organization to create a qualitatively validated software application that meets the expectations of your organization and end users. In an agile organization the software application is the product of the collaboration. However, this final product is traditionally set up by the IT operation on the IT infrastructure in a separate process to make it available to the end users.
DevOps builds on Agile and adds the integration of software development and IT operations to further improve the maneuverability of the business organization, and the speed with which the evolving software application is made available to the end user(s); required activities are automated wherever possible.
Activities that can be considered for automation to establish the Continuous Delivery Pipeline include:
- Continuous development, the practice of automatically generating the source code of the software leveraging functional and technical specifications.
- Continuous integration, where the source code is automatically built into an installable software product.
- Continuous deployment, where the software product is automatically installed and configured for testing or use.
- Continuous provisioning, in which the IT infrastructure components, on which the software product is installed or integrates, are automatically rolled out, set up and configured.
- Continuous testing, which takes care of the automated execution of technical, functional and integration test scenarios.
- Continuous monitoring, in which all activities of the team and the availability and condition of the deployed software product are continually monitored, including automated alerting and, if possible, automated mitigation of issues in the event of incidents.
The automation of activities not only achieves acceleration. The automation also contributes to the quality of the result of these activities, because the automated actions are traceable and repeatable across software development and IT operations. Long term, this automation also contributes to keeping quality and costs of operations and maintenance under control.
However, the integration of software development and IT operations with DevOps implies the software development activities and the ITIL management processes are facilitated by one organizational entity. This integration sets constraints for contracting software development and IT operation and infrastructure.
The enterprise scale DevOps software development organization
SAFe, the Scaled Agile Framework, is currently the leading organization framework worldwide for the organization of an enterprise scaled software development organization, which integrates Agile and DevOps, and provides governance through portfolio planning and program management. The figure below gives an overview of the SAFe framework as well as the distinct positions of Agile and DevOps within this framework.
In the SAFe framework, the DevOps activities are positioned at the program level and executed and set up by the Systems team under the leadership of the Release Train Engineer (RTE). This team takes ownership of the components which constitute the Continuous Delivery Pipeline and is responsible for the operation of the pipeline across all teams in the organization.
In SAFe the components of the pipeline are called in SAFe Infrastructure Enablers. The focus area of this team is primarily the automated setup of the program’s middleware and the integration of the middleware components with the infrastructure. Although this setup and configuration is done through software automation, the knowledge required for this is strongly IT infrastructure oriented and includes topics such as network configuration and routing, server installation and configuration, database server management, backup, failover, restore, infrastructure monitoring. In situations where the hosting infrastructure is outsourced to a third external party, for example your cloud provider, the team often acts as an intermediary between the development teams and the hosting party.
For the construction of the Enablers, the team has its own backlog with its own epics and user stories, and they use an agile approach to get things done. As soon as Enablers are constructed, they are made available to all teams at the team level. By organizing these activities through a dedicated team, a consistent approach for the Agile Release Train within the program is assured and the required knowledge, skills and experience are bundled in one team. This team also facilitates the deployment of the Enablers to the Dev teams. This approach guarantees an effective and efficient design of the Agile Release Train for all Dev teams to benefit.
In the SAFe framework, the agile activities are positioned at the team level. The Dev teams use the Infrastructure Enablers to automate work. Because the Enablers are provided and only need to be put into use, the Dev teams can continue to focus its attention on collecting the software requirements and building the software application. The Enablers contribute to the acceleration of the Dev teams and the improvement of the quality provided by the DevOps Enablers, without the necessary, in-depth IT infrastructure and operations expertise being embedded in every team in the program.
Although the Enablers provide support for some of the DevOps aspects, each team will also have to take responsibility for several ITIL processes in the areas of Service Transition and Service Operations in close cooperation and coordination with the System team. Topics such as Change Management, Release and Deployment Management, Service Validation and Testing, Incident Management, Problem Management, Application Management, and Technical Management need to be taken into consideration. By embedding these processes in the teams, the teams will also take responsibility for the operational issues of the users of the production environment.
This is how the typical infinity symbol for DevOps is established, through continuous feedback from the users, and application and system monitoring, enabling the teams to adjust their daily activities and plan for the next release.
Selection criteria of for team members in the DevOps organisation
Given the foregoing argument, it is obvious knowledge of and experience with Agile and the underlying principles are basic requirements when selecting candidates for a role in the software development organization. For working in a software development organization, whose setup is based on the SAFe framework, this basic requirement can be supplemented by a role-specific training from the SAFe Role-Based Curriculum.
Dev team
The members of the Dev teams must have knowledge and experience which is appropriate for their specific role in the team, such as business analyst / requirements engineer, software developer, tester, scrum master, product owner; with potentially a few roles assigned to one team member. It is also highly desirable that team members have knowledge and experience with the concepts that are part of the Continuous Delivery Pipeline. This conceptual knowledge could ideally be supplemented with knowledge and experience with the pipeline tooling, as selected and set up for the program by the System team; this is however optional. Knowledge and experience with the ITIL processes delegated to the team is desirable. Which ITIL processes depends on the agreements that have been within your software development organization between the System team and the Dev teams.
System team
For the System team, all required expertise and experience must be present in the team for the design of the components of the Continuous Delivery Pipeline and the target IT infrastructure platform. In practice, a team member will be an expert one or more components of the tooling used for the construction of the Release Train. The knowledge and experience of the team is supplemented by the team members who provide the necessary IT infrastructure and operations knowledge. A must have requirements is all team members must be able to express all required setup and configuration tasks through software code. This skill is a prerequisite which enables the extensive automation of work within the software development organization.
Team building and collaboration
If you enter into an agreement for the delivery of software development teams with your supplier, agreements are made about the size and composition of the team, the required skills and experience of the team members, and the expected duration of the deployment of the team. In the situation where you add members of your organization to the team, the mutual expectations regarding the skills and experience of these employees should be part of the agreement. A guiding principle for System and Dev teams is the team is multidisciplinary and autonomous within the constraints set by the software development organization and able to bring the team’s mission to a successful result. This approach ensures there is a joint view on the team structure and mission.
Subsequently, all team members, including the members provided by your supplier, should be jointly trained in the agile, DevOps approach that will be used by the team. The aim is to establish the team as a team and the team’s view of the agile approach to be used. The frameworks specifically set by your software development organization are included. During the training the team members establishes team agreements on, for example, responsibilities, the Definition of Ready and the Definition of Done.
The EduScrum[1] method can be used as a training method. This method lends itself specifically to adjust the content of the training to the actual needs and experience of the team members. Because Scrum provides the basis for the work form, the team members will have to decide for themselves how they achieve the learning objectives. This approach directly contributes to team building. If necessary, an Agile coach can be assigned to the team. This is the case when not all team members have experience with Agile and/or DevOps.
Anticipate changes in approach and teams
As described in the previous section, the training for the teams is tailored to the frameworks set by your software development organization. Your working method is also reflected in these frameworks. In an agile / DevOps working environment there is continuous attention for improvement and should include experiments to adjust the approach. It is therefore unavoidable the approach to get things done within your development organization will change over time. This change will have to be incorporated in the training of new teams.
Another change that you need to be anticipated, although undesirable but unavoidable, is members will leave a team at some point. If this is a leading member in the team with a long track record, a replacement will not be easy. In this situation it is advisable to ask your team how they want to handle the change. The team can, after proper consultation, take the decision to redistribute the work and responsibilities of the departing colleague within the team. This allows team members to grow professionally within the team, which contributes to the retention of team members. Once this is done, there may still be a need for a new team member. However, this team member does not have to exactly match the outgoing member in terms of knowledge and experience profile. In many cases a profile with less experience will suffice.
Respect the technological complexity
When transitioning to a DevOps software delivery approach your instinctive reaction may be to source team members with square profiles; the multi-specialists who are both an expert in software development and IT infrastructure and operations. Although, this profile looks ideal, they are likely to cost so much in development and training, that it becomes too hard for them to stay up to date with all the skill sets you are expecting. My advice to you is to respect the technological complexity of your software and infrastructure and acknowledge this complexity requires your software development organization and teams to have a deep understanding of all aspects of full software lifecycle. Looking at your approach for team sourcing this respect must imply your organization acknowledges distinct profiles for Dev Team members and System Team members. However, all teams have in common they need to adopt some of the trades which were in the other silo before the transition.
If after reading this blog you still have questions on how to address team sourcing in your specific situation and context, feel free to reach out to me to discuss your challenges.
[1] Ref: https://www.capgemini.com/2019/02/eduscrum-the-next-revolution-to-training/