Case study

Tailwind Gears is a manufacturing company that produces many different parts that are integrated into other products. They have five different product-centric divisions with a total of more than 600 developers. Each division has its own development process. Some use Scrum, some SAFe, and others use classical waterfall methodologies (validation model, or V-Model). Two of the five divisions build components that include software used in critical systems and are therefore highly regulated (International Organization for Standardization (ISO) 26262 and generic good practice (GxP)). The programming languages the software is built with range from embedded C and C++ code on hardware and chips, to mobile apps (Java; Swift) to web applications (JavaScript; .NET).

As with development processes, the tools landscape is very heterogeneous. There are some old Team Foundation Server (TFS) installations on premises; some teams use Jira, Confluence, and Bitbucket, and some use GitHub and Jenkins. Some teams already have some continuous integration/continuous deployment (CI/CD) practices in place, while other teams still build, package, and deploy manually. Some teams already work in a DevOps way and operate their own products, while other teams still hand over the production releases to a separate operations team.

Tailwind Gears faces the following problems:

• No visibility for top management on how development is doing. Since all teams work differently, there is no common way to measure velocity.
• The divisions report slow release cycles (between months and years) and high failure rates.
• Every division has its own team to support its toolchain, so there is a lot of redundancy. Things such as templates and pipelines are not shared.
• It's difficult to allocate developers and teams to the products with the most business value. Toolchain and development practices are too different and the onboarding time is too long.
• Developers feel unsatisfied with their work and not productive. Some already left the company and it's hard to recruit new talent in the market.

To address these issues, the company decides to implement one common engineering platform. This also intends to unify the development processes. These are the goals of the initiative:

• Accelerate software delivery in all divisions.
• Increase the quality of the software and reduce failure rates.
• Save time and money by raising synergies and only have one platform team that is responsible for the one engineering system.
• Increase the value of the software being built by allocating developers and teams to the products with a higher value proposition.
• Increase developer satisfaction to retain existing talent and to make it easier to hire new developers.

To make the transformation visible, the company decides to measure the following four key metrics of DORA:

• DLT
• DF
• MTTR
• CFR

Since there is no unified platform yet, the metrics will be collected using surveys. The plan is to move one team after another to the new unified platform and use system metrics there.

Developer satisfaction is an important part of the transformation. Therefore, two more metrics are added, as follows:

• Developer satisfaction
• Satisfaction with the engineering system

This is a mix of six metrics from at least three SPACE dimensions. There is no metric for communication and collaboration yet. This will be added to the system as the transformation evolves.