Oracle, Databases, Scrum and Agile

I recently read a great post by Cary Millsap, an influential member of the Oracle community on Oracle and Agile. I have read both of the books Cary mentioned. They are excellent. And the Goal by Eli Goldratt is outstanding, if you haven’t read it, put it at the top of your list. It is a novel and has nothing to do with software.

I don’t really understand why Agile is not embraced by the Oracle community. There are lots of reasons why it can make a developer’s life better, and it doesn’t matter whether it is coding SQL or Java. However from a DBA perspective, I think having changes committed to production DBs every week or two is scary, especially if you are the one responding to 4 AM outages (and why do they seem to mostly occur at 4 am?).

For Agile to be successful we need to deploy early and often. For production stability and performance we need to quantitatively know deployments are going to work just as well or better than the last deployment. There need to be safeguards put in place to address the risks, and systems that reduce or eliminate the transaction costs of doing deployments. As mentioned in Cary’s post, automated testing plays a huge role here.

Here’s one way of stating the DBA’s needs in the form of a user story:

As a DBA I want to have a stable, high quality database to monitor performance and tune so that I can maintain data operations and improve system performance.

Acceptance Criteria:

• New database releases to production must contain all the performance improvements implemented in production to date.
• All DB changes must have automated test coverage that quantify whether or not the DB changes implement the desire inputs and outputs correctly
• Any DB change found to not function correctly can be rolled back without impacting the rest of the DB
• All changes between production deployments are automatically calculated and displayed to DBAs
• Production Databases are stable and not changing between the regular release cycle.
• DBAs collaborate with and are consulted by the team(s) implementing DB changes
• DBAs provide weekly mentoring and DB code reviews with team members implementing changes
• (Please add your additional acceptance criteria)

What changes you would need to implement in your organization so that the above user story were true?

If you are a DBA working in a small company next to developers and QA, then maybe it is changing a few of your practices, working more closely with the other developers on DB changes, implementing test frameworks like DB Unit, getting SQL code into version control, implementing a DB change management tool like Liquibase, and creating a better rollback strategy.

If you are in a large bank sitting with 15 other DBAs at the backend of a manually intensive, form driven, cost managed, outsourced deployment process, you have some work to do. The goal and many of the steps are the same as with the small company. Ironically, the bank has many more resources to implement these changes. However the management hierarchy and organizational silos make it much slower and more difficult to implement these changes. So what do you do?

Well you can continue to stay in your DB team silo, complain that Agile is the problem and be the victim. This means that most interactions with others wanting changes will be negative, you will be viewed as obstructionist, and that cute tester will think you’re a jerk. Another approach would be to remember that we are all on the same team, and go for a walk and meet the Agile teams to see how you can work together. You might take this blog and the user story above, show it to the ScrumMaster, Product Owner and Developers.

Start a friendly discussion about how your needs for a reliable, production friendly DB can be met in the context of regular production releases. Remember that by doing this you are asking them to change as well, and since you are both changing, the situation becomes problem solving together. One more point, expect mistakes to be made and occasional firefighting on the road to a more effective development and database operations process. The changes are non-trivial, the results can be amazing, and the journey is the most memorable part of the experience. Bon Voyage!

Thanks to James Thomson for the inspiration on this one.