Three months …
In what will be a series of posts, we’re going to look at how we might do things a bit differently in the world of ELT publishing.
Making ELT products takes time. A lot of time. Too much time. And in the current climate, we can no longer afford to think about product development in terms of years; the rest of the world is moving too quickly for that, and if we don’t catch up, well …
So at ELTjam, we’ve set ourselves a challenge. If we wanted to produce an ELT 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’re going to explore this idea by looking outside of ELT and outside of publishing, starting with this post on what ELT publishers could learn from Agile software developers.
The Agile Manifesto
We are uncovering better ways of developing ELT materials by doing it and helping others do it. Through this work we have come to value:
- Individuals and interactions over processes and tools
- Working ELT materials over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
These words, with a couple of choice edits, are the Manifesto for Agile Software Development. Written in February 2001, the manifesto defines an approach to creating software. In the quote above, I’ve substituted the words software for ELT materials, and it reads quite nicely, I think: a fuzzy-feeling manifesto for what ELT publishing might be. Because the reality is that ELT publishing isn’t really like that at all.
But what if it was?
What agile development is (not)
For those of you unfamiliar with agile software development, it can probably best be understood by what it’s not, and a good example of what it’s not is the process whereby an ELT coursebook is produced. Here’s how that typically works:
- A publisher identifies a market need or a gap in the market.
- Requirements for what kind of product would best satisfy that need or fill that gap are gathered.
- A product spec is worked up and budgeted; sales forecasts are made; an author or author team is found; a proposed publication date is set.
- The project is green-lit by the powers that be, and budget is approved.
- The authors begin writing, often quite large chunks of the book at a time. The editorial team give feedback. Second, third, fourth, fifth (sometimes!) drafts are done. The manuscript is finally considered ready to be copy-edited and handed over to production.
- Once in production, there’ll be four or maybe five proof stages. At each stage, text corrections will be made, content problems will be ironed out, artwork and audio will added. Eventually the book is considered ready.
- The book is then sent off for printing, and woe betide you if it isn’t pretty much 100% perfect by this stage; we’re about to produce tens of thousands of copies of it, copies that will arrive a few weeks later in the warehouse.
If you don’t work in ELT publishing, how long you think steps 1–7 above typically take? Three months? Six months? A year? If you got all that done in a year, you’d have done a pretty incredible job. Oh, and by the way, that’s for one book or one level of a series. How long do you think it takes if you want to do a multi-level, multi-component course?
The steps above are an example of a waterfall approach to product development: sequential, tightly regulated, with progress through the project flowing downwards from one phase to the next. And it’s always made perfect sense in book production, because waterfall development comes from the manufacturing sector, a sector where you have to actually make a physical thing. It’s a process that’s suited publishing because we, too, have always had to make a physical thing – a book.
But it’s not without its problems, one of the main ones being that the first time 99.999999% of your customers see your product, it’s finished. And you can’t really change it at that point, because you’ve printed tens of thousands of copies. And what happens if no-one likes it? What if you kind of messed it up and didn’t make the right thing? What if no-one wants to buy it?
The agile way
Software developers don’t make a physical product, so they do things differently. They do things the agile way. To describe an agile project, the key adjectives would be iterative and incremental. Agile software developers don’t believe that you can ever fully understand what the true requirements of a product are at the very beginning of its development; the only way you can really drill down to what the customer needs, and decide whether what you’re building will actually fit that need, is to build it, test it, get feedback, adapt to the feedback, do another iteration, test it, get feedback, adapt, etc., etc. If the requirements of the project keep changing, then great! It’s a sign that we’ve put the customer at the center of the process and, in theory, means we’re getting a better understanding of them; it means we’re creating products which people really need and which work as well as they possibly can.
A number of different methods are used in agile development, but a few are common to nearly all projects:
- Each product has a Product Owner, a person whose responsibility it is to understand and articulate the interests of the project stakeholders. The key stakeholder is usually the customer who we’re making the product for.
- The project team work in short iterations, often called ‘sprints’, in which they develop a working version of the product or some element of it. A sprint typically lasts between a week and a month. After each iteration, the product is presented to the key stakeholders so that changes can be made to later iterations. In theory, by the time you’ve ‘finished’ your product, all the key stakeholders know exactly what to expect of it; there should be no surprises, and they should all be very happy with it.
- During a sprint, the project team works closely together, and there is daily collaboration. This often takes the form a the ‘daily stand up’ meeting, a key element to the agile development process. The daily stand up is just what it sounds like: a meeting where everybody stays standing up. The intention is that it lasts no longer than 15 minutes. During the stand up, each key member of the project team has to answer three simple questions:
- What did I accomplish yesterday?
- What will I do today?
- What obstacles are impeding my progress?
It’s a brilliant, simple project management tool that I’ve been trying to persuade publishers to take on board for a while now, with mixed results. It seems the fear of a very short daily meeting outweighs the reality of much longer, less frequent but less productive meetings.
As ELT publishing moves into a digital age, our methods need to change, too; what worked for the manufacture of a print product for hundreds of years might not be best suited to a world where digital product is leading the way. So is a version of agile development workable in ELT publishing? If so, could it cut down on development times and costs? And could it deliver ELT products which better suit teacher and student needs? I think the answer is yes, and this is how it might work.
Let’s imagine that I work for Publisher X, and I spot a problem that I think we can solve. Let’s imagine that problem is that the state universities in Country X are about to switch to English-language tuition. The problem is that most of the academic staff don’t know how to lecture in English. I decide that we need to provide a solution that will help university teachers in Country X lecture in English with ease and confidence.
My first step would be to learn as much as I could about university staff in Country X and the exact issues they’re facing. Is the problem that their general level of English is too low? Is the problem that they don’t know the technical language in their discipline? Is the problem pronunciation or intonation? Every assumption like this would be tested until we had a list of what these people would require in order to achieve their goal – that is, to lecture in English with ease and confidence. Once we had those requirements, I’d decide on their relative importance. Once that prioritisation is done, we can start making our product.
I’d put together a project team, probably consisting of an author or two, a development editor, a copy-editor, a designer, an editorial assistant (for artwork research and text permissions) and an audio producer. We’d have a planning meeting and set our tasks for the first sprint. The objective of this first sprint would be to produce something that satisfied the most important requirements of the target market. Let’s imagine that requirement was to be able to use their intonation better when lecturing. That becomes Unit 1 of our course, and the focus of our first sprint.
How might the sprint look? Something like this maybe:
Author and development editor plan unit structure, identify possible artwork, discuss audio requirements, etc.
Author writes first draft; development editor does an initial brief for audio and artwork.
AM: Development editor feeds back on first draft.
PM: Author writes second draft; final artwork selection and audio brief is prepared.
AM: Designer creates units; audio recording and editing takes place.
PM: Copy-editor edits designed unit.
AM: Designer carries out final changes based on copy-editor checking.
PM: Final QA by development editor and copy-editor.
Is all of this achievable in five days? In some projects yes, in others no. If the answer is no, then you’d do a longer sprint, anything up to a month. But I’ve worked on many ELT titles where the above timeframe would have suited the complexity and scope of the content. And perhaps we need to be working smarter and producing simpler material so that this kind of turnaround is achievable. As one of the principles of the Agile Manifesto states: Simplicity–the art of maximizing the amount of work not done–is essential. Words to live by.
So what happens at the end of that first sprint? Well, you send your finished material into the market for feedback. Does it fulfill their needs? Does it help them solve their problem? Once that feedback comes in, you maybe do a second iteration of the same unit. What about now? Does it work better now? It does? Great. Let’s do another sprint, but this time we’re doing Unit 2. What requirements are we focusing on here? What have we learned from Unit 1 which will make Unit 2 smoother and better? And so we go on. With each sprint we understand our target market better, and we make better material for them. We constantly go back and revise, we always test and never assume, we put the customer (the teacher, the learner, whoever it may be) at the center of everything.
And let’s imagine your course ends up being 10 units long. That’s 10 weeks of development. In ELT publishing timeframes, that’s light-speed. And if you need multiple levels or multiple components? Run multiple project teams.
Would it work? Who knows. Maybe some of your are already trying it; maybe some of you have tried and failed.
I’m aware that for the sake of illustration I’ve simplified what are often extremely complex taks and concepts. But with some proper thought, so good planning, some guts and determination, could we change the way we publish ELT materials, and could that change have a real, tangible benefit for the students and teachers who use them? There’s only one way to find out.
For Part 2 by Laurie Harrison, go here.