Kendra Little

26 June 2020

The Role of Agents of Change, aka Champions, in Database DevOps Implementations

This week I attended the Virtual DevOps Enterprise Summit. As a sponsor, Redgate held a virtual Happy Hour event in which we chatted with a great group of folks about implementing DevOps within an Enterprise. The conference had great content, but the Happy Hour was one of my favorite bits of the event.

One person who joined the discussion made some great points about the value of ‘Agents of Change’ in overcoming the top obstacles which arise when making changes to database-related workflows. I think ‘Agents of Change’ is better terminology for a role that I’ve previously thought of as a ‘Champion’.  ‘Champion’ sounds a bit like someone will win and someone will lose, but an ‘Agent of Change’ sounds more like a helper for the entire group, which is closer to the true goal of this role.

I realized after the talk that I haven’t written enough about the importance of identifying Agents of Change when working to improve database engineering and delivery, and what the role of an Agent of Change is in relation to database workflows.

First-hand Experience with an Agent of Change

Years ago, I worked at a small organization who was implementing Agile processes across all our development teams. This included some data processing teams who worked heavily with relational databases: the data processing teams understood a great deal about tuning and testing database code. This also included some teams who primarily worked on front end web interfaces: these teams preferred to do as little work against the database layer as possible and wanted to focus primarily on the front-end user interface for our customers.

All of these teams worked against the same databases, and changes introduced by one of the teams focusing on front-end work could quite easily massively impact every other team as a result of the architecture.

Implementing Agile processes for the database worked well with the data processing teams

As you might imagine, it was much easier for database administrators (DBAs) to work with the developers who understood a lot about how to leverage the strengths of relational databases as we evolved our processes. The two groups shared an interest in learning more about databases, as well as a common language to talk about change.

DBAs had a huge amount of friction when working with the teams focused on front-end development

In this case, there was no common language and interest. After years of working in a siloed fashion where the front-end teams had come to think of the DBA team as a type of batch script that simply repeats the word “NO,” the developers tended to dread and avoid working with the database altogether.

Having DBAs attend stand-ups regularly for these front-end teams only helped a small amount. The DBAs had a hard time following the conversation, which largely didn’t involve them, so it was difficult to make a meaningful connection. We also had so many development teams that DBAs couldn’t attend many stand-ups without it taking up a huge part of their workday. Even the managers of the DBA team and front-end development teams started feuding after a while.

As soon as a single person began working in the front-end team, relationships between everyone improved

Dramatic improvements began when a leader on one of the data processing teams suggested that one of their team members — a quite talented developer and communicator — move into one of the front-end teams as a team member who could offer help both in designing short term changes, and in helping evolve the architecture of the system so that teams could eventually become more independent of  one another.

We now had a talented translator who could identify when was the right time to loop in someone from the database administration team for a code review or chat about architecture. I also found that this developer’s excitement about databases really helped the team gain confidence: the database wasn’t as scary or dreadful now that there was someone on the team who liked the technology and was exited to find new ways to work with it.

This change was also good for the developer who moved teams: they became recognized as a type of hero by the DBA team. Leadership throughout the organization heard about their good work and they quickly became regarded as an emerging leader in the development organization as a whole.

Years later, I still think back upon this teammate as someone to emulate.

The Role of an Agent of Change in a Database DevOps Transformation

Agents of change are invaluable when you have established silos between development and operations, particularly when there are only limited healthy lines of communication between the groups.

In the example I described, an Agent of Change inside the development team was very effective. In some cases, you may wish to formally identify Agents of Change both in the development and in the IT side of the organization, and formally ask them to take on this role.

To succeed as an Agent of Change, these folks should be strong communicators who:

1. Are excited about working with databases as well as software development
2. Are interested in learning the language of both teams
3. Are open to new ideas about how workflows can evolve, rather than simply moving to a prescribed workflow
4. Can devote a significant amount of time to this effort for at least six weeks, potentially longer
5. Have a high degree of psychological safety which empowers them to ask questions

At Redgate, we have found that Proof of Concept (POC) implementations are key to launching a database DevOps initiative. Research such as the 2019 Accelerate State of DevOps Report confirms that POCs are effective across many organizations. Identifying one or two Agents of Change and engaging them as part of the POC process increases the chances of making the POC productive and producing useful findings and recommendations for your organization.