DevOps Pipeline Health Check for world-leading manufacturer

The Project

Over their many years of business, the client had expanded globally: most notably in the Chinese market where they currently have 28 offices. They had worked with many other organisations to increase their system capabilities but needed an impartial consultant to define DevOps best practices, find opportunities for optimisation, and create a prioritised roadmap for implementation.

What we did

As part of Ten10’s Cloud & DevOps services, we executed a DevOps Pipeline Health Check assessing three main pillars:

1. Backlog Management
2. Development Practices
3. Operation Management

From this assessment, optimisation opportunities were found for Backlog Management and Development Practices.

Backlog Management

Previous way of working

We held a series of workshops with members of the client’s team to better understand how different areas of the business operated together. The first process explored was Backlog Management, concerning the ideation, creation, refinement, estimation and maintenance of the work items. The client’s existing process was as visualised below (Figure 1).

Several areas for improvement were identified, as although there was a technical debt backlog created by the engineering team, there was no widely-established backlog system between the Business Manager (in China) and the Marketing Manager (in the UK) and their respective teams.

Miscommunication about feature requirements also meant protracted development projects as products delivered did not achieve the intended brief, meaning additional work was required to satisfy expectations. Together, these issues created another problem: the inability of the development team to accurately estimate when their work can be delivered.

Improvements identified

The proposed opportunities to enhance the backlog management were two-fold:

1. Creation of a Product Backlog
   This was to capture all customer feature requests, management feature requests and product enhancement requests earlier. Azure DevOps was recommended to capture these types of work earlier so development input could be given and the team would have a steady set of features to work through.
2. Creation of a Lite Requirement Specification
   This was a set of sections that required completion before presenting a feature request to the development team at the weekly meeting. The recommended parameters for the specification document were:
   

   ID	Requirement Deck Sections
   1	Title of the feature request
   2	Description of the feature
   3	Detailed requirements describing the functional expectations of the feature
   4	Wireframes on how the feature should look
   5	Supporting documentation or links that will help in the building of the feature

Development Practices

Previous way of working

Assessing the client’s development approach was split into three areas:

• Software Methodology
• Development Approach
  • Branching Strategy
  • Environment Strategy
• Test Approach

While there was a loose alignment with Agile ways of working already in use, there was no software methodology in place. There were also development practices in place, though these were not communicated to all members of the team. This caused misalignment within the team on what the practices are and had an impact on the branching strategy (Git Flow) and environment strategy which often led to testing occurring against the wrong build and development lead times slipping due to additional effort required to merge branches.

Testing was spread thinly against three programmes, making it difficult to test builds in earnest as there was not enough time to conduct the manual and automation testing to the expected standards.

Improvements identified

We identified the following opportunities to enhance the development way of working:

1. Adopting a Kanban methodology to help manage work by balancing demands with available capacity, and by improving the handling of system-level bottlenecks.
2. Leveraging a static code analysis tool such as SonarQube to conduct reviews of the codebase in the absence of human reviewers.
3. Adoption of GitLab Flow
4. Adopting a branch to environment approach to enable parallel development.
5. Onboarding additional test resource to remedy the current constraints on testing.

Benefits

The proposed changes from the Ten10 DevOps Health Check were identified to create a cohesive environment that improves how the development teams work with the rest of the business.

• By implementing the Kanban framework, the client enables predictability to be reinforced through tooling and actionable insights drive decision making.
• Combining this framework with the lite requirement specification and the creation of a backlog means the client can now forecast when work can be delivered without onerous ceremonies impeding on developers’ flow.
• The adoption of the static code analysis tool reinforces quality before the build is handed to test.
• The adoption of GitLab flow enables the developers and testers alike to streamline the dev to test process and enable parallel development.
• Onboarding additional test resource means the development team can ease the bottleneck on testing as there are more personnel to assist with testing, meaning features to be completed faster.