Many publishers use a traditional model of project management that can make the publishing process slower and less responsive. Steve Martin argues that adopting an Agile approach can benefit both editorial professionals and their publisher clients.

The benefits of Agile approaches

Most publishers use a traditional project management model. Although there are benefits to this approach, there are drawbacks, such as:

• complex, difficult to understand plans
• enforced long-term commitments that set rigid expectations
• a lack of autonomy and empowerment for project managers
• inefficiencies, especially at scale, including:
  • work passing through too many hands, resulting in miscommunication and rework
  • people doing too many concurrent tasks, leading to mental overload
  • multiple documents doing the same thing
  • problems getting sorted after the fact rather than before
  • difficulties changing direction
  • lots of ‘wait time’.

These issues are usually coped with (at the cost of money, time and quality) and this approach has been around for a long time so isn’t going away. But alternative approaches have evolved over the last few decades, moving away from fixed plans and rigid control structures to a more dynamic approach to change.

One of these is an ‘Agile’ approach to change. It isn’t just a project management methodology – it is a philosophy for effective teamworking. It is described in the ‘Agile Manifesto’, which was created by a number of thought leaders in the technology world. Its principles are as follows:

• Individuals and interactions over processes and tools.
• Working deliverables over comprehensive documentation.
• Customer collaboration over contract negotiation.
• Responding to change over following a plan.

Underpinning these principles are more detailed and useful mechanisms, such as TIA:

• Transparency – ensure the information about a project, for both assets and performance, is continually captured and accessible.
• Inspection – analyse and understand the state of the project at any point in time.
• Adaption – make remedial changes in real time, ideally proactively, to keep things on track.

Agile doesn’t mandate what is done but how it is done. Examples of implementations are ‘Scrum’ and ‘Kanban’, which will be explained below.

The Agile approach goes a long way to minimising the drawbacks of traditional projects. It was, after all, one of the reasons why the Agile Manifesto was created in the first place!

Traditional projects tend to deliver in large chunks, often after long periods of time, meaning customers only start to profit at the end of a project or phase. Agile projects deliver rapidly and incrementally so that customers can start profiting far more quickly.

Finally, given that one of the fundamentals of the Agile Manifesto is empowerment, people who work on Agile projects often get a greater sense of ownership and job satisfaction.

All in all, it is an approach that has potential for the publishing world.

How can editorial project managers, editors and proofreaders benefit?

The publishing world tends to use traditional project management, often working with packagers and third-party service providers. There are reasons why things are as they are, and these evolve in the long term, but for now, a sensible attitude for anyone interested in Agile approaches is to ask: ‘What can Agile do to help me, within wider industry constraints?’

Here is an explanation of a couple of terms mentioned earlier:

Scrum

This uses timeboxes (short periods of time, for example two weeks) by breaking up work items (the backlog) into batches that the team focuses on as their primary goal while also refining requirements for the next time box. The work items as a whole are also looked at in the background to maintain their priority and relevance.

Kanban

A Kanban (or Kanban board) is a pipeline-based approach (like a car production line). Teams pull work items from a backlog in priority order and push them through various customisable work stages until they are done. The backlog is maintained in a similar way to the Scrum one. Free tools such as Trello can be easily set up to operate a Kanban. The picture below shows how a Kanban might look (in this case for someone taking on too much work!).

Personal workload

One of the challenges for a publishing professional is how to track work in a simple way. A to-do list is OK, but a Kanban has advantages. A simple ‘To Do, Doing, Done’ Kanban would show at a glance what is on the go at any time and what stage it is at. A more elaborate Kanban may add workflows that cover each process step – there may be a need for separate boards for editing and proofreading, as their workflows may differ.

It is possible to flag work items as blocked, as a reminder to chase people. To track the personal financial side, project managers can add additional terminating columns for (eg) ‘Send invoice, Awaiting payment, Paid, Done’. Horizontal ‘swim-lanes’ can be used to divide up the work between, for example, different clients.

Work in progress (WIP) limits

A Kanban can help manage overload. One way is by tracking WIP limits. It has been proven that the ‘keep chucking new work in at one end and get it moving to appear busy’ approach is a terrible idea. Finishing work, not just starting it, is what adds value. High WIP means swapping between different tasks (‘context switching’), which has a negative impact on productivity and quality. It is far better to finish five jobs in sequence effectively than five at once badly. Unfortunately, the second approach is sometimes necessary, but a Kanban highlights this and allows time to be better managed and, perhaps, trigger negotiations with clients. Over time, sensible WIP limits will become clear, and when to say ‘no’ or ‘not yet’ will become a more empirical decision.

Throughput

In Kanban, throughput – the amount of work delivered over a given period – is as important as deadlines. Monitoring throughput and proactively fixing problems improves the chance of hitting future deadlines. More advanced Kanban tools provide reports such as cumulative flow diagrams to show at a glance whether someone is productive or ‘stuck’, and if so, where. These have a learning curve so a simple ‘green’ or ‘red’ flag, or counting task completions per month, might give the project manager insight while they learn how the graphs work.

Project management

A client may permit the use of a Kanban tool, even if it is to simply mirror their main Gantt chart. If so, once such a board is created, team members can be invited to join it to collaboratively manage work and update progress. Most Kanban tools allow attachments, comments, sign-offs and more. Having everything in one place reduces email chatter. This gives a holistic view of where people are, who is overloaded, who is stuck and what is going slowly.

If the project involves sensitive documents, it will be necessary to talk to the IT department about what can and cannot be stored externally at online providers to ensure security requirements are met (one could store links to internal document libraries as a compromise).

Collaboration opportunities

The collaboration aspect of Agile methods can also bring benefits. Here are some examples:

• Progress coordination – in a fast-moving environment where many people are concurrently involved, having a daily ‘stand-up’, in person or online, works far better than written progress reports in terms of keeping people on track. All or some of the team assemble every morning to share what they have completed, what they are working on and what impediments they face. The meeting should be no more than ten minutes so any detail would be discussed away from the stand-up.
• Key delivery meetings – Project launch, planning, and other meetings (face to face or online) should include as many involved parties as sensibly possible, even if just for scheduled timeslots within the meeting. This means that queries and issues can be discussed in person and written communication should, where possible, be relegated to confirmation and follow-up.
• Quality management – Regular (eg fortnightly) retrospectives (QA reviews) reviewing what went well, what did not go well and what can be improved are recommended to ensure lessons are learned while they are fresh in the mind as opposed to waiting until the end-of-project review.

---

Hopefully, this gives a flavour of what Agile is and how it can help publishing projects. The best way to start is to do a little more research and dive in. Good luck!

 

 

Photo credits: cranes by Mike van Schoonderwalt on Pexels, Kanban board by Dr ian mitchell, CC0, via Wikimedia Commons, team meeting by fauxels on Pexels.

Posted by Harriet Power, CIEP information commissioning editor.

The views expressed here do not necessarily reflect those of the CIEP.