Agile Database development? What’s that? Why would I need that? These were questions I had myself until until recently when I tried it.
Several couple of weeks ago, we successfully finished our first sprint and my intention is to pass on this experience and hopefully provoke some reaction from readers. I would love to hear how other folks do database development and see where there are commonalities and where differences.
I have devoted the first part of this series to examining the reasons that have led us to the decision to incorporate Agile processes into database development.
Disclaimer
Let me make it clear right from the start: I do not claim to be an expert in the diverse methodologies of software development, nor do I claim to know the differences and subtleties of the various agile processes. On the other hand I cannot really claim that I am too overly interested in theoretical constructs. This I’ll gladly leave to the experts that can contribute to each and everything. I do however like to think that I am a person with a good portion of common sense that acts result-oriented and not completely process-oriented.
Definition
What exactly is “Agile Development”? Wikipedia gives you the following answer:
“Agile software development is a group of software development methods based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change. It is a conceptual framework that promotes foreseen interactions throughout the development cycle.”[1]
My Background
What does this definition now mean for me and the environment in which I work? I work in the investment banking IT of a large financial institution for the equity structured products desk. My primary clients are the traders and the quantitative analysts. The systems, for which I am responsible, are self-developed, classical front-office systems, which have a lot of interfaces to other downstream departments. Hence a lot of important consumers of our data are located in departments like Controlling, Risk Management, Middle-Office and Back-Office.
My professional environment is and has always been dynamic. We never had the luxury of having 6-month release cycles that can be planned way ahead of time with a lot of business analysts that gather the requirements from the customers and communicate them to the developers. To overstate the case somewhat, one could say that 90% functional software that is available within 3 weeks is preferred over a software that covers maybe 95% – 99% of the functionality but takes 3 months to deliver. The missing functions will be subsequently be delivered. The main thing is that the users can use the system productively, while the whole system develops around its core functionalities grows more feature-compete more stable and mature.
When I started with my company, I was sitting directly on the trading floor next to the traders. There were numerous days where it was not possible to do systematic development, because something might have gone wrong and had to be fixed, or because of the many requests for ad-hoc queries and analysis that had to be worked off. ‘Systematic development’ at this time was the implementation of the strategic policies of the business owner of our applications. This could be, for example, to facilitating a data feed from or to another system, or help the implementation of mid and long-term goals of the business, such as lifecycle management of product classes. For that we had concrete deadlines that had to be met. Beyond that there were the tactical targets. This could, for example, be the development of a certain feature for a trader or an analyst. Usually those requirements were raised in a mail, tracked in a project-management tool and put into production with the next release in case there was enough time to develop them and there was no collision with the strategic targets. This was, so to say, our daily business next to providing support to maintain production availability.
When it became foreseeable, that one of these tactical targets could not be finished within the agreed timeframe, we told this to the person who raised this request, explained the reasons for the delay and agreed a new delivery date. In my own experience it is worth talking to this particular customer personally and clarify things in a conversation, rather than sending a mail, or, even worse, not communicate at all.