Using the DSDM Agile Project Framework at the University of St Andrews
Using the DSDM Agile Project Framework in the Curriculum-View (C-View) Project. The DSDM Agile Project Framework was introduced into an efficiency change programme already running in a non-Agile environment at the University of St Andrews, Scotland, in 2014. The introduction came with a switch from external consultants to internal personnel, all of which was a radical departure for the organisation.
This case study examines one of the largest (still ongoing) projects within the change programme, an ITbased undertaking to improve the access, visibility and management of curriculum data and therefore the student journey through the university.
Challenges included the introduction of Agile to an already existing project and the buy-in of senior management turned off by the pre-Agile doldrums. Added to this was also the availability of adequate developer resources.
The project:
C-View is one of nine technological projects in the university’s change programme. It has the widest scope of the nine and, since late 2014, has been delivered wholly by in-house staff.
It has five main areas, each with specific objectives and deliverables:
- A new, user-friendly database of agreements with other universities (e.g. agreements that enable St Andrews students to study for a year or semester at those universities), searchable by current and prospective students.
- A switch from manual to electronic management of curriculum changes.
- Enhancement of the publication process for several key curriculum publications.
- A centralised system for external examiner recruitment, renewal and reporting.
- Enhancement of the academic monitoring process, for internal quality monitoring and statutory reporting.
The use of the DSDM Agile Project Framework
The business case and requirements for these five areas were established in the pre-Agile phase, so no new high level documentation was produced when Agile was introduced, though they were refined in accordance with Agile principles. From thereon, though, the DSDM framework was followed as closely as realistically possible, based on a project analysis conducted using the Appendix B questionnaire in the Agile Project Management Handbook version 1.2.
Therefore, the project is fully focused on business needs, with frequent refining of requirements and prioritisation, all concentrated on what matters to the business.
Great emphasis is placed on prioritisation and MoSCoW is the prioritisation approach we used, both at a high level and at the detail of how scarce developer time on any given occasion can achieve the greatest value at that point. “Everything in the project that can be prioritised is” is almost a mantra.
Iterative development and incremental building of solutions became the norm, with frequent releases – including part-finished solutions if they offered user value – and plenty of early testing.
Every effort has been made to map actual team roles against DSDM roles, from the business sponsor and business visionary to business advisors and developers. This enables roles, responsibilities and escalations to be clearly defined and observed.
Quality is never compromised and is managed by setting quality criteria for each deliverable and then maintaining constant dialogue with developers, followed by plenty of testing to establish fitness for purpose. However, setting criteria can be a challenge as those on the business side often fail to see the need for specific criteria, so overgeneralise.
Communication approaches that are particularly effective include facilitated workshops – proven as the most efficient way of gathering consensus when several sides are involved – and modelling of solutions, including mock ups, workflow diagrams and tutorial videos, all bringing proposed solutions to life and helping users understand what it is they really need.
Meanwhile, risk (threats and opportunities) is managed through risk and issue registers, a decision log and a change request log. It is felt that the DSDM approach has reduced the negative risks, compared with the project’s pre-Agile iteration, because of better business involvement (the business feels the benefit of not having to know exactly what it wanted at the start) and better senior management engagement.
Conclusion:
This project has a long way to go, so of course it is too early to observe all elements. However, early indications suggest that the DSDM Agile Project Framework appears to be providing a number of important benefits, including greater management confidence and support, techniques for managing resources most effectively, a focus on delivering what the business really wants and an adherence to quality outputs with negative risks minimised or mitigated, all without the involvement of external providers.
The DSDM Agile Project Framework appears to be providing a number of important benefits