The past two years have been a journey of growth, adaptation, and plenty of lessons learned. Stepping into a leadership role I was tasked to guide the data infrastructure team into scrum methodology in alignment with the direction of the organization. Having experience in agile in previous other jobs, I observed their current workflows and devised a plan of action.

It hasn’t been easy, but the progress we’ve made is worth reflecting on.


The Starting Point: Firefighting and Tickets

When I joined the team, the daily rhythm was dominated by urgent requests, troubleshooting issues, and responding to tickets. It’s the nature of infrastructure DBAs—our work often feels like an endless game of whack-a-mole. Databases don’t wait for the next sprint planning meeting to crash, and when something goes wrong, it’s all hands on deck.

In this environment, introducing agile methodologies initially felt like trying to teach a fish to climb a tree. The team was skeptical. Many saw agile as something that worked for application development teams but wasn’t practical for infrastructure work, where unpredictability reigns. And to some extent, they were right. The challenge was finding a way to adapt agile principles to fit our unique needs while still respecting the organization’s requirements and operational realities.


The Shift: Building a Framework That Works

The first step was to focus on the areas where agile could provide immediate value without disrupting the team’s ability to respond to emergencies. This involved:

  1. Introducing Kanban: Instead of forcing a sprint-based approach, we started with Kanban boards to visualize our work. Tickets, tasks, and ongoing projects were tracked in a way that made the flow of work more transparent. This helped the team prioritize effectively, even in the chaos of firefighting.
  2. Defining “Agile for Us”: We tailored agile principles to fit our environment. This meant shorter stand-ups, emphasizing collaboration, and focusing on incremental improvements rather than trying to overhaul everything at once.
  3. Carving Out Time for Proactive Work: One of the biggest shifts was setting aside time for proactive tasks—projects that would reduce future firefighting. This wasn’t easy, especially when urgent issues were piling up, but the payoff was clear. The more we invested in preventive measures, the fewer fires we had to put out later.

Adhering to Requirements

Agile isn’t about abandoning structure; it’s about working smarter within the structures that exist. In our case, adhering to the organizational requirements meant ensuring all processes, documentation, and reporting were compliant while still finding room for flexibility.

This required a balance:

  • Documentation in Agile: We emphasized lightweight but thorough documentation, ensuring that it met agency standards without bogging down the team.
  • Audit Readiness: By integrating compliance tasks into our workflow, we stayed ready for audits without making it a disruptive event.

Overcoming Resistance

Perhaps the hardest part of this journey was getting buy-in from the team. Change is hard, especially when the status quo feels like survival mode. To address this:

  1. I Led by Example: I made it a point to actively participate in stand-ups, update the Kanban board, and prioritize proactive work alongside the team.
  2. We Celebrated Wins: When agile practices led to tangible results—like reducing the number of repeat incidents or completing a long-delayed upgrade—we celebrated those successes.
  3. We Listened: Feedback loops were critical. If something wasn’t working, we adjusted. Agile is all about continuous improvement, and that applies to how we implement it as well.

The Results So Far

Two years in, we’re not a fully agile team—but we’re much closer than we were. Here are some of the key outcomes:

  • Improved Visibility: The Kanban board has migrated to a Sprint board, and has become a cornerstone of our workflow, helping the team and leadership see what’s in progress, what’s blocked, and what’s next. We have two generic tasks, one for maintenance, and one for tickets. Primarily these are for time tracking purposes.
  • Proactive Work Gains Ground: By setting aside time for proactive projects, we’ve seen a measurable reduction in recurring issues and firefighting.
  • Team Morale: While the shift was challenging, the team has come to appreciate the structure and focus that agile provides. It has allowed our less experienced members to step up and grow in taking and closing tasks instead of waiting for direction. I also think it’s a very good system for introverts.

Looking Ahead

The journey is far from over. Agile isn’t a destination—it’s a mindset. As we continue to refine our processes, my hope is to embed agility even deeper into how we operate, ensuring the team is not just reactive but also proactive and adaptable.

For anyone looking to introduce agile methodologies to an infrastructure team, my advice is simple: Start small, be patient, and adapt the principles to fit your reality. Change doesn’t happen overnight, but with persistence and collaboration, it’s possible to create a team culture that thrives on improvement and innovation.

Here’s to the next two years and all the lessons yet to come.