Monday, February 04, 2013

Breaking Down Barriers to Agile Database Development

Having a cross-functional team that works together to solve a problem is a basic property of an agile development environment.  It's impossible to list all the things that can impede the development of an agile database environment.  There are, however, some particular scenarios worthy of note.

One common case, especially in smaller organizations, is that the person who works on the database design is also a programmer.  In that case, fostering a collaborative environment is probably not too difficult.  Don’t let people catch you talking to yourself too often, though.  They might decide you have cracked under the pressure.

Another scenario that is ever-increasing in its frequency is when you have an agile development team with a “database guy” or a “database gal.”  In this situation it is important for programmers and the “database folk” to work together.  However, it’s still not that hard.

The toughest nut to crack is when you have an organizational boundary between a team of programmers and one or more database people, and those database people serve not only as database developers but also as “gatekeepers” to some production databases.  Oftentimes, the gatekeepers are vehemently against anything agile as well as anything automated touching their jealously guarded database structures.


I’m not exactly known as some great builder of bridges.  I’m actually better known for my “scorched earth” manner of dealing with people who I see as “in the way.”


However, there is one trick that has worked for me on the rare occasions when I was able to take a deep breath and count to a thousand before opening my mouth.  That trick is giving the gatekeeper control over the new processes I want implemented.  Instead of persuading them to let me have the most agile thing I can possibly get, software development teams in control of database design, I settle for the next best thing.  I try to persuade the "database guy" to take on the test-driven development and and object-oriented design activities I want implemented.

An example would be trying to get them involved in things like writing transition tests.


People tend to want to do the right thing and, when they are doing the wrong thing, it’s usually because they don’t understand the negative impact.  The other major reason is fear of no longer being needed.  It’s not so important who implements good practices as it is that they are implemented.

Giving control over certain aspects of an agile database development process to someone who is already in control of the database development process often neutralizes both the major impediments to adoption.  The gatekeeper will be able to make sure things are done his way and can be assured that he will remain relevant while slowly growing more accustomed to the modern ways of doing things.