UCISA-Eduserv

Award for Excellence

Application Form 2011/12

Online Enrolment v2 and Agile Development

Institution Name
Robert Gordon University
Originating Department
IT Services
Contact Name (and email address)
Colin Jones, Web & Applications Team Leader (c.jones@rgu.ac.uk)

Objective of the Project/Service

The main focus of this competition entry is to show how the development project
undertaken was used as an opportunity to radically change the in-house software
development and project management methodologies from the more traditional “Prince and
Waterfall” approach to fully embracing “Agile” development practices.

The Online Enrolment v2 project was to produce a replacement web enabled system to
allow all students to enrol at the university at the beginning of their course of study, to
provide and confirm relevant personal details, to choose options for the collection of ID
cards and to make appropriate arrangements to pay any required fees.

Description of the Project/Service

The university launched its first online enrolment system in 2002, however in recent years
changing business needs and new initiatives in student recruitment and study programmes
meant that significant alterations were going to be required to the existing online enrolment
system in order for it to cope with the new patterns of enrolment and study.

The project team consisted of members of staff from IT Services and Student Administration.
At the beginning of the project three approaches were considered:

Amending the Existing Online Enrolment System

Consideration was given to making amendments to the existing enrolment system
however there were several disadvantages to this, primarily that the underlying
application architecture of the old system, designed years previously, would have
required very significant changes in order to incorporate the required business models.

Purchasing an external or commercial solution

The Student Administration department visited and investigated several other solutions
to provide online enrolment. Whilst investigating other potential solutions it was felt
that, even now, our existing single enrolment process which dealt with all aspects of
enrolment was still significantly further ahead than the primary commercial contenders,
many of which had separate systems for each process (e.g. online payment) instead of a
fully integrated solution.

Page 1 of 17
 Development of “Version 2” of the in-house solution
The third option therefore, which would allow us to retain the integration with existing
business systems and to build upon a known and understood user journey through the
system, was to re-write the existing system using the in-house development team.

After considering the options available, the university decided to proceed with the
development of a new version of online enrolment using the in-house team. At the beginning
of the project, the team also used this as an opportunity to revise the way in which we would
manage the development project.

Prince & Waterfall vs. Agile Development Methods

Our previous software development projects had always followed the fairly traditional
project management methods, having a large scale and detailed up-front design stage,
followed by a significant development effort, culminating in final testing of a “finished”
product. This would also be placed into the usual project management controls, with strict
change control processes and a formal project board.

At the beginning of this project however we decided that we wanted to see if using Agile
Development methodologies would allows us to better address some key requirements:
• Improve Estimation Capability
• Be more responsive to change
• Rapidly deliver usable software
• Improve quality and release control

Version 2 of the online enrolment system itself had to deliver as a minimum, the same
functionality contained within the existing version, but had to be built in such a way as to
make future upgrades and maintenance faster to implement and with less risk.

The key aspects of the online enrolment software were:

• Must allow the student secure access to the service
• Students should be able to check their course details
• It must allow them to update their personal details including contacts/addresses etc
• Must gather HESA monitoring information such as disability and previous education
• Must allow the student to see their course fees and payment arrangements
• Allow the student where necessary to pay in full, or by instalments online
• Allow the student to confirm ID card requirements and pick-up points
• Ensure the student is shown and actively accepts the university terms and conditions
• Emails the student with a confirmation of their enrolment session
• Passes all the gathered data into the SITS student records system
• Passes any financial payment data to the university finance system
• Interfaces with Worldpay our external payment provider

Initial enhancements envisaged as part of the future roadmap:

• Allow uploading of student photographs to integrate with ID card system
• Instalment plans and enrolment of students on the “RGU Professional” modular programme

Page 2 of 17
Return on Investment
The development was completed using internal resources and took the following overall:
• 2.5 FTE Web/Application Developer (five individual developers involved)
• 8 months duration from project kick-off to production release
• Additional resource from the business users in Student Administration
• Total internal resource value utilised for the project, approximately £85k overall.

The existence of an online enrolment system significantly decreases the staffing requirements
and logistics involved in enrolling students at the university. It also allows students to “fast-
track” through the enrolment process, from home or on mobile devices, available 24hrs,
without having wait in queues or be at a particular place a specified times. The ability to
adapt the service quickly to new business requirements and initiatives is also very important,
and as it has close integration with existing business information systems it means that manual
administrative tasks can be minimised.

A further key benefit was that the development team were able to learn and practice the
new Agile techniques and processes and whilst this necessitated some overhead on this
project, all of the skills gained can now be put to use on future projects.

Demonstration of Excellence
The key aim of this project was to deliver a replacement to the Online Enrolment system,
but a further important aim was for the team to extend and develop best practice within the
project and software development arena by revising the methodologies traditionally used,
fitting processes to ITIL guidelines and moving to Agile development practices.

As a result of this, the project has not only delivered the enhanced version of the enrolment
software to the business, but has also realised a number of key benefits in team development
and refined processes, over and above simple delivery of the end product.

Streamlined Requirements Gathering – Agile User Stories

Requirements gathering is quite an arduous and often a notoriously inaccurate part of the
software development process. End users find it difficult to visualise a working system and
the possibilities open to them, and changing business needs during the lifetime of a
development will often mean that carefully prepared plans have to be altered significantly
wasting both time and effort.

As part of this project we moved to using “Agile Stories” to define user requirements,
looking at the whole system from a much higher level than usual and defining basic
requirements of the system from the perspective of different user roles. So for example,
one of our agile stories was:

As a student,
I want to provide my contact details
So that the university can keep in touch with me

This story gathering exercise was carried out in conjunction with the business users and
developers, and informed the project of the overall scope of the system, getting agreement
from all parties and taking just one day to complete.

Page 3 of 17
Improved Estimation – Story Points & Planning Poker
Once the high level requirements of the system had been defined in terms of agile user
stories, it was the turn of the development team to discuss in more detail what was likely to
be involved – from a technical perspective – in delivering each of the aspects of the system
described in the user stories agreed with the business.

When this was done, we used another agile technique to allocate “story points” to each one,
known as “Planning Poker”. Each developer was given a pack of numbered voting cards, and
each decided on a relative size for the story being discussed. When all the votes were
revealed this often gave a surprising degree of consistency, with little variance between
developers. Where outlying votes appeared further discussion took place in order to reach a
consensus decision. Again this initial process took just one day to complete for the project,
and meant that we had an estimated relative size for each user story.

Setting User Priorities – MoSCoW

After the user stories had all been scored, we had a further meeting with the whole
development and business team involved to determine the initial priority of the work. This
was based on the “MoSCoW” scale:
• Must Have – absolute requirements without which the system cannot function
• Should Have – requirements that are very important and would be painful to drop
• Could Have – things we would like to deliver but at a push could remove from scope
• Won’t have – not required, although they may be included in a future release

This was just the first of many opportunities during the process for the business users to help
set the priorities of things worked on and the order in which they were to be completed.

Delivering Working Software – Sprints and Scrum

With the scope of work set out at a high level, the quantity of work sized, and the priority of
functional delivery agreed, we were able to move immediately into the development cycle
using the “Scrum” methodology. This broke the work down into manageable fixed work
packages of three weeks duration, each having its own planning meeting to define detailed
requirements, with the goal of delivering fully working and tested functionality at the end of
each of these “Sprints”.

The benefit to the organisation of having such frequent delivery of working software is that at
many points throughout the development project we had the option to put live the
development to that point – even if all the features had not yet been implemented. This
means that even if a subset of features can provide real business benefit, the organisation can
start to take advantage of that far earlier than in the traditional approach, where you would
have to wait for the entire software development to be completed.

In our project we had a critical mass to achieve before we could go live – as we were
replacing an existing system, we would not wish to go live with less functionality. However,
if we had been developing a completely new system we would have had several points during
the project where an early implementation would have been possible. In any case, we were
able to go live with a forward roadmap for further development, part of which has already
been delivered and part of which is scheduled for mid 2012.
Page 4 of 17
A further benefit for the business team was that they were able to carry out regular testing
on small parts of the application. This had a significantly reduced impact on their resources
than in the traditional approach which would necessitate a much longer intensive testing
period where business users would need to commit significantly more resources to testing
the application as a whole. They were also able to see the working application continually as
it developed, providing a higher level of confidence that the application development was
proceeding on track and delivering the functionality as agreed.

Improving Code Quality – Unit Testing & Continuous Integration

Another key aspect we wanted to introduce as part of this project was to move towards
test-driven development and create a full unit test suite to automate the testing of all the
components within the application. The reasons for doing this were two-fold: firstly, it helps
when developing using a team of people as it ensures that developers do not inadvertently
break existing functionality, and secondly it provides a far higher level of quality assurance,
that the code is working as intended, and allows us to automate the validation and testing of
the software product.

To further this goal we linked our unit test suite to Hudson, a continuous integration server,
which continually monitors our source control repository for changes by developers and
automatically runs all the unit tests and code quality checks. Should it detect an issue with
the code it will also deliver a “test failure” report automatically by email to the relevant
developer. We also used a “build radiator” screen which prominently displays the status of
the software to further encourage code quality and good testing practice within the team.

Improving Production Service – ITIL Release & Change Management

As part of our introduction of ITIL guidelines across many of our internal processes and
procedures we implemented a full change and release management process to ensure that
versions of the product are built, tested and tagged with a release number. These releases
are taken through our internal change control process and can be released as a complete
package by our automated deployment system to all our production servers at the press of a
few buttons. The benefit of this is that rollback to a previous version is just as simple and
deploying new releases is very quick and easy to carry out with the minimum of disruption
and downtime for end users.

Strategic benefit
The university’s aim to deliver a rich student experience from the very first contact that a
student has with us means that the online enrolment process is a key interaction point from
which students will form opinions about us. First impressions count. Consequently it is very
important that the process is simple and streamlined both for the student, and for
administrative staff, and that data gathered is recorded appropriately and in the correct
business systems.

It is also vitally important that our student facing systems are able to adapt quickly to
changing business needs and new initiatives. For instance, the university’s move towards
expanding modular course enrolments and enhanced pathways for continuous professional
development, under the “RGU Professional” umbrella, are recent changes which have now

Page 5 of 17
been accommodated by the enhanced system. Rapid “Agile” delivery of these types of
changes is very important, but it must also be coupled with the assurance that quality is not
being compromised.

Implementing these agile development practices has meant that the development team has
been able to move forward significantly in positioning itself to respond to these types of
demands, whilst at the same time significantly enhancing the quality of product and the
service being provided. Having used these methods for the first time on this project and
seeing how well it has worked, we now intend moving forward on all our future
developments using this type of methodology. In addition, we are also looking as a
department at how some aspects of agile methods can be used outside the software
development arena and into general project management, in cases where these techniques
would deliver a benefit.

Transference of Best Practice

The methods and techniques used during this project are not new, however it is often the
case that development teams can take some time to adopt them, and feel nervous moving
from established work patterns. In addition institutions themselves are often wedded to the
“traditional” approach through strict project management processes and procedures.

Our experiences in using these methods, and the success which we have encountered should
certainly encourage other institutions to pilot the introduction of these methods. It is
important to note that it would not be necessary to introduce all of them at once to start to
realise real benefits. Indeed, just implementing Agile Stories and Scrum would be a very
valuable step in changing the development process and delivery of software. For a list of the
technologies and techniques we used see Appendix A – Technologies and Techniques

Names of Staff involved (including job titles and email addresses)

Development Team
Colin Jones Web & Applications Team Leader c.jones@rgu.ac.uk
James Buckingham Senior Web & Applications Developer j.c.buckingham@rgu.ac.uk
Annette Murty Web & Applications Developer a.murty@rgu.ac.uk
Peter Wright Web & Applications Developer p.w.wright@rgu.ac.uk
Lewis McConochie Systems Engineer – DBA l.mcconochie@rgu.ac.uk
Business Representatives
Julie Guest Head of Student Administration j.k.guest@rgu.ac.uk
Gillian Reid Student Records & Information Manager g.reid@rgu.ac.uk
Fiona Proud Student Finance Officer f.proud@rgu.ac.uk
Project Board Representatives
Shona Cormack Vice Principal (Student Experience) s.cormack@rgu.ac.uk
Valerie Maehle Dean v.maehle@rgu.ac.uk
Andrew McCreath Executive Director a.mccreath@rgu.ac.uk

Support of Institution UCISA Representative

As the UCISA Representative for the Robert Gordon University, I confirm that this
submission for the UCISA-Eduserv Award for Excellence 2011 has the support of the
institution.
Andrew McCreath, Executive Director (Information Technology & Communications)

Page 6 of 17
a.mccreath@rgu.ac.uk
Appendix A – Technologies and Techniques
The following Agile techniques
hniques were used:
• Agile User Stories, Story Points and Planning Poker
• Scrum methodology and Sprints
• Unit Testing / TDD and Continuous Integration

The following software technologies were used during the implementation project:
• TRAC - issue tracking system for software development
d projects (http://trac.edgewall.org/
http://trac.edgewall.org/)
• Subversion – open source version control system (http://subversion.apache.org/
http://subversion.apache.org/)
• MXUnit – Unit Testing framework (http://mxunit.org/)
• ColdBox – Conventions Based Object Oriented Framework (http://www.coldbox.org/
http://www.coldbox.org/)
• Hudson – continuous integration server (http://hudson-ci.org/)
(
• ANT – Automated build and deployment tool (http://ant.apache.org/)
(
• MySQL – Open Source relational database (http://www.mysql.com/)
(
• ColdFusion – Application Server (http://www.adobe.com/products/coldfusion
(http://www.adobe.com/products/coldfusion-family.html)

Our project scrum schedule was defined as follows for each “sprint” (a.k.a
(a a. iterations).

A sprint burndown
urndown chart from the project showing work being completed to target date for
that sprint delivery.

Page 7 of 17
Appendix B – Agile Tool Screenshots
Examples of our TRAC issue tracking and release management system:

Our Agile Storyboard and our Hudson “Build Radiator”

Radiator” showing testing status, and a
screenshot
hot of the Hudson continuous integration console.

MXUnit test results screen showing all 288 unit tests passing:

Page 8 of 17
Appendix C – Online Enrolment User Screens
The following pages show some example screen shots taken from the online enrolment
application which students would follow as part of the online enrolment process. It is not an
exhaustive list of screenshots as there are several paths through the system depending on
student type and course, etc, and different screens would then be shown.

Login Screen to Online Enrolment for Students

Overview Screen

Page 9 of 17
Some Initial Personal Details

Home Address Screen

Page 10 of 17
Disability & Learning Difficulties

Term Time Contact Details

Page 11 of 17
Education Screen

Page 12 of 17
Monitoring Information

Finance Overview

Page 13 of 17
Finance Payment Arrangement Screens

Page 14 of 17
Student Declaration

Page 15 of 17
Student Confirmation Email

When the student completes the online enrolment process they are automatically sent a
confirmation email:

Page 16 of 17
Administrative Staff Screens

As well as the front end student interface, the system also has “back office” administrative
screens which allow staff members to make changes to the system and run reports etc.
The two examples below show the reporting tools and application settings.

Page 17 of 17