Agile ELT (or, How to publish an ELT course in three months, Part 1)

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:

  1. A publisher identifies a market need or a gap in the market.
  2. Requirements for what kind of product would best satisfy that need or fill that gap are gathered.
  3. 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.
  4. The project is green-lit by the powers that be, and budget is approved.
  5. 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.
  6. 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.
  7. 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?

Chasing waterfalls

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:
    1. What did I accomplish yesterday?
    2. What will I do today?
    3. 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.

Agile ELT

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.

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

To finish

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.

49 thoughts on “Agile ELT (or, How to publish an ELT course in three months, Part 1)”

  1. having now worked on two projects where there’s been no real development stage, or at least not one I was involved in, and having completed first drafts of over half the content before getting feedback from an editor,I’d say this approach would have considerably speeded things up and wasted less of my time.I work fast,I need the process to work at the same speed.

  2. I unknowingly adopted the Agile way when I developed my English International VLE course (part of a research project). I had to do it in sprints, and the pace was electrifying but it was a responsive approach to my (albeit small) ‘market’, developing content to their specific needs. Digitally it was a good place to be, because I knew that my content could be tweaked and improved upon. I asked for and responded to student/teacher/institution feedback, scary to start with, we were all wary of what the implications were but it became a shared enterprise, a team effort, and we all felt empowered by the experience, but perhaps most importantly … it worked!

    • Thanks for the great comment, Miranda.

      Brilliant to hear that it worked out well. I like your description of the pace of the project as ‘electrifying’. I think it would come as quite a shock to anyone who’s never worked on a project like this before. It can get quite intense.

  3. Interesting thoughts, Nick. A couple of questions: 1) Do you think this could still work for print materials? 2) With the faster development times, you really need a bunch of people who are working on this project full-time if not in-house. Where does this lead in all of the work-for-hire vs. royalty issues? Away from royalties, I should think!

    • Thanks for the questions, Joe.

      1) I think it would be much more complicated, as the printing side of things is going to draw out the length of the process and potentially make it much higher-risk. I wonder, though, if you could still develop the material in the same way, sending out PDFs for customers to essentially pilot for you. At the end of the final sprint, you’d print a first edition of the book. It’d need a lot of careful planning, for sure.

      2) Very interesting that you bring up the nature of the team. One of the principles behind the Agile Manifesto is as follows: “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation”. There’s definitely an emphasis on having everybody located in the same space. That would obviously represent a huge change to how we work in ELT/ESL publishing.

      As far as royalties are concerned, I don’t think this would need to affect them at all; after all, there’s still a product to be sold and revenue to come in. What I think would change is the role of the author in the development of the project. Authors would need to defer to the Product Owner a lot more and trust him or her to make the right decisions on behalf of the people who are going to be using the product. Come to think of it, that’s a role that the author has often played up until now.

    • Joe – with regard to your 2nd point, I’d say you would ideally want the authors in-house, as part of the team. Isn’t it odd that it’s common in ELT for editors, production people, project managers, even audio producers and software developers to work in-house, but almost never content writers? It would be perfectly logical for writers to be in-house (and therefore, like everyone else, not on royalties). Given the trend towards ever more outsourcing, I don’t think it’s going to get any more common, mind you.

      • ‘Isn’t it odd that it’s common in ELT for editors, production people, project managers, even audio producers and software developers to work in-house, but almost never content writers?’
        Isn’t the argument that writers are ideally experienced in, and still involved in, teaching – which an in-house writer never could be (apart from the occasional evening gig to supplement a publishing salary)?
        Of course, a lot of ELT projects do use freelance editors at some stage, as in-house resources are limited. And a lot of in-house editors would tell you they ARE royalty-free content writers!

        • Well, it’s certainly true that some ELT books end up being partly written by in-house editors, although of course they never feature on the book cover or the royalty statements…

          I guess you could make the case that, in theory, using out of house authors means you can get your content written by practising teachers. However, I’m not sure what percentage of professional authors do all that much teaching? And almost all ELT editors are recruited straight from teaching, and generally have very significant teaching experience. Maybe it’s something to do with the office environment that’s not conducive to the creativity needed to be a good writer?

          It would be interesting to compare with other industries – is the main creative talent always commissioned on a project by project basis, or are there any remotely equivalent industries where the creative talent consists of in-house staff?

  4. A most challenging train of thoughts. I can’t wait to read the following parts.
    One of the crucial points of planning is to find and scale the market or let us name the amorphous mass, the Chimera (octopus, centipede, the Saviour you name it): The Customer. The Customer who, entering the bookshop, will grab your precious newborn and not the rival’s bastard (given the umpteenth facelift). The Beast who thinks that the world is perfect as it is, yet you will be able to awaken a yearning in him/her that s/he needs something more perfect. Your companion (your adversary) who is (or who is not) willing to co-operate in finding new ways of learning. To lend Seth Godin’s metaphor, who is your Tribe who wants to belong and who wants you to lead them?
    And, from a developmental perspective, who is the proper audience whose opinion really matters? This teacher or that? The kids? My students or the colleague’s? If I get a positive feedback from next door, should I believe in it? Should I restructure the whole material if I get a negative hint? It is good to have a pilot group or a bunch of advisers but I would not bet that they are an oracle of our success, neither be sure that they would be my real customers. (Oh, those reviewers who were so positive about our project but they never ever tried to use the final product in the classroom.)
    You might be right that with the dawn of the digital age the spectrum of would-be customers, the target groups and the amount of feedback can be widened. And, apart of those lonely moments at crossroads when you, only you (and some dedicated contributors) must decide which way to go, the Agile way can truly speed up the process.

    • Many thanks for taking the time to comment, Mihaly, and for doing it in such an elegant way!

      I think the issue you’re pointing to is probably too complex for me to respond to fully here, so I think I’ll make it the topic of a new post. Essentially, what I think it comes down to is, Who are our customers in ELT publishing? Because we’re in the very tricky situation of our final end user — i.e. the student in most cases — not necessarily being the person who makes the purchasing decision (or even hands over the money!). So you’re absolutely right: Whose opinion really matters?

      I need to give this one some more thought, so a lengthier response will be forthcoming.

      Thanks again for taking the time to comment.

      • Thanks for your reply Nick. You are absolutely right that your post here is about HOW and not about FOR WHOM to publish ELT materials. I am eager to read your forthcoming ideas.

  5. Representing a studio who design and produce mainly ELT material, this is an interesting concept. Currently, with the ‘waterfall’ approach, the production process is very long, studios are often in a minor role and the process usually involves multiple proof stages as editors adjust and correct as the projects proceed. If a more ‘agile’ approach was adopted, design and production issues would be ironed out much earlier for subsequent feedback into course development and writing, solving a lot of the problems that cause the current level of changes. I am sure working more collaboratively with studios in an agile way would save publishers a small fortune on correction charges as well as be able to get their products to market quicker.

    • Great to have some input from the design and production side of things, Mike. I’m hoping we’ll get the chance to test this out at some point in the not-so-distant future!

    • Totally agree, Mike. I remember when I started in publishing, I was shocked to discover there was a stage in the process called ‘handover’, when the manuscript was handed over from Editorial to Production. In my web development days, handing over work from one function to another happened regularly throughout any project. That still seems a more efficient model to me.

  6. An interesting and (as others have rightly said) timely post, and I’ll be interested to see the follow-up parts – Can I assume those will be written following an iterative and incremental model? In which case this and other comments here on Part 1 might be of more than just passing interest to Part 2?

    You’ve done an excellent job in drawing clear distinctions between the existing ‘waterfall’ approach with the ‘agile’ one but I think it inevitably raises a certain amount of skepticism (I’m something of a luddite it has to be admitted).

    My main query is: If customers become collaborators with the producers, just how much risk are they going to have to take on that they wouldn’t otherwise have if they simply bought an ‘off-the-shelf’ offering?

    I feel that you may have downplayed the role of feedback in current/former print publishing – as I’m sure you no doubt know yourself, ‘old school’ publishing relies heavily on masses of data from questionnaires, pilots, focus groups, etc. etc. during what you call stages 1 to 3 in the waterfall process. None of those extensive efforts represent a cost to the potential customer, except perhaps in terms of their time (and incentives to make even that worth their while are not uncommon).

    By contrast, from what I understand from your description of the Agile process, the customer appears to be doing a great deal of work and accepting significant financial risk when by definition they have no idea what they are going to get for their investment at the end of the 10 weeks (or 10 months or whatever).

    One of the bullet points in the manifesto reads ‘Customer collaboration over contract negotiation’ – I have to say that if I was the rector of a university in Country X, I would want to scrutinise very carefully any contract from an Agile ELT publisher and absolutely insist on negotiating for a number of safeguards against those risks. That could take some time to thrash out with the Prodct Owner, I assume.

    As a potential customer, my main concerns would be: How do the developers know how long it’s going to take when, by definition, they don’t know what the product is that they’re actually going to be delivering yet? Even if they did know how long it was going to take (in theory) – what happens if e.g. one of their authors becomes ill or their development editor takes a job at another company leaving the project half-way through or the designer goes on maternity leave, etc. etc.?

    Those events would of course also be disruptive in a ‘watefall’ process but, I think, they could be absorbed far more easily in contrast to a very tight-knit project team, especially one where they mostly carry out meetings face-to-face in 15-minute stand ups – a loss of a member from that kind of close-knit team could spell disaster for schedules and delivery dates. As a collaborator – not just a consumer – I would therefore be finding myself accpeting all kinds of additional risks that rightly ought to belong to the product owner. And any slippage on the part of the project team could leave me in a lot of bother with … what as a backup? A ‘finished’ coursebook? And if that was the case, wouldn’t I want to ask myself why I was bothering with Agile ELT when a safer bet might be to cut them out and go for the ‘finished’ and off-the-shelf coursebook option in the first place.

    If it’s the case that the Product Owner is the one to accept all financial risk until at least an agreed completion stage has been reached that sounds like a potentially huge upfront investment on the developers part (not least because it needs a team of at least seven full-time staff working intensively on a single project for anything up to a year before seeing a return on that investment). That sounds potentially very risky and certainly no less risky than disappointing sales in a published coursebook (which are themselves mitigated by aggressive marketing and promotion).

    It’s an interesting argument and I agree that some things are inevitably going to have to change but I think we’re only just seeing the tip of the iceberg in terms of the challenges they represent.

    • Thank you for the detailed and very well argued comment, Nik. And there’s nowt wrong with a bit of skepticism 🙂

      I’ve just got someway through a fairly lengthy response, but I’ve realised that there’s quite a bit of crossover with other comments in this thread related to customers and customer collaboration. So, I think I’m going to hold back and put together a more detailed post on that topic shortly.

      Thanks again for taking the time to comment.

  7. Nick, that’s a great overview of Agile and you’re part of a growing group I’ve seen starting to apply the principles outside of software development. I’ve been developing web-based ELT courses with an Agile approach for a couple of years now. This puts us more on the software development side rather than content but here are some observations from the trenches.

    What works

    -Daily, face to face stand ups encourage the sharing and solving of problems before they become too big
    -Involving the whole team in product development creates a better final product
    -Retrospectives at the end of each sprint are probably the single most important aspect of Agile. Sharing what went well, and what needs improving at the end of each sprint creates a virtuous circle of improvement.
    -Releasing bits of your product often and early helps you get feedback from real users, not just focus groups.
    -It’s much easier for clients to say what they want when they can see something real, rather than discussing an abstract idea.
    -Estimating is much more accurate because Agile teams often wait a couple of sprints before getting an idea of how fast they can work. Thus estimates are based on real data rather than a finger in the air.
    -Time not spent writing lengthy spec documents and adjusting your Gantt chart is time spent making the actual product.

    Some of the challenges

    -Getting accurate and timely feedback that can inform the next iteration is not always possible.
    -Designers unfamiliar with Agile can sometimes struggle as they don’t have the whole picture from the start.
    -A collocated team is harder to work with, but not impossible. Google hangouts can replace the face to face meetings.
    -Some clients still want to see lots of documented specs and the big Gantt chart!

    The best thing for us about Agile has been the transformation of our mindset from massive up-front planning to just in time development. We have an idea of what might work, test it out and then review the results and change our approach based on what we see. But this is where Agile starts to stray into Lean ( and the subject of another post?

    • Thanks for giving us some excellent insight from the trenches, Simon.

      One of things I’d meant to mention in the original post was related to the positive effects the daily stand-up can have on team dynamics. One of the issues that I think probably contributes to that is that it gives people the freedom to admit mistakes or bring up problems before, like you say, they become too big. That’s something that’s been sadly missing on some of the big ELT projects I’ve worked on.

      I read somewhere that the only thing you can ever really get blamed for during a project such as this is not admitting you need help when you really do. It reminds me of this great quote from Al Siepert at NASA:

      “In NASA, we never punish error. We only punish the concealment of error.”

      If it works for the rocket scientists, then, well …

  8. Great post, Nick, and some fascinating responses.

    A couple of (hopefully thought-provoking) point about an iterative publishing model:

    I agree fully with Nick’s synopsis above of waterfall vs. agile models for publishing content. But my eyebrows go slightly higher at the iterative model being adopted full-scale, partly as a consequence of my own background in market-specific adaptations of core material.

    Basically, the point of an iterative approach is like whittling a stick – you’re working down a blunt object to an ever-finer point, with the aim being to maximise revenue/profits/whatever by having the sharpest stick – i.e. by having a product that the market has informed you is what they want. The greater the amount the of market feedback, the more responsive to the market we’ve been, right?

    But what if (as hinted at by Mihaly, above) you get two contrasting responses? Whose need is greater? The obvious response is ‘whoever’s richer’, so you can maximise revenue, and you continue whittling your stick. But what about the segments of the market who didn’t shout as loud? What about the voices who are poorer, but have equally valid educational needs? What about the customers you’ll never get anyway, as the opinions they would have given remain unvoiced because previous feedback has guided the product away from what they would have wanted before they had the chance to shape the product?

    I wonder if we’d be missing a trick developing solely along these lines. So, a proposal:

    a) We go agile
    b) We go iterative up to a point
    c) We SPLIT development into market-specific models, each with its own team.
    d) THEY go iterative post-split, spinning off into the production of market-driven, targeted products more closely shaped to the needs of their customers. Each market-specific team learns from the best practice of pre-split team (maybe they were part of it, and cascade the knowledge).
    e) See c), if the country/region/sector requires it.
    f) Continue in this ever-decreasing circle until the investment required to form the next team down stops making commercial sense.

    Obviously, you’d need to draw a line somewhere: a university chain in Turkey with 180,000 students might merit their own adaptation (‘iteration stream’, if you like) whereas a PLS in a coal-mining village in the Russian Steppes might have to make do with a more general solution – i.e., one ‘designed for them’ by other, bigger players in the market. But, of course, this would be no worse than the ‘any colour you like as long as it’s black’ approach big publishers routinely take at the moment.


    • Just a thought to your brilliant comment Martyn: in view of the yesterday’s announcement of the Penguin-Random House merger, who do you think will have an advantage to reach the proper market, my collection of tender haikus, processed in the Agile way, or the 2,000 page bestseller published by PRH, in their outdated, traditional way?

      • I’d love to respond to your comment with a wittily-composed haiku of my own, Mihaly. But I can’t. So I won’t.

        But in response to your point: say you wanted to publish a book on a current affairs issue (Edward Snowden, for example) and could turn that around in 15 days rather than 15 months. You would, in that case, sell more while the potato is hot than in 15 months when the storm has blown over.

        This is a facile example, but taken more generally – agile publishing provides a dynamic advantage over rivals if you can respond not just to over-arcing ELT market trends, but also to changes in situation and circumstances. The government collapses in Italy – educational reform is instituted by the incoming government – publishers need (by law) to have full ebook versions of their products ready for school term start dates a few months hence. A new ministry of education decree means all Uzbeck students need to achieve B2 before they can enter university – testing apparatus needs to be put in place – this needs to be digital because of the vastness of the country. *

        In these cases, being agile is not just better. It’s the ONLY solution.

        *Only one of these two examples was made up.

        • Was it the comment about Uzbek students?

          (only asking as we visited Uzbekistan some years ago and despite the obvious negatives, we did love it!!)


          • Got it in one, Alison.

            If you want to read more on the topic, look up ‘la riforma Gelmini’ for an introduction to the depressing reality of the Italian education sector…

    • Apologies for the delay in responding to your great comment, Martyn. So much food for thought here, I think I’ll do as I’ve promised with Nik and Mihaly’s comments and roll of this into a new post about ELT customers and their needs. More anon!

  9. Interesting discussion, this. I’m scrum manager for a writing team which is displaced globally (twelve different courses being produced between March of this year and January of next) – we’ve had one f2f and the rest is done in a distributed fashion. The tech scrums are based in Brighton (platform, tools and interface) – I’ve yet to meet them. Clear goals, however, (and good comms tools) make this an easy thing to manage.

    • ‘Clear goals, however, (and good comms tools) make this an easy thing to manage.’

      Don’t suppose you’d mind listing some or all of those comms tools, would you? Paid for, or free?

      • Mostly proprietary, sadly – and therefore not shareable. On the writer side we’re using a Moodle site with various enhancements in terms of due date tracking, collaboration and versioning and that kind of thing. The rest is in-house stuff (not my house, which is why I can’t share)

  10. I think the winning idea here is the daily scrum meetings. It reminded me of how we used to write video activity books – brainstorms of ‘what’ at the breakfast table, heading off to write, meeting back at the table at regular intervals during the day to share, brainstorm solutions and then pressing on again. 10 days later we had a book.
    BUT – we’d been mulling over the script for a while before the rough cuts arrived. And with our backs up against the wall, we tended to fall back on tried and tested ideas that we knew had worked in the past.
    That’s actually my big concern. Tell us writers that the deadline is tight and we will play it safe and produce more of the same. Fresh innovative courses require time for trial and error. So I think ‘clear goals’ are fine for later down the line, but at the start they can chain you to the mundane.
    I reckon publishing bits and pieces as soon as they’re written is a great way to go. And stay flexible about how they’re assembled at the start. I think ‘it’s gotta work and it’s gotta be engaging’ should be at the top of the writers brief. ‘It’s gotta come after this unit and build on that one’ can come later.

    • Thanks for taking the time to comment, Vicki; it’s great to see you on here and to get some more author perspective. And I couldn’t agree more with your line “it’s gotta work and it’s gotta be engaging”. In fact, I use almost those exact words when I’m briefing prospective authors for my author agency. And anything we could do to stop everybody playing it safe would be a good thing, in my eyes at least.

  11. Excellent article and some brilliant ideas. I just wanted to dd my two cents regarding the meetings. I’ve seen a few and they are really something different. The atmosphere is charged (mostly with energy and motivation) and it’s fast and furious. From what I’ve seen, you need an agile moderator in the meeting to control things and keep it positive and moving along. Someone objective if possible. This person balances ideas and makes sure the goals are achievable and bite-sized.

    Also, I’ve seen some meetings that don’t work – this is usually because they lack buy-in from someone in the room. To make agile work – everyone needs to be in it from the start.

    Finally, I recommend ‘The Agile Samurai: How Agile Masters Deliver Great Software’ by Jonathan Rasmusson – even if you are not a software developer, it’s a great read.

  12. Iterative development is something I’m trying to do with my blog ( as I’m working with a business english class of ‘techies’ (software developers and others) so I found that the class is much more keen on the ‘process’ in the moment, learning something as soon as possible that is useful, than the product (perfect english).

    I suppose the biggest criticism of iterative development, whether it’s a book or a lesson, is that it’s ‘messy’ – which it is! But it’s also very creative and fun for the teacher. I like the idea of ‘The Sprint’ too, good stuff.


Leave a comment