*Thanks to Erich van Rijn for sharing his experience applying Agile project management principles in journal publishing for Scholastica’s white paper “Iterate to Innovate: How scholarly publishers can use Agile methodologies to respond to change more effectively.” This blog post features the transcript of his interview for the paper, which is available here.*
In many ways, the rise of digital research dissemination and now Open Access has been cause to toss past journal publishing playbooks out the window — or at least large chunks of them.
While certain aspects of journal planning remain unchanged, such as disciplinary indexing milestones, others are becoming far more fluid. Few could have predicted how ubiquitous machine-readable metadata would become, leading to advances in machine learning that could impact the entire research lifecycle, or how funder mandates would necessitate business model transformations to accelerate OA journal development. Like a series of earthquakes in the scholarly terrain, such changes are causing rumblings within and even completely upending the most well-laid-out publishing plans and making it harder to project future infrastructure needs and revenues.
As a result, the Agile methodology, an iterative project management approach that originated in software development as a way for companies to become more responsive to the latest internet norms and technologies, is becoming increasingly applicable in scholarly publishing. As the name suggests, Agile supports flexible planning to respond to change factors.
The University of California Press is one publisher starting to incorporate Agile methods into its publication planning to mitigate risk while testing new journal models. We caught up with Erich van Rijn, Director of Journals and Open Access at UC Press, to learn how they are identifying opportunities to be more Agile.
Q&A with Erich van Rijn
In what ways has UC Press been looking to become more Agile in recent months, and why?
EV: In the past, when starting new initiatives, we tended to put a lot of effort into mapping out product plans and pricing models upfront, developing three or even five-year profit and loss statements. But with all of the changes occurring in scholarly publishing, we’ve learned a lot of that kind of effort can be wasted. It’s better to have a publishing infrastructure that supports standing up new products relatively quickly. You want to make investments in just the core areas needed to get something off the ground before putting too many eggs in that basket or trying to predict where it will lead. Even in the span of three years, you’ll likely be headed down a different road than you thought.
Of course, there’s no excuse for bad planning. Planning is important for everything, and Agile requires planning too. For example, when launching a medical journal, you have certain milestones that you will always have to hit. You need to recruit an editor, recruit an editorial board, and get indexed in PubMed. Where Agile comes into play is leaving room to adapt to the needs of the market. Agile is about staying open to adjusting or even totally changing the vision of what your end product is going to be. These days, you have to be willing to change.
Can you give an example of how you’re implementing aspects of the Agile methodology in journal planning now?
EV: A recent example is how we’ve been approaching the launch of an OA trans-disciplinary global health research journal called Advances in Global Health. When our team initially approached the project sponsors, we had certain development ideas in mind based on past publications. But since then, the editorial team has had a lot of energy around framing the journal around promoting the UN Sustainable Development Goals and really focusing on incorporating voices from LMICs at all levels of the journal’s operations. These are both exciting directions, and I don’t think that’s something anyone would have anticipated a year ago when our conversations about the journal started, but it’s a direction I see the industry beginning to move in from sessions at events like the ALPSP conference, and obviously one well worth pursuing. To realize their editorial vision, we know we’re going to have to make some adjustments to how we see the business model of the journal unfolding, so we’re working to not make too many assumptions. That means we can’t plan as far ahead as we would have for new journals in the past, but I know that if I tried to push the editors to follow our initial publication plans, we would be stuck in the mud right now.
If we find that this new journal approach isn’t working, we’ll have to make some adjustments and decide whether to keep going in the same direction. Having a strong relationship with a journal’s editorial office in which there’s a high degree of trust and collaboration can help when it comes to rapid iteration.
What is an example of a past project where you think implementing aspects of Agile project management would have been helpful?
EV: In the past, because we focused on mapping out plans three and even five years in advance, I think we were somewhat resistant to incorporating feedback into our product development if it ran counter to what we’d decided. For instance, when we started Collabra as a mega journal, we developed a plan around the idea that people would be more incentivized to peer review if they were paid for it. As we were developing that journal, when we encountered researchers saying they were not interested in getting paid to peer review because they saw it as a professional obligation, we tended to dismiss that feedback because our whole vision for the product centered around putting a percentage of APCs into a fund people could lay claim to via a points system either to get paid themselves or give money back to the community towards APC waivers. If we had acknowledged feedback that getting paid doesn’t matter to many academics, we could have pivoted earlier to focus on the more important aspect of our idea, putting a portion of APC revenue into a waiver fund. That’s something we learned and are now implementing across all of our OA journals that I think we could have acted upon sooner. I think the risk you take when you plan any product too far ahead is you can end up building a pretty significant infrastructure around a specific idea that may still need some tweaking and will certainly be subject to change.
I think, for better or worse, building out extensive technical infrastructures for particular ideas is a common scenario in scholarly publishing because it’s such a niche industry. The pool of partners for publishers to work with is pretty small, and it becomes a bit of an echo chamber because there is a finite number of people chasing your business, and many of them will accommodate your requirements if you pay for it. I think that’s a bit of a problem because it front-loads project planning without leaving room for agility. It also means that getting new products to market can take a long time because it often requires going through an RFP process to identify vendors who are interested in doing what you’re looking to accomplish. And, with the rate of change right now, by the time you get an idea off the ground, it may not be as relevant as you thought it was a few years before.
How important do you think team motivation is when implementing Agile project management principles?
EV: One of the most important things in early journal development, particularly for pilot projects, is getting the right editorial talent. If you have an editor who has a strong vision, a strong network, and commitment to the publication, I think that definitely plays into being more Agile. You really need intelligent and committed people who are willing to iterate and change to succeed. If you drag somebody kicking and screaming into trying something new, it’s not going to be successful.
One point that a former colleague made is when you’re starting any project, you have to go into it with some sort of vision of what you want to accomplish and be willing to iterate from there. If you start out with the seed of an idea, get people excited about it, and then let it grow from there you have the opportunity to have a winning project. I think getting early buy-in from the people you are going to work with, and also making them feel like true partners in the project development is key.
Where do you think publishers have to make the biggest adjustments in project planning and execution to become more Agile?
EV: One of the challenges for university presses is we often expect sustainability too early in product or business model development. Ultimately, you have to give new initiatives space, and that can be frustrating in a business like publishing that is driven by scale. Most of us are used to tried and tested processes that sort of hum along. Being Agile doesn’t mean reinventing the wheel for every project you do, but you have to be willing to change things up and tolerate some messiness.
Of course, you don’t want to set up bad behavior where anything goes. Ultimately, you have to establish some rules of the road to make sure projects are successful, and a lot of that boils down to doing project retrospectives. Different organizations have different names for these, but ultimately, it’s about revisiting a project post-launch to break down where you succeeded, where you didn’t, and, most importantly, what you learned. I think often people can become wary of admitting any kind of failure, but if you haven’t failed at anything, that means you haven’t learned anything either.
I think one of the things publishers have to work on is being more dispassionate in decision making and instead relying more on data. When you plan based on data, it’s a lot easier to pull back and see when certain assumptions you made may not be right. In the old subscription ecosystem, it was easy to determine whether something was working or not because it all came down to whether it was generating subscriptions. But in an OA publishing ecosystem, all of the data points are changing, and we’ve got to change how we’re evaluating the success of different products.
Early in any project, you need to ask, “What type of data and feedback do we need to guide our planning, and how easy or difficult is that going to be to get?” I think finding more efficient ways to consolidate and track data is one of the biggest problems to solve in the publishing industry. Some large publishers have built internal data warehousing and systems capacity to make granular information available in a couple of clicks, but smaller organizations haven’t been able to do that really.
Do you think the Agile methodology has a place in scholarly publishing long term?
EV: I like to think of Agile as having a home in the publishing process. That doesn’t mean Agile planning in publishing will ever necessarily move at the speed of software development. But I think the idea of responding to external feedback and iterating based on that feedback is a useful methodology for publishers. Again, planning ahead is still important, but being able to iterate is becoming critical. You have to be willing to redo certain things and revisit assumptions. All of that is inherent in sprint-based planning and prioritizing and other Agile methods. So I think Agile has a home in publishing, but how rapidly publishers can manage Agile processes will vary depending on their combination of internal resources and external partners.
