Wednesday, January 2, 2013
A former DBA's guide to Agile.
"Ninety-nine percent of all software sucks, with Agile we can make it a hundred" (paraphrasing a tweet from Buck Woody some years back)
The past year brought me out of the waterfall software methodology and into working in a agile shop. I used to make fun of agile, partly because I have never seen it implemented well and partly because I was a DBA in a waterfall shop. (If for some reason you don't know a DBA, they proceed cautiously, probably have a black leather jacket and generally don't like change.)
So here it is in former DBA writing style - a list.
0. Forget everything you knew about project management, it hardly exists anymore as a stand alone job. (And C# arrays are zero based, so my list is as well)
1. It is better to be a developer in an Agile shop, a waterfall DBA would go insane.
2. As you get more comfortable with pushing code that has hardly been tested to production, be careful as it starts to creep into your daily life; just the other day I walked out on the ice on the river behind my house to make sure it was safe (open water a few feet away), when my ax was right there to test it first.
3. You have to completely give in to the developers, especially since work that has been promised to the business needs to get delivered, there is no more "control". In any corporate power struggle, the business folks win, and if you hold up their new KPI, because the code is insecure or non performant, you lose.
4. Each unit of work (a story) is small enough generally to be completed in a day or two of work and it might not be the finished product. "You mean this stored procedure is only half written! You are NOT going to production with that!" says a waterfall DBA the morning of a huge deployment every three months.
5. If you ever want to be a remote worker - this is a great way to show management that work is being completed despite the fact they don't get the face time they value so much.
6. Because deliverables are generally small - the screw-ups are usually smaller but more visible; making this useful if you have a vendetta and want to get someone axed, but have a big HR department. :)
7. There seem to be less meetings because things need to get done. A huge win for those of us who lived in meeting driven development.
8. Everything you do has a "point" value, so if you are a competitor and believe the developer with the most points wins, you get to win many times a year.
9. You will get better at estimating, or you will work more than you want to in a given sprint. The upside is the entire team gets to put their .02 in on how complex the work actually is; so the old days of some folks over estimating their work in an effort to provide time to play on Facebook is gone.
10. If a sprint falls during mushroom season, you can just lower your velocity a bit and spend a little more time in the woods :)
I have no classical training in agile so I am sure the pedantic readers will note I don't know the terminology or really understand what I am talking about, my lone excuse is I am too busy trying to keep up with all the cool new technology and projects I get to work on.