Continuous delivery is not just a software issue
Continuous delivery (CD) is the latest buzzword in platform development, a hot new trend that you need to jump on or be dead meat, the greatest thing since sliced bread … join in if you know the words.
Unfortunately, for many in digital publishing the exhortations to move to continuous development, no matter how great the potential benefits of doing so might seem, will meet with cynicism – or perhaps a weary shrug. Continuous delivery? We’re still trying to nail delivery, thank you very much.
This would be a shame. Publishers might still be struggling to make the move from waterfall to agile – and even those who are notionally in a position to move to CD will feel that it would have internal impacts that are unknown and in many ways unpredictable. However, an approach based on CD really does have a lot to offer.
But continuous delivery is not just a software issue. We need to look at it with a wider focus, that sees all the issues of workflow, budgeting and resources. Only then can we begin to chart out a practical and immediate route to achieving these looked-for benefits.
And actually, those benefits might not be as far out of reach as you suppose.
Is continuous delivery out of reach?
We made an argument recently for breaking the cycle of periodic redesigns and taking a more iterative approach to development on publisher platforms; an approach similar to CD.
It was good to see some of these points echoed in a piece on the Digital Science ‘Perspectives’ blog recently, (Beyond agile – Continuous delivery is the new frontier in fast, cost effective and lower risk innovation). This title neatly spells out the benefits publishers could achieve with CD – greater speed to market, better cost control and better control of the risks in innovation. However, the author’s exhortation to ‘Take a few leaps ahead – the transition to agile is complete, and the next evolution of development is CD’, might lead some to see CD as a rather far-off goal. You have to have completed your transition to agile and be looking forward to a next step, maybe. It’s described as an evolutionary process – and evolution, as we know, is a slow-moving thing, involving generational change.
You might believe that CD could be a while coming about. Meanwhile, the mainstream of web development races onwards; user behaviors and expectations continue to be shaped accordingly – business opportunities are missed and new competitive threats proliferate. Can publishers realistically afford not to pick up the pace in moving to CD?
It’s a question that goes to the heart of a really important issue in digital publishing developments.
The shortcomings of futurology
Companies like HighWire are often compelled to act like futurologists on behalf of their clients; helping them to make judgments about which technologies they can afford to ignore and which they should adopt – and how quickly or cautiously they should move in their adoption.
However, futurologists are prone to a couple of besetting sins, which this insightful blog post points out. One of these is to focus too narrowly on the tech, and ignore the role of human behaviour and culture in shaping change. Hypnotised by the new affordances a given technology will bring, they ignore the behavioural changes that would have to come about before that technology could really be accepted by significant numbers of people – for instance, remember how culturally unacceptable Google Glass turned out to be?
Translating this dynamic to the business context of publishing, it is often the case that seizing the opportunities offered by a new technology can involve changes to workflow. From the point of view of a Java developer these might seem quite trivial: ‘all they have to do is drop this piece of code in whenever they publish and article and look how much time they save themselves’.
However. The member of staff in question might not be comfortable with using code. The IT department might not like the code that is being dropped in, or the fact that someone outside their department gets to drop bits of code into a system for which they have a duty of care. The many hours of work that are saved by this piece of code might result in someone being made redundant, which could have strategic impacts.
There is something of a ‘butterfly’s wing effect at work here, meaning that quite small changes in workflow turn out to have big organisational impacts.
This is a dynamic that has prompted platform developers like HighWire to be extremely conscious of how they frame their service propositions. Partnership working has to be more than a ‘motherhood statement’: the development partner must be extremely conscious of the effects that technological advances in platform design will have on how the client’s team operates. A collaborative, consultative process has to sit alongside technical development.
Now, as our clients begin to show an appetite for a more CD style of approach, this has led us to frame a way of working that will help liberate publishers from the cycle of periodic redesigns, and embrace a more CD-style approach, while also supporting them in solving (and in some cases simply eliminating) the workflow, budgeting and resourcing issues raised by a change of this kind.
We call it Continuous Improvement (CI), and you can learn more about it by joining our webinar at the link below.