Going off-road - Research infrastructure and data

How the Jisc Open Research Hub team uses iteration and minimum viable features to keep the service agile in a rapidly changing environment

What’s more annoying than setting off on a journey and getting lost?

Setting off on a journey with a map and still getting lost…

When there are many possible ways to get to your destination, and all your passengers have a different opinion about how to get there then the map has gone from pristine wayfinder to Rorschach inkblot. What if opinion changes about where to go; must all routes be recalculated? Even worse, what if there are eight of you and all you have is a bike?

Welcome to the agile product roadmap, a tool which tries to please everyone, yet can also end up pleasing no-one. However, and somewhat counter-intuitively, it can also be the defining factor in making the development of a product as responsive and market efficient as possible.

During the large and complex Jisc Open Research Hub (JORH) project, this roadmap has been an essential tool, used by everyone from developers and strategists to customers and committees, to make sense of how we move forward, and in what direction.

Strategy is a bumpy road

JORH was first conceived as part of the Jisc Research at Risk programme, which set out to help create a robust and sustainable research data management infrastructure and services to enrich UK research. At the time, HE institutions were under pressure to comply with new requirements to make data outputs publicly available. Sustainable infrastructure was a big deal. The initial expectations were set out in 2011, with clarifications in 2013. For some research outputs, access was mandated from 2015 – researchers and institutions had to adapt (in infrastructure terms) fast.

This was one of the problems from the off: research data management is still evolving with changing demands on those who need the service the most. Infrastructure takes time to build, and in the process of that build, sector issues change. Sector priorities such as the REF shift focus from data onto publications, where the requirements of publishers and Open Access initiatives such as Plan S hold sway.

This left JORH with a relevant, but incomplete brief. The potential change to the strategic direction of the product pushed it into ‘pivot’ territory: where the addition of a suite of features changes it into another product. A pivot can disrupt the existing development roadmap and demote the current priorities. Sometimes a change of direction is desirable, but, if it doesn’t follow incrementally, a pivot can undermine the maturity of the work that has already been done. Worse, this could be perceived as panic or a lack of vision. When strategic direction detaches from the requirements then the product never really arrives into the market.

Use cases and flex

To avoid this, use cases are key. For JORH, these were gathered from researchers and research support staff from over 70 UK universities and refined by Jisc, working closely with 16 institutions. This process defined the Minimum Viable Product (MVP) required.

The MVP is a working product with just enough features to satisfy early customers, and to provide feedback for future product development. For JORH, minimum didn’t mean simple, as requirements came from different types of university at different stages of maturity around research data management. JORH is, technically, three services – repository, preservation and reporting. Whether or not an institution had some of these capabilities already, the product still had to be defined for any user, meaning multiple use cases across multiple development pathways.

However, over a period of two years, as mandates came into force and institutional priorities changed, there was inevitable scope creep. This undermined the original work, even though it was based on solid, well refined use cases. Eye catching functionality disrupted the focus on the initial features, which remained embryonic in the MVP.

As this wasn’t enough, there were technical choices made, driven by economy and sustainability, that meant the core repository offering from the service had to be built from scratch. But with the churn of requirements in use cases threatening to turn into a tsunami, how did the team go about building a repository that wasn’t immediately washed away?

Your feature is (currently) a skateboard

The answer was to make everything agile. Not just the product but the features in the product. The team developed an approach based on the concept of the MVP but going more granular into the very features themselves. We called it the Minimum Viable Feature (MVF).

To explain further we need an example, one which many agile fans will be familiar with:

This is Henrik Kniberg’s classic depiction of agile product development (and it’s verging on mandatory to include this diagram…). Rather than focus on big bang delivery – everything is done, everyone is happy (impossible if user requirements are changing) – the product is developed incrementally. Each iteration is an individual testable unit that works.

Consider the road metaphor from the introduction. Rather than waiting for the car to get you from A to B, start simpler, but with something you know can make the journey. The skateboard won’t be for everyone (“I travel long distances. I need an engine!”), but it works.

This is key for agile product development. You’re not going to start with the Rolls Royce version of every feature in the product. It takes time and effort to get to stage 5; those who really want the car will wait. But, as we know, circumstances and priorities change, so maybe the bike will do instead of the car. Users can come onboard when it fits their requirements. Some want luxury. Others are happy with the basics. By making a feature iterative, the JORH team can develop any part of the service according to greatest need, or value to the largest audience. Most importantly, the team can learn directly from users through testing. This is how we can compensate for changing use cases and priorities, and why iteration solves that problem.

Single sign on vs ORCiD

Let’s take authentication as an example. User requirements from the university sector draw a red line around Single Sign On (SSO) – the authentication process already embedded into student and staff practice at all HEIs. This makes sense as customers are already familiar with it. But there are also researchers who use ORCiD, a personal ID that connects the person to their organisation (not necessarily a university) but also to any research output they have produced that is associated with that ID. Plus ORCiD is global.

So SSO is more common, but ORCiD does more and has a wider reach. However, SSO was the priority for JORH because it’s a UK sector requirement: it must be there. This means the team tackled SSO authentication first, even though some customers needed something else. Authentication with ORCiD is a nice to have (for most) and adds product value when it happens but it’s not the first step in getting authentication from A to B. SSO is the dependable family saloon; SSO + ORCID is the Rolls Royce.

Be 1:50,000

Alas, this approach undermines the traditional roadmap. If features, let alone the overall product, are developed incrementally, agile and subject to change, how can you convey the development plan to the audience?

The need here is to be high level. Taking detail out of a roadmap can be frustrating for users but it also avoids unnecessarily over-promising or under-delivering. A continuous prioritisation process pays dividends: options for development can be offered to users and their preferences acted on.

Feedback from the sector highlights the need for delivery times for new releases to be clear. Within these cycles, development can be more fluid. If a user wanted the car and it’s still only a bike then they won’t be getting onboard. But by mapping out the possible increments of delivery for any given feature, a customer can see how far away any part of the product is at any given time.

Getting there

In the course of this article, there have been a lot of metaphors around journeys and transportation. It never does to take a metaphor too literally, but here the language and imagery are useful.

For customers, the idea of a product that progresses, matures and changes makes sense in a world of quickly changing priorities and shifting economic and political landscapes. What we do is use development strategies that suit these dynamics, and seek to find the best course at any given time. Getting there is never a smooth journey but we’ll get there nonetheless.