One of the key ideas we have as we approach new customers is that we want objective results and data to drive planning our interventions. We strive to give initial results quickly so our customers can take home value straight away. For this reason we created an initial evaluation package that we can offer quickly to assess the initial situation.

Our customers often have a very clear idea of the symptoms their business is facing, but have a hard time identifying the root causes. In this study we'll present the case of a 20-years old company that had issues of productivity and implementing innovation.

Initially we ran a psychological safety 5-points check. This gave us and the customer an inital idea of how their developers feel about their job and if there are any evident workplace problems.

It was important that these checks were worded the right way, were sent in a consistent way and had the right tone so that we didn't skew the results. We took special care to be consistent across different checks so the results were statistically comparable.

Using some analysis, we determined indicators that showed us some strengths and some pain points: the sysadmin team was feeling 20% better than average, but development and release were certainly suffering, reporting satisfaction levels 15% below average. This is a typical result when a DevOps culture has not been cultivated. While there are multiple possible explanations, it's not too hard to imagine that manual releases and waterfall development are perceived better in traditional system administration teams, but are behind the times in development and releases teams.

The second point of intervention was a department or company retrospective. In our case it showed tha

Next, we shadowed numerous repeating meetings and took notes about the kind of topics covered -- for example, line management, product management, or project management -- and the objective of each -- e.g., status updates, planning and so on. This lead to a report where we documented the current methodology of the company. The outcome made us understand that there was no formal development methodology in place and most of the responsibilities were set on team leads that were traditional project manager and line managers all in one person. Product management choices were made by sales and were driven by customers without any particular product vision being implemented.

Finally, we took some more time to examine the architecture and code quality of the company's brownfield application to understand the amount of work needed to refactor and modernize the application. This was quickly resolved as the application code was huge, in places over 20 years old, and over 8 million lines of code, with hundreds of projects and solutions, so it was clear from the start that refreshing the code would take person-years and that it would involve making deep changes in the way the company produced software.

With all these informations in hand we paired with the company CTO produced a vision document to push the company forward for the current year. Our choices were centered around fixing the methodology and introducing a simple, non-scaled scrum framework; starting to break up the sysadmin-developer divide by creating multifunctional teams; migrating to github and adding continuous integration and automatic deployments; taking a smaller application and focus on modernizing that to understand better what it was going to take to refactor the whole codebase.

In conclusion, the company decided to trust us for implementing this plan with them and within 6 months we had delivered on all the points promised.

‍