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:

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 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

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.

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

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.

Principles

• A small team working closely together in 1-week sprints
• Develop usable learning materials early and test with learners and Excedo stakeholders
• Everyone on the team takes individual and collective responsibility for doing whatever is needed to meet the goals of each sprint and to deliver a publishable course

Meetings

• Storyboarding workshop: start each course with an in-person two-day workshop to map out the course at a high level and come up with content ideas.
• Sprint planning: start each sprint with a half-hour team call to agree on and commit to our goals for the week, and decide how we’re going to achieve them and who is going to do what.
• Daily standup: 15-minute call every day for the team to check in together, with each team member updating on they got done the day before, what they plan to get done today, and what potential issues or blockers might get in their way.
• Sprint review: look back at what we’ve delivered during the week.
• Sprint retrospective: discuss how the process worked during the week, and come up with suggestions for making the next sprint run more smoothly.

A storyboarding workshop

Tools

• Slack for messaging: the central nervous system of the project – a chat channel for the team to raise questions or issues and solve problems together.
• Trello for tracking day-to-day progress and project-wide view: an easy-to-interpret visual overview of project progress.
• Google Drive for all documents, so we can work collaboratively
• Google Hangouts for meetings
• EdApp – the authoring tool and LMS that Excedo uses to create the mobile learning content.

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 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.”

• A small team working closely together and communicating every day makes projects run better. We found that people were happy to pitch in as necessary to do what we needed. There were no ‘silos’ with people saying ‘that’s not my job’. Not only did people enjoy the work more, we were more efficient and effective, saving time and money for the project.
• Getting everyone together in person for the storyboarding workshop at the start of each course made a big difference – in terms of team cohesion, and also in that it meant that the whole team co-created the shape of the course. This meant everyone felt a sense of ownership, and that there was no need to put together detailed writer and editor briefs.
• Having people working part-time on a project like this can be difficult – given the intensity of focus during the sprints, it really helps if the project is someone’s main focus and if they’re available to work on it every day.

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”

• Working in sprints makes things feel much more manageable when you’re faced with uncertainty. Sprints can help make a complex project feel less overwhelming, as you only need to think about the current sprint goal – e.g. “Write and edit the first draft of module 1”. But it was a new and sometimes unsettling experience for some and the process can make things feel a bit fragmented. It’s easy to forget about the bigger picture of the course content and how it all fits together when you’re only thinking in one-week blocks.
• Daily standups were almost universally popular – they really helped everyone feel part of the team; and they also kept everyone in the loop on where we were; and meant that issues could be addressed as soon as they came up rather than building up into bigger problems. During every sprint, often many times, we had someone raise an issue and someone else is the team was able to suggest a solution or offer to help out. A daily standup is a big commitment, and at times may feel like overkill, but it really does make a difference.
• Empowering the team: Everyone on the team was very experienced, so we were able to rely on them self-managing to a large degree in developing the content, which is exactly what we wanted. With a less experienced team, more guidance and support and more detailed briefs would have been needed. Despite the team’s experience though, it was still an adjustment to get used to taking a more proactive approach rather than waiting to be told by the project manager what needed doing.

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.”

• We needed to develop processes and documentation as we went during the first course. This was then re-used and refined in the next courses. The fact that it was developed in response to specific needs meant we only created what we needed – maximising the amount of work not done and preventing us from getting bogged down in unnecessary systems and processes. But, of course, this experimental and emergent approach did mean missteps and things going wrong. In the end, that felt like a price well worth paying.
• As we went, we developed a ‘playbook’ – a short document setting out the core processes and linking to templates. This was a 37-slide deck that could easily be read and understood in half an hour.

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.”

• More and earlier feedback from learners and stakeholders would have made things even better. In fact, getting timely and regular feedback was one of our biggest challenges. Given the short timeframe for each course, a delay of just a few days in getting feedback meant that we’d developed quite a lot of new content that might then need reworking. User feedback is likely to be the biggest challenge facing any publisher attempting to truly adopt the principles of Agile in a project – and is likely to be the element of Agile that gets neglected, even though it’s possibly the most important of all.

Conclusion

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.