Last night, I had the pleasure of presenting at the Greenville SSIG; my topic was Agile Database Administration, and it was a presentation that I had pulled together at the last minute.  It still needs some refinement, but overall I thought it went pretty well.  However, I was surprised at a couple of things:

1.  Out of my (admittedly) small sample of attendees, only about 2% had encountered Agile methodologies (like Scrum) in their work, and

2.  Even fewer of them understood the challenges that Agile is supposed to solve.

I decided that in order to improve the presentation, I would try to do a little more research; since I own a blog, this seems like the perfect place to synthesize some of my thoughts on the subject.  As I did in my presentation, I’ll try to skew the discussion toward data people, but there may be some challenges along the way (since much of Agile focuses on management of development tasks, not administration or service-oriented tasks).

Begin at the beginning….

The Agile movement begins with the Agile Manifesto, a short statement of belief written by 17 software developers during a weekend at a resort in Utah.  The entire manifesto reads as follows:

We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more.

There are twelve basic principles associated with the manifesto; I’ll tackle those at a later post.  The concept of the manifesto is clear, however, in that the goal is to manage tasks through a focus on relationships and the business environment as opposed to strictly moving from point A to point B.

As a sidebar, I do find it quite funny that the Agile Manifesto webpage appears as if it was thrown together after a weekend of drinking and philosophical conversations at a ski resort; it hasn’t changed in 12 years.  I’m not sure if that’s intended as a silent testament to the longevity of agile code or not.

It should be noted that many agile methods actually began before the manifesto; the manifesto was not intended to spawn new methodologies, but rather to provide a common framework for several existing methods.  It’s a philosophy, not a method; you have to think agile before you can be agile (I’ll pause for a minute to let that sink in… ready to move on?)

Let me try to define the agile movement by what it is not:

• Agile does not mean a particular method of development; rather, it’s an umbrella for several different methods.
• Agile is not represented by a set of tools; but you should use tools in an agile way.
• Agile is not an excuse for sloppy work; instead, it’s an attempt to focus on quality throughout development.
• Agile is not a solution for every organization; the agile philosophy represents a change in process which must be endorsed by the organization in order for it to be successful.

Jumping the candlestick…

The term agile means “nimble”; it’s the ability to quickly respond to a changing environment.  Most agile adherents recognize that processes such as lengthy requirement gathering sessions can cripple the development process; if your organization spends a lot of time defining what it needs up front, the business environment can change before you get it developed.

But what about database administrators?  Most admins I know have mild cases of ADHD; database professionals are the master of change.  Need a query to see what’s happened over the last year?  No problem.  Backups not working? We’ll look into it.  Server overloaded?  We’ll deal with it.  Printer not working?  Not my department, but sure.  Developers too slow in getting a report to you?  I can do it.   We’re already agile, right?

Wrong. To be agile doesn’t mean you leap over one flame to another; it’s finding a method of getting things done that is responsive to business changes while solving business problems.  If you’re constantly hopping from one issue to the next without figuring out how to keep the fires from occurring, you’re eventually going to get burned (see what I did there?).  If your servers can’t handle the queries your users are throwing at it, you can tune the queries but you may need to look at a hardware solution.  If your boss keeps asking you for the latest numbers, it may be faster to run the query for her, but writing a report (or showing her how to write a report) will minimize the long-term problem.

Thinking agile means thinking strategically; be nimble (solve the immediate problem), but be clever (address the root cause).

Where do we go from here?

I hope to start pulling together a few blog posts on various agile methods and how they relate to the agile philosophy over the next few weeks; specifically, I hope to talk about how the agile philosophy is influencing my database administration management style.  Until then, here’s some links for you to consider:

http://en.wikipedia.org/wiki/Agile_software_development

http://www.agilemanifesto.org/ (Be sure to read the principles on the next page).

http://www.agiledata.org/essays/dbaSkills.html (lots of material here; I need to revisit it