Waterfall
Coming from a background of software development using
waterfall, I was always fully aware of its shortfalls. Speed of delivery, number of defects found in
test and its rigidity and inability to cope with changing business requirements
in an agile way. With a split site
development team of 3rd party developers in the US and Testing and
Management in the UK the turnaround of defects was painfully slow and changing
requirements had the impact of future delays and increased cost to already
delayed projects. After moving on to my
current testing job I moved into another role using this software development
methodology.
The old approach was
very labour intensive with manual testing, producing and reading of BRD’s/functional
& technical specifications and then taking time to write test cases, all of
which added unnecessary layers of process to software development. Gladly those days are behind us after moving
to agile, but it does remind you and helps you understand how software
development has matured and benefited from adopting an agile approach. Agile
Moving to agile had a profound effect for us as
BRD’s/functional & technical specification documentation were replaced with
story cards. Our deployment process of getting new
releases into our QA environment was simplified to just one click of a button! This was a stark change compared to writing a
release note and creating a request ticket in another application, which was
then sent to our Application release engineers to deploy. The removal of these process heavy steps was
like removing barriers in the software development lifecycle. By cutting down on manual tasks it freed up
the team to concentrate on what we were best at ‘software development’.
The business benefited from the move to Agile as previously
last minute changes were very difficult to accommodate into a release. With story cards it was easier to estimate
the time needed to carry out the requested change and therefore easier to
manage changes like this from a release management view point.
The move to Agile was not without its learning curve
however. It took some time to mature as
a team and get processes in place to better manage releases and become more
efficient in the way we used agile as a business. Releases in 2011 were still happening too
infrequently with large areas of functionality being worked on behind beta
features which would then be turned on in one release. The down side to this was that there would be
2-4 releases a month which would mean we were not able to fix live issues a
quickly as we would have liked. The risk
of failure to each release was greater as there were more changes building up
for each release and last minute changes would add additional complications
which could have impacts across multiple areas of the site. Due to the size of the release and the risk
regression of the releases was lengthy so that we would have confidence in the
release. As a result of the low release
rate and increased risks our release success rate in 2011 was 73% which
gradually improved the following year to 76%.
A change was still needed…
Daily Releases
Around May 2012 it was decided we would look at releasing
more frequently, as opposed to our traditional 1 release a week we had the
ambition to release everyday where possible.
Releasing smaller number of stories on a regular cycle was thought would
reduce the risk seen with larger releases and therefore improve the confidence in
the releases we were doing, as there were fewer changes to test and therefore
fewer defects. This approach also
helped change the way last minute business changes were handled. Rather than add these into the release last
minute when they would add risk to a release they could now wait till the
following day’s release, as our release frequency was now daily as opposed to
weekly. Large releases are less
frequent but are managed better though our multivariate testing which allows us
control over monitoring the performance of new features for the site with a
live test group of users. This process
was not in place when we first adopted agile but allows us to fine tune a
feature and find any other issues with it before it is released to the main
alpha site for all users to experience.
Daily releases I think have been one of the key changes we
have made which have led to the improvements seen in our software development
process. Compared to the previous year our release
success rate has increased dramatically from 76% to 93%! While at the same time the number of release’s
done has increase from 66 to 123. This
is a clear indication that the daily releases along with our agile approach are
pivotal to successful software delivery.
This has only been possible due to our adoption of agile and the
establishment of associated technologies, which over time have allowed us
greater flexibility to cope with change.
What the Future Hold’s
Going forward we’ll be looking to streamline our deployment
process to live similar to the current process we have implemented for
deployments to our QA environments. A
one click deploy process to live with the ability to rollback just as easily if
needs be. This will remove another
process sticking point in getting software to live where it makes a difference
and delivers value to the business and consumers. Once this is in place we will have less
limitations of when changes can be deployed to live. We will no longer be limited to one
deployment a day but could potentially release to live multiple times in one
day if needed. I can foresee in the future that we will seek closer interaction with our users and use their feedback to
update the site and bring features that the users want to see. This could also be useful in crowd sourcing
feedback from users on new features which are currently in test that could
dynamically feed into the design/functionality process for that feature before
it is delivered to live. Closer collaboration between the business, development team and end users can only help improve our software development process. The technical abilities of one click deploy along with our agile approach add benefits of faster speed to market which make us more responsive to change.
