Moving To Agile Database Development – Part I
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.
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.
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.”
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
Pages: 1 2