Transforming Software Delivery for the Brazilian Federal Government

Before I moved to London, before Kubernetes and Terraform became part of my daily vocabulary, I spent a formative period of my career at SERPRO — Servico Federal de Processamento de Dados — the Brazilian Federal Government’s IT company. SERPRO is one of the largest government IT organisations in the world, responsible for building and maintaining systems that serve the entire federal administration, from tax processing to the Office of the Presidency.

In 2012, I was working with a 70-person team responsible for systems that directly supported the Presidency of the Republic. Our primary deliverables included the presidential project monitoring system — the tool used by the Presidency to track the progress of government initiatives — and modules for the national anti-drug programme. The challenge wasn’t primarily technical. It was cultural, organisational, and deeply human.

The context

SERPRO had been operating for decades with traditional waterfall methodologies. Requirements were gathered in lengthy documents, development cycles stretched over months, and releases were infrequent, high-risk events preceded by exhaustive manual testing phases. For the presidential systems specifically, deployments were treated with extreme caution — a failure in a system used by the Presidency wasn’t just a technical incident, it was a political one.

The problem was that the pace demanded by the Presidency’s office was accelerating. The project monitoring system needed frequent updates to reflect changing government priorities. The anti-drug programme modules required rapid iteration as policy evolved. The existing delivery model simply couldn’t accommodate these timescales without cutting corners on quality, which given the systems’ sensitivity was not an option.

The team of 70 included developers, testers, project managers, and analysts — many of whom had worked at SERPRO for years using the same methods. They were skilled professionals, but the processes around them were limiting what they could achieve.

Introducing SCRUM and Agile XP

I led the adoption of SCRUM for project management and Extreme Programming (XP) for engineering practices. The combination was deliberate: SCRUM gave us a framework for planning, prioritisation, and stakeholder communication, while XP provided the engineering discipline needed to deliver faster without sacrificing quality.

For project management and workflow tracking, I introduced Redmine — an open-source project management tool that fit within SERPRO’s technology governance framework (which favoured open-source solutions over commercial products). Redmine gave us backlog management, sprint planning boards, and burndown tracking. For a team that had previously managed work through documents and email, having a single, visible system of record was transformative.

The engineering practices centred on:

Pair programming. This was perhaps the most culturally challenging change. Developers who had worked individually for years were asked to sit together and write code collaboratively. Initial resistance was significant. But within weeks, the benefits became visible. Knowledge silos dissolved. Code quality improved measurably. Junior developers learned faster. And crucially, for government systems where auditability matters, every line of code was reviewed in real-time by a second engineer.

Test-driven development. We established TDD as a non-negotiable practice. Every feature began with a failing test. For a team accustomed to writing tests — when they were written at all — after the code was complete, this was a significant shift. But it gave us confidence that changes to the project monitoring system didn’t break the anti-drug programme modules or vice versa, which was critical in a shared codebase.

Continuous integration. I set up the team’s first CI server, automating the build and test cycle so that every code commit was validated within minutes. Previously, integration was a phase that happened at the end of a development cycle, often revealing weeks of accumulated conflicts. CI made integration a continuous, low-risk activity.

Deployment architecture

Beyond the development practices, I designed the deployment architecture for the presidential project monitoring system. The previous deployment process was entirely manual — a documented procedure that someone followed step by step, with manual verification at each stage. Deployments to production required change approval from multiple stakeholders and were scheduled weeks in advance.

I worked with the team to build a repeatable, scripted deployment pipeline that automated the build, packaging, and deployment steps. While this was primitive compared to what we’d consider CI/CD today, it was a significant advancement for the context. The automated pipeline reduced deployment time from a full day to under an hour, eliminated manual errors, and made the process auditable and repeatable.

Training and cultural transformation

A 70-person team doesn’t adopt new methodologies through a memo. I invested considerable time in training — running workshops on SCRUM, XP practices, and the deployment pipeline for project managers and engineers alike. The project managers needed to understand the new planning cadence and how to work with Redmine. The engineers needed hands-on guidance with TDD and pairing.

The approach that worked was demonstration over argumentation. Rather than trying to convince leadership through presentations alone, I focused on delivering visible results with a pilot squad and letting the outcomes build the case. When the pilot team’s defect rate dropped and delivery cadence increased without incidents, other squads started asking questions. That organic interest was far more powerful than any top-down mandate.

One particular turning point was a weekend transformation sprint where I worked intensively with a cross-functional group to convert an in-progress feature from the old process to the new one. Seeing the contrast — the visibility, the test coverage, the speed of iteration — convinced several initially sceptical team members. Momentum built from there.

Measurable outcomes

Over the course of the engagement, the transformation delivered concrete results:

• Release frequency increased from quarterly to fortnightly, with some changes shipping weekly
• Defect rates in production decreased by over 60%, directly attributable to TDD and pair programming
• Deployment time reduced from a full day to under an hour through the automated pipeline
• Lead time from requirement to deployment dropped from months to weeks
• Team morale improved markedly — the 70-person team reported higher satisfaction, particularly around collaborative practices and the sense of shipping meaningful work regularly

The Redmine-based workflow gave stakeholders at the Presidency visibility into progress that they’d never had before. Instead of waiting for monthly status reports, they could see work moving across the board in real time. This transparency improved the relationship between the technology team and its government stakeholders.

A foundation for everything that followed

Looking back, the SERPRO engagement was foundational to everything I’ve done since. It taught me that the hardest part of improving software delivery is rarely the technology — it’s the people, the processes, and the organisational context. A perfectly configured deployment pipeline is worthless if the team doesn’t trust the process, if leadership doesn’t support the approach, or if the practices don’t fit the organisation’s constraints.

Working with a 70-person team on systems that served the Brazilian Presidency gave me a lasting respect for the complexity of government technology. These systems serve hundreds of millions of citizens. Making them better — even incrementally — has an outsized impact. That sense of meaningful work has guided my career choices ever since.