The Digital Services initiative commits us to: “Develop an improved service design and delivery approach based on agile processes and using multi-disciplinary teams, embracing the principle of co-production.”
As part of the Digital Services initiative, we have been developing a new Undergraduate Admission System in partnership with the Undergraduate Admissions team. As the university begins the admissions process for undergraduates joining in October 2016, the new system will be going live–replacing paper application forms.
The Undergraduate Admissions system is an early example of what we mean by taking an agile approach using multi-disciplinary teams. What has that actually meant in practice for the UG project?
- A member of the Undergraduate Admissions team (dubbed the Product Owner in agile terminology) was seconded to the project for its duration, and attends daily meetings of the development team.
- The prioritisation of work is the responsibility of the Product Owner, not the development team.
- Although we are only removing paper application forms from the system now, lots of functionality in the system is already in use. And ‘going live’ does not mark the end of the project.
- We can respond to feedback and make changes when the software isn’t quite right.
The Product Owner. Having an admissions professional working so closely with us on a daily basis helps us understand and stay current with the needs of the team; it also helps the Product Owner understand the pressures on the development team and how easy–or hard–certain tasks are to complete. We are never more than one day away from a constructive conversation about the issues that we all faced, and we feel like we’re facing problems together.
Prioritization. Asking the Product Owner to prioritise work means that we can be sure that the Admissions team gets the things they need in the order in which they need them. This ‘just in time’ approach ensures that we never write software that might not get used–because we’re always focusing on the most important task that is not yet complete.
Incremental Launch. Instead of waiting until everything was ready before any part of the system ‘went live’, we offered as much of the system as we could to the Admissions team for use during the current admissions cycle. Even though changing systems in the middle of an admissions cycle is difficult, there was enough value in the partially completed new system that it was worth using in the latter part of the current cycle. That helped build confidence in all of us that the new system was headed in the right direction.
Responding to Feedback. Because we aren’t stopping development immediately after we go live, the Product Owner can decide how best to prioritise further development. It may be that making a change to the live system is more important than developing a particular piece of new functionality–and they can reflect that in their prioritisation. The Admissions team need not feel like their on their own when the system goes live.
There are plenty of lessons for us to learn which will help us make co-production teams even more effective in the future, but we’ve already learnt that working in close partnership with our ‘co-producers’ helps ensure we deliver appropriate and effective systems and services.
We’re all eager to see how the new system works in the coming admissions cycle.