Using Kanban to manage content production
Kanban is a visual management tool for the continuous delivery of products that is now used in software development and other knowledge work as well as manufacturing. It was developed by Hirotaka Takeuchi and Ikujiro Nonaka in their work at Honda, Toyota and other successful manufacturing companies.
Our Kanban journey at Scope began when we started to apply content design practices to the production of our information and advice content. We wanted Kanban to help us visualise, manage and continuously improve the process.
We read a lot, we talked to Kanban practitioners in other organisations, and we had some coaching from the charismatic KanbanDan. Then we started off in a simple way by setting up a Trello board that modelled our content workflow. Things evolved from there.
This introductory post from Leankit identifies 4 Kanban principles. They are a useful way to look at how we’re doing.
Visualise work
Half the team work remotely so we needed a simple way to visualise our workflow that everyone could access online. Trello was an obvious choice and it’s worked well for us.
Our first iteration of the board had only a handful of columns, each representing a stage in our content workflow. As we started to understand our processes in more detail, we added more columns to the board to reflect each individual step. We now have 21 columns, which might look daunting at first sight. But it means we know exactly at what point each content item is, and we can easily see where the bottlenecks are.
As we got more used to ‘walking the board’ every morning, we increased the amount of information on each card so that we don’t have to rely on memory, or on looking up details elsewhere. At a glance we can see who’s involved (researcher, subject expert, content designer), key dates (pair writing, critique session, testing), the user story and its acceptance criteria. We also include the test persona so that user researchers can easily see the kind of test participants they’ll need well in advance.
The board is public, so people in other teams can see what new content is being planned, and when it’s ready. The information architect uses the board to pick up content that’s ‘done’, ready to add to the website navigation. And our digital marketing colleagues use the keyword information annotated on each card to inform their paid search campaigns.
Limit work in progress
We are continually challenged to stick to Work In Progress (WIP) limits on the board.
It’s tempting to have many content items in progress, but we have found by experience that this can be counterproductive. It’s better for content designers to focus on no more than one or two pieces at once. But other people in the process can work with higher WIP limits because their part of the process is much shorter: for example, an editor doing a second eye on a piece can cover several items in a day. So balancing WIP limits across the whole board is tricky.
Focus on flow
Kanban has taught us the importance of trying to maintain a consistent rate of flow, and to focus on the right-hand side of the board, where work gets finished. The board makes it easy to spot where work is getting stuck, and it’s become part of our team culture that people offer help to unblock the flow.
Sometimes though, external dependencies mean that we make exceptions to this principle. If we outsource content testing, it’s uneconomic to send one content item at a time to the agency because we need to give them work in batches. We deal with this by using a separate column on the board to accumulate items. Tested items are also returned to us in a batch, so the team would typically ‘swarm’ to iterate all the tested items as quickly as possible to restore flow.
Continuous improvement
Everyone in the team is encouraged to look for ways to improve how we work, and to put those ideas into practice.
The whole team reviews the board together each morning, and this is an opportunity to notice and change something that’s not quite right. If we are always having to ask who is working on a piece right now, we might decide to have a policy that you add your avatar whilst you’re working on a card and remove it when you’re not to improve the visualisation of work.
More formal retrospectives happen every month to make sure that we set time aside to reflect on the past month and its challenges and agree any action we need to take. We have a rule that anyone can call a retrospective at any time — we don’t want to wait up to a month if something important needs addressing.
We also had Kanban coaching and training sessions once we had started using Kanban and could bring our own questions and challenges to the debate. Everyone in the team attended these. As well as finding practical ways to improve our Kanban practice, these sessions were good for building team skills like listening to each other and developing trust.
We still have some way to go, but Kanban is an evolution not a revolution! So far, it’s been challenging, stimulating and sometimes counter-intuitive. It’s helped build a committed and supportive team and it’s meant we can confidently manage an ambitious number of content items through a complex workflow.
