Moving To Agile Database Development – Part I
I still like this way of working because I believe that it is keeping me from falling into a daily routine. On the other hand, however, there is indeed a real danger to lose track of one’s goals and falling behind schedule, which then in turn might mean that certain delivery dates cannot be kept any longer.
At one point we moved from the trading floor to another level, which naturally resulted in a loss of visibility simply because we were no longer on-site all day.
This move forced a change in expectations towards the availability of new features for our users and for us. In accommodating the need to formalize the development we introduced monthly release-cycles. This at least offered the advantage that releases became more predictable and lifted some pressure off us as our customers realised that new features were not put into production immediately after development, but only at known release dates.
However, we maintained our way of development, whereas from one point onwards the communication between us as development team and our customers was taken over by a single person, who acted as central point of entry for requirements and passed them onto us, so that we should focus more on the development part. But what might seem positive at first glance as we did not have to struggle with the customers any longer until we had a sufficiently exact requirement, turned out to be a huge mistake in retrospect. In my opinion the transmission of requirements via a third party only incurs unnecessary friction so that the final result might not be what the customer wanted or what was discussed initially. There are several possible reasons for this:
1. The intermediary has not understood the requirements in full and/or not communicated those clearly enough to the developer.
2. The intermediary has a different opinion on the priority of a requirement and does not communicate those clearly enough involved parties.
3. The intermediary has his own opinion on how a requirement is to be implemented and this opinion might differ from an actually effective implementation.
4. The developer is missing certain background information for a particular requirement, because the intermediary is evaluating the background information differently and may omit information that is of value to the developer.
The first item in particular often led to misunderstandings and last-minute changes, because a requirement which had a low priority suddenly elevated in priority and became so important that it needed to be in the next release shortly before the release day. Needless to say, the quality of our code suffered from this and the code sometimes could not be completely tested for the front-to-end before releasing it.
All in all however we did quite well with that approach, until discrepancies between “us” as the data team and the client developers in our team became more and more apparent. The C# guys were practising agile development already for quite some time with a two week development cycle and a release one week later. Meanwhile we continued to perform our monthly releases. In the majority of cases this was no problem at all, since it is entirely possible to code database changes backwards compatible, or add new version of a stored procedure under a different name so that the procedure just sits in the database and only starts being called when the new client is released. In this way such client releases can be decoupled and can happen anytime after the database release. But then there were cases where a coordinated and combined database/client release was the only reasonable way in order to avoid unnecessary delays. This usually resulted in out-of-cycle release on our database side, which always represented a significant extra time and effort to create the release script, raise the change ticket, explain the reasons for this extra release to change management, etc…
Eventually we decided to harmonise both teams’ release cycles and to go even one step further and try to adopt agile techniques during development.
After researching Agile development we came to the conclusion, that there was little difference between ‘Agle’ and our method of development and release. Moreover, it occurred to us being worthwhile to jointly define priorities with the business application owner and gain more visibility through daily meetings.
Admittedly this may sound trivial when you read this on a webpage, but as a matter of fact our decision-making process was more or less the following dialogue:
Project Management: “Don’t you guys want to try agile?”
Data team: “Hmm, why not?”
Project Management: “Okay, I’ll prepare something then.”
Data team: “Cool …”
Oh well, this “preparation” from project management resulted then finally in our first sprint planning. But that is a topic for the next part…
Pages: 1 2