Since 2013, we’ve evolved from a blog to a learning agency. But what got us fired up to start in the first place was our interest in tech, startup culture and new ways of working — and how these could be brought into educational publishing and the development of learning solutions. This is something that’s still really important to us in the work that we do for our clients.

One example is Agile – the standard approach for running software projects and developing tech products – but in our experience still not used much in publishing content development when done at a large scale.

This post is about how we recently applied the principles of Agile to a large course content development project.

The problem

Courses from publishers often take years and millions of pounds to develop. The publishing process usually looks a bit like this:

a non-agile approach to product development

Each of these stages is clearly separated, often involving different teams of people and taking months or years. There are two big issues with this approach. First, a lot can change in the time it takes to do all of this. Second, by the time 99.99% of potential customers see the end result and get to decide if they’d want it, you’ve finished the whole process.

If you’ve got it wrong, there’s nothing you can do about it. So, although extensive and detailed planning and a carefully staged step-by-step process sounds like a sensible approach, when you’re investing a lot in a new product, it’s actually a very risky approach.

Agile sought to solve this problem in the world of software, and we’ve always felt that it ought to be possible to bring about a similar change of approach in educational publishing.

The promise of Agile

In 2013, Nick Robinson and I published a couple of blog posts on Agile publishing, setting out this challenge:

If we wanted to produce a coursebook series in three months instead of, say, three years, how would we do it? Could we even do it? What would have to change?

We then described a possible model for how the Agile project methodology could be used to develop learning materials.

The basics of the Agile approach are:

  1. Watch your users working / learning and talk to them to really understand their problems and needs.
  2. Work out what you think your product (or course, or materials) needs to do in order to help them. Prioritise those things according to the positive impact they will have. This prioritised list is your backlog.
  3. Work in sprints (short bursts of focused effort, typically two weeks long) to develop your product in increments, with each sprint focused on the highest priority features from the backlog.
  4. Test the output of each sprint with your users and learn from their responses. Check and the update backlog, then move on to the next sprint.
  5. Continue the cycle, working iteratively, until you have a launchable product that’s been road-tested during development.
The basic principles of the Agile approach.

The fact that you’re working in small increments and adjusting as you go means you can adapt and handle change without it derailing your project. You can also avoid the risk of wasting the entire investment of time and money. Up-front work developing detailed plans and specifications and setting up complex processes to manage a project could well be wasted effort, and we’re big fans of the lean concept of minimising the amount of work not done.

How it works in practice

Each sprint starts with a sprint planning meeting, where the team themselves decide what they’re going to do and how. Rather than imposing complex processes, the idea is to empower the team to work together to find the best way to do things.

At the end of each sprint, the results are shared with users and other stakeholders. Their feedback is used to help plan what’s done in the next sprint. The team also carry out a sprint retrospective to look at how things are working and come up with ways to do things better in the next sprint.

The product develops in a way that takes user feedback on board throughout – and the process itself is constantly improved based on what the team is learning. This should mean better products, developed more quickly, and happier project teams. And a much lower risk all round.

In our 2013 posts, we suggested that Agile publishing should involve a close-knit team (writers, editors, a designer, audio producer and others) working in sprints to develop a coursebook series in increments (e.g. a double page spread or a unit at a time). This would mean a different approach to content itself, as well as the process – keeping it simple, and then adding to it with more expensive artwork, more audio or video only once we have some evidence that we’re on the right track.

Over the last few years, we’ve used Agile on a lot of projects – building apps for publishers, developing prototypes for new product ideas, developing a learning platform for a chain of schools, developing training materials for tech companies. But until last year, we’d never had the chance to use it for developing the content of a big course that was part of a multi-million-pound corporate enterprise with fixed deadlines and investment, an ambitious business plan and revenue targets (not a very Agile-friendly environment). Enter Excedo.


Excedo is a new company and product from Nikkei and the Financial Times. It plans to provide a multi-level business English and communication skills mobile learning course with online live classes. We’ve been working with them for a while to help develop the product spec and produce courses.

Developing products with an Agile appraoch

The challenge we were set

Each level of the Excedo programme consists of 10 short courses of about 10 hours-worth of learning materials – self-study lessons to be done on the learner’s phone, collaborative peer-to-peer activities, and lesson plans for small group live classes done via video conferencing.

When we started working with Excedo, the first courses took about 12 weeks each to develop and were pretty labour intensive. Scaling up course development to the level needed to have a multi-level programme on the market quickly was going to be really challenging – but had to happen somehow.

Excedo were already following some of the principles of Agile, but they wanted to push the Agile approach further, so they challenged us to do what we’d written about in our blog posts and develop some courses using a more Agile approach.

Our aim was not only to develop courses, but to also build a process that would enable a lot more courses to be developed in future. And most importantly, have a mechanism for both stakeholders and users to review the courses as they were still being developed, so we could be confident they were going to work before we’d actually finished them.

So, we agreed to put a team together and take on the challenge of developing publishable courses from start to finish in only 8 weeks per course. The team had no prior knowledge of the project and although we were familiar with the project and the course spec (and had been briefed on the processes used by the in-house team), we had no in-depth knowledge of the content approach and the ins and outs of developing it.

Given how much we had to find out, we decided to work in one-week sprints. The first course would be used to develop a basic process from scratch, and we’d then refine it course by course, until we had a ‘well-oiled machine’ by the end of the year.

We and Excedo believed that a course in 8 sprints was definitely a ‘stretch goal’, but it seemed like it ought to be achievable. If it was harder than anticipated or things changed during development, then it was going to need more sprints. Excedo were happy to go with this plan, even though it meant more cost if we did need more sprints – and we were pretty sure the first course would need more sprints.

I think it’s this willingness to accept a degree of uncertainty that’s unusual. It’s probably why we’ve never had the chance to work in this way on such a big project before. Usually, when outsourcing a project like this, an organisation would insist on specifying exactly what they expect to get in return for a fixed amount of money and by a specific date. This essentially rules out Agile. If this process worked though, the benefits for Excedo in terms of speed of development (and therefore improved time to market and cost savings) would be enormous.

How we did it

The core team for each course consisted of two writers and a content editor. We had a project lead (me) and a project manager overseeing all courses. We also had various other people available to support. Ideally, we’d all work in the same place, but we’re talking freelancers here, so we had to work as a remote team – something we’re very used to (and this project was pre-COVID). None of the team had ever worked on an Agile content project before. This backed up our hunch that this way of working is still extremely rare (or non-existent) in big publishing projects.

Our agile course team

Our Agile course team

In terms of process, we started with little more than a set of principles, regular meetings and the tools we were going to use. Everything else would be developed as we needed it.



Laurie giving a storyboarding workshop

A storyboarding workshop


Useful tools

How it went

It was hard, but everyone found the experience positive and enjoyable. Writers and editors worked side by side (virtually, using Slack to stay in constant contact) to develop the content collaboratively in Google docs before moving it into the EdApp authoring tool.

We put in placeholder audio and photos as we worked so that each lesson of content could be reviewed and tested as working materials. The content was built up module by module, rather than the traditional approach of planning it all, then writing it all, then editing it all, then authoring it all and then carrying out QA.

The fact that we were constantly producing usable materials was highly motivating for the team, and helped to give us and Excedo the opportunity to see how it was working before everything had been written.

Did we manage to produce a decent course in 8 weeks? Not quite – it took 9 weeks for the first course. But it was publishable quality, fully copy edited, with final artwork and photos in place, and audio and video scripts ready for production. The pace felt manageable – everyone was working hard, but there was no burn-out and everything felt under control. And we’d learned a huge amount from the first course that would make the next courses better, as well as quicker and easier to develop. In fact, the next three courses were each done in 8 weeks, with the last one being clearly the best, and no late nights required to get it finished in time.

By the time we did get to our fourth course, we had a stable workflow where we knew what we were likely to be doing in each sprint, so could plan ahead. The important thing is that we’d arrived at this workflow based on what had actually worked – if we’d tried to come up with something as part of an early planning stage, it would have looked different and wouldn’t have worked as well.

The agile process we used

The workflow we arrived at by the time we got to course 4

What we learned

As we worked, we captured lessons learned, and we regularly asked the team members for feedback on how it was going and how we could improve things. Here are some of the main things we learned, including some quotes from team members.

1. A small close-knit team makes for a better project

“There is a nice feeling of teamwork and I get the impression that my contributions are valued.”

“I like it – it feels like a positive feedback loop – it is much more collaborative and supportive than I am used to.”

“The standups really help because writing can be isolating.”

“Daily standups help to improve channels of communication (permission to speak out). Helps with motivation – very clear and needs to be done before end of tomorrow.”

2. Adopting new ways of working was a big adjustment for the team (but overall positive)

“It is an interesting project with interesting content – it’s definitely a steep learning curve though”

“Lots of platforms were new (Slack, Google docs, Trello, Ed) and it can be a little overwhelming to begin with”

3. We didn’t get it right the first time, but our approach evolved throughout the process

“Getting things done quickly caused some headaches later on.”

“Lots of things that were annoying have been worked through.”

“It has been up and down – we are only getting better so everything is becoming easier. People are more aware of what they need to do.”

4. Getting user feedback is the biggest challenge

“There were inevitable frustrations – not sure what Excedo are expecting, the project is in a state of constant flux. I was often left wondering how this should be.”


I’d describe the process we ended up with as ‘semi-Agile’. That is, we used certain key principles and processes taken from Agile, but adapted in a pragmatic way to a publishing context. As we developed more courses, the process and the stages we followed became more stable, and by the time we got to course 4, we knew with some accuracy what we’d be doing in each sprint, so were able to plan ahead more.

But it was only by adopting a highly flexible and incremental approach at the beginning that we were able to get to that point so quickly. Not only were we able to develop our first course from scratch in only 9 weeks, we also developed a process based only on what worked in our context.

We did not decide beforehand how to develop courses based on an abstract project plan or on our experience of other (very different) projects. Instead, we worked as a team to incrementally improve things. As a result, we formulated a repeatable way of developing high-quality courses extremely rapidly, in a way that could then be standardised and documented. This meant that scaling things up with multiple teams working in parallel was now completely achievable. Even so, it’s vital not to stop the process of continually improving how we work – no process should be set in stone.

Coming back to our 2013 blog posts, I don’t think a coursebook series could be developed in 3 months using this approach. But I’m completely convinced that it could be developed significantly faster than is the current standard. I’m also convinced that (if user feedback is deeply integrated into the process) it would result in a product better aligned to the needs of the teachers and learners it’s designed for, and that the team working on it would find the process more enjoyable and motivating.


Other related posts

See all

Our Learning Design process


6 insider tips for making a pro video on your phone