EDGE Development - Nicky Morris, EDGE Product Manager

Bringing new features to EDGE

Over the last month, we delivered our second release of the year. This was a significant release with a number of new features and enhancements. I thought this would be a good opportunity to share a little about how we build releases, explain our development process, and highlight how users can get involved.

How we develop EDGE

The EDGE team works using an agile development approach. This means we deliver regular improvements and enhancements through small iterations, focusing on collaboration, continuous feedback and incremental delivery, allowing functionality to grow and evolve over time. We follow a user-centred design approach to the build, involving users throughout the discovery, and design phases to ensure new functionality addresses real-world needs.

Our development backlog is shaped by several sources. Over the last month, we have been working on onboarding new Trusts, implementing recommendations from internal reviews and external penetration testing, and delivering improvements based on user feedback and discussions.

New 'My Saved Searches' functionality 

One recent example is the new 'My Saved Searches' functionality. We are beginning a programme of work focused on helping users stay informed about new studies in EDGE that may be relevant to them. Saved Searches is the first step in that journey, allowing users to save search criteria and receive notifications when new studies matching those criteria are added.

This is a good example of our agile approach to development. Our broader goal is to support users throughout the entire study engagement process - from discovering relevant studies through to recording expressions of interest and assessing feasibility. Rather than delivering everything at once, we are starting with the first step: helping users find studies more effectively. Future developments will build on this foundation.

Help shape the future of EDGE development

To support this process, we are looking at creating a dedicated space within our community forum where the EDGE team and the community can discuss ideas and help shape future development of the EDGE service. We encourage anyone interested in influencing the direction of the platform to get involved. More information will be shared in an upcoming user newsletter. If your an EDGE user and wish to subscribe, email us here.

Nicky Morris, EDGE

Agile Development

What does everyone mean

when they say Agile development?

You may have heard the Knowledge team talk about booking work into a ‘Sprint’ or discussing it in the ‘product backlog meeting’, so I thought it would be a good idea to sit down for a few minutes and explain what it all is, and why we describe ourselves as an Agile development unit using Scrum framework.

Companies have long employed development practices like Prince2 or Waterfall to create systems, but I find this a little restrictive, particularly when working in IT where the landscape and requirements change frequently. Agile is a project management philosophy that priorities early and frequent increments, allowing for changes throughout. Scrum is the framework that guides us through this. Scrum defines how we identify the work needed, who does the work, how and when it will be released. Agile and Scrum are a perfect partnership here, allowing us to be creative, regularly release updates and continuously move forward in developing EDGE.

We are always on the lookout for great ideas for functionality, these ideas form a list that we refer to as a Product Backlog. We can’t build everything at once so we make sure the Product Backlog is prioritized and under constant review so when we do meet with development, we know exactly what we want to build, how it needs to work and what should be done first.

While most updates are released monthly, internally we work on a two-week development sprint. Having a two-week sprint means our developers have a pretty good idea of what they can complete in the timeframe and this work becomes our sprint goal. The Sprint goal is set between our Product Owner and the development team. We agree this as a team, everyone is involved in the decision and therefore committed to the goal. We don’t have a lot of rules in scrum but there is one big one: The sprint is a locked event – no interruptions. As you can guess, interrupting the team mid-way through throws off their focus, leaves them less time for their original work and mild chaos ensues. It is probably one of the most difficult things for us Knowledge officers to do, we are always asking for “just one quick change?”, “just one little import?”. Anyway, that’s the rule and we do our best to stick with it.

At the end of the sprint, we have meetings which are called Reviews and Retrospectives, in short this is our chance to look at what we have achieved, make sure we are happy with it and for us to think about the sprint itself. Did we do everything we could, is there anything we would change next time? It’s this part where you see Scrum and Agile ideas blending again, the aim is continuous improvement. We aren’t going to try to build Rome/EDGE 3 in a day, but with small changes, tweaks here and there, and open discussions, everything keeps moving in the right direction.