Assessment & Feedback product and agile methodology

Assessment & Feedback product and agile methodology

Sadly Joanne Moles (Assessment Delivery and Platforms) will be leaving us this month. I’ve really enjoyed our adventures – both in and out of work! Joanne’s departure means that I will be taking on the role of Product Owner (PO) for the Assessment and Feedback (previously Digital Assessment) product.

The Information Services Division (ISD) at UCL runs its teams using the Agile Delivery Framework (AQF). This is a highly structured and comprehensive software development and delivery approach that serves a big institution like UCL well. It is a relatively new approach and was brought in by Chief Information. Officer Andy Smith during Covid. Earlier this year ISD won the UCISA Digital Transformation of the year award at the UCISA Awards 2023 for its Agile Transformation project.

For our external audience, and others in UCL who are not so familiar with agile, I wanted to take this opportunity to explain a little about how things work.

Product

A product is a defined by the World of Agile as “Something that satisfies a business need”. For me this definition is suitably hazy, it could be a particular service area or a platform. Currently in the UCL Education Domain we have the following products:

  • Digital learning environments (DLE) – this includes the Virtual Learning Environment (VLE)
  • Curriculum management
  • Assessment and Feedback
  • Learner Engagement
  • Media Environments

Other domains that we work with include student lifecycle and support and wellbeing – both are in the Student Experience domain. Other domains (grouping of product teams) are Research & Innovation Operations; People, Money & Insight; Digital Infrastructure; Campus Experience; Digital Research & Innovation and Faculty Operations. Domains are overseen by portfolio teams. All areas are evolving and the naming and categorisations are subject to change.

Product Teams

Product teams pull together a group of individuals from various places in ISD, or the wider institution, with the goal of taking forward their product. A team is likely to comprise of:

  • The Product/Platform Owner (PO) sets the strategic direction, articulates the vision, and maximizes the value of the product/platform. They engage with stakeholders, represent user voice, and provide guidance to the team.
  • The Agile Delivery Manager (ADM) is responsible for the day-to-day running of the team and ensuring all the team members have what they need to ensure delivery.
  • The Service Owner (SO) ensures the service meets customer needs and champions great customer service. They are accountable to customers and users, with a deep understanding of the supported product.
  • Service Operations Managers (SOM) are responsible for day-to-day service operation and successful delivery.
  • The Technical Lead (TL) is the most senior technical role with overall responsibility for the technical solution. They ensure reliability, integrity, and performance in both design and implementation.
  • The team supporting the product or platform consists of the above roles and may also include a Business Analyst and/or Solutions Architect.

Change portfolios will also have a sponsor at University Management Committee / Vice Provost level and a portfolio lead, as well as a Portfolio Delivery Manager, Portfolio Architecture Lead and Portfolio Business Analyst.

The Agile Calendar

Agile cadence works around a 12-week cycle (term) made up of 6 sets of two-week sprints. At the start of a term there is a 2-day Termly Increment (TI) planning event planning which all of the product team are expected to attend. Work is usually scoped out on a Miro board. At the start of each sprint there is a Sprint planning meeting, at the end of each sprint there is a Sprint review and a demo of any features delivered. The last sprint (out of 6) is an Innovation and planning sprint and gives teams the time to explore difficult areas, review deliverables and plan for the next TI planning. At the end of each term there is a Retrospective session for the team and an Inspect and Adapt session for the whole domain which involves sharing key metrics and overviews of work carried out. Teams meet in a daily stand up (usually 30 minutes) to discuss progress and issues. All work is logged on a Jira board. There are also two domain demos every 4 weeks and numerous domain sync meetings, along with meetings for POs, ADMs and others. There are quite a lot of meetings…

An agile termDuring this time product teams will deliver Epics (large changes), Features (to enable an epic) and smaller changes (to enable a feature). Each epic requires a Lean Business Case (LBC), we have just written our LBCs for next year and are witing to hear which have been successful.

Agile Principles and Behaviours

The Agile Delivery Framework (ADF) used at UCL incorporates elements of Scrum and the Scaled Agile Framework (SAFe). I’m not new to agile having used it in a previous job, but I’ve never used it to this extent before. Regardless of whether you are developing software or doing something completely different the principles and behaviours have much to offer. The key ADF principles are as follows:

  • Controlling to empowering
  • Projects to product
  • Order-taking to co-creating
  • Technology focus to user-experience
  • Doing the most valuable work every term

They are supported by an agile mindset: Enabling increased collaboration through cross-functional teams; encouraging fast feedback and learning in iterative cycles; focusing on delivering value to our customers; supporting continuous improvements; and enabling increased adaptability to change. The key agile behaviours are defined as follows:

  • Prioritise and sequence by value – “fall in love with the problem not the solution” – Uri Levine, hunt the value, always work on the most important area
  • Outcome focussed teams – see the bigger picture and measure the impact of change
  • Make work visible – make systems visible, work together on work and complete
  • Empower Decision Making – encourage collaboration, shared ownership
  • Small Iterative Deliverables – deliver iteratively not incrementally, reduce time for feedback loops

Training sessions are run to educated product teams on how these principles and behaviours can work in practice.

More information on UCL agile is available on the Agile Project Management site and ISD Agile Resource hub (internal only).