March 26, 2025
Knowledge is valuable, but its real power lies in how we put it into action. At Freyr Digital, we were familiar with DevOps, its associated practices, and how it could transform our organization into a high-performing product development powerhouse-capable of delivering quality products and solutions to our life sciences customers. As we began our journey, our efforts laid a strong foundation, but to truly become a development powerhouse, we knew we needed to adopt a more strategic and adaptive approach.
The primary challenge in translating knowledge into action lies in knowing when to take the right steps. Since actions impact many people in an organization, doing the right thing at the right time depends on where we are as an organization, our current processes and practices, and the skills and capabilities of our people.
This marked a turning point in our transformation. As a portfolio of software vendors specializing in custom solutions, we had a dedicated team going the extra mile to deliver results. However, we saw an opportunity to enhance quality, boost productivity, and accelerate the conversion of business requirements into deliverables. Rather than focusing on last-minute fixes, we aimed to shift from reactive problem-solving to proactive innovation, building scalable, high-impact solutions.
We had a vision of where we wanted to be-how we wanted to work, develop, test, deploy, and release software. However, we knew that achieving those goals required thoughtful strategy, continuous learning, and a commitment to improvement.
Fast forward to today: in the last year, we’ve made over 100 releases with near-zero deployment failures and achieved almost full automation in rolling out changes. Additionally, we’ve seen significant progress in revenues, leaner and more agile teams, and an overall shift towards our vision of becoming a powerhouse in software products, solutions, and services. While there’s always more to achieve, we’re confident that we’ve laid a strong foundation and are ready to accelerate.
As we move forward, we’re taking a moment to reflect on our transformation-what worked, what didn’t, and the lessons we learned. By sharing our journey, we hope to support others navigating similar changes.
This blog series is mainly empirical, sharing what we did, while also connecting our actions to best practices and recommendations from various DevOps and Agile resources.
Doing the Right Thing at the Right Time
One of the key aspects of our transformation was identifying the right actions at the right time. With multiple possible initiatives, we needed a structured approach to ensure meaningful progress.
Looking back, we can group these actions into three categories: Tools and Processes, Software Architecture, and People. These categories are highly intertwined, with changes in one impacting the others. However, it was possible to incrementally make changes in each category and measure progress toward our overall goals.
The initiatives in these categories often depended on one another. Changes in one area opened possibilities for further improvements in another.
The First Steps
To set a strong foundation, we focused on three core initiatives:
- Integrating our source code bases with SonarQube for code quality metrics.
- Moving all teams to a common tool for managing requirements, source code, and test plans-in our case, Azure DevOps.
- Structuring teams with clear responsibilities to enhance ownership and accountability.
These three initiatives gave us visibility into:
- The work being done (requirements and tasks).
- The code quality (SonarQube metrics).
- The people involved (team responsibilities).
Among these, defining clear team responsibilities was the most challenging. Initially, team structures were fluid, with people moving across projects as needed. Transitioning to dedicated teams with distinct functional areas was a necessary step, though complicated by our existing product architecture, which wasn’t fully designed to support clear ownership.
The Role of Software Architecture
We quickly realized that product architecture was one of the most critical areas for change. A modular architecture was essential for enabling independent teams to take responsibility for their work. Without this, our efforts to create team ownership were limited in impact.
Re-architecting our portfolio was a complex process. It included moving fully to the cloud and starting to build cloud-native applications using a microservices architecture. This topic will be covered in a future post. The key takeaway, however, is that changes are incremental, and some steps must precede others to unlock benefits and further progress.
Metrics and Continuous Improvement
After beginning work on re-architecture (an ongoing endeavor), we shifted our focus to monitoring metrics and setting targets:
- Code quality metrics in SonarQube.
- Code integration metrics in Azure DevOps.
- Feature throughput metrics for individual teams.
- Adoption of cloud-native services.
These targets weren’t hard mandates but guiding objectives to help teams align their efforts.
Empowering People
With metrics in place, it became evident that teams needed support to achieve these goals. For example, while setting targets for unit test coverage and API test automation was straightforward, achieving them was challenging, especially for legacy code that hadn’t been designed for testability.
To address this, we:
- Set lower targets for legacy code.
- Organized workshops and hands-on training on writing quality unit tests and designing testable code.
- Provided guidance on building stubs for API testing.
- Conducted reviews of unit tests by senior architects.
The Tools, Architecture, and People Triangle
A good example of the interplay between these categories was code and repository management. Integrating with SonarQube, which is an improvement in tooling, revealed low unit test coverage, which pointed to architectural issues limiting testability. Improvements in architecture and team skills led to better-quality unit tests, but these weren’t being executed regularly due to poor branching practices. We addressed this by standardizing branching strategies and ensuring regular integration of code into the main branch, enabling CI pipelines to run all tests.
The Right Sequence of Change
One approach to transformation is to implement best practices indiscriminately. While this might bring benefits, the results often fail to justify the effort, leading to frustration.
We followed a different approach, based on the principle of flow: analyze the end-to-end process, identify bottlenecks, and address them incrementally.
Each improvement revealed new bottlenecks, requiring further action. This wasn’t a game of “whack-a-mole” but a deliberate process of doing the right thing at the right time.
For example, mandating unit test coverage without improving code design would have led to frustration and “coverage theater” (superficial tests written to meet metrics). By addressing architecture and skills first, we ensured meaningful progress.
Looking Ahead
True transformation isn’t about a single big shift-it’s about smart, well-timed decisions that drive continuous progress. We’re excited to share our journey and insights to help others navigate their own path to scalable, high-impact change.
In the forthcoming blogs of this series - DevOps for the Win, we’ll break down each phase of our transformation in the DevOps Triangle -Tools, Architecture, and People-helped us achieve lasting impact.
Category: