Selection criteria for team members in the DevOps organization
In the previous part of this blog you read about how to source your DevOps teams when you aim to deliver your software products faster. Further, you will read about the criteria of selection for team members in the DevOps organization.
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. This curriculum is offered by our Capgemini Academy.
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/