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…
References:
[1]: http://en.wikipedia.org/wiki/Agile_software_development
]]>