Many organisations who are not themselves fundamentally or solely digital are interested in how ‘Agile’ might apply to them and their working practices. Many others are highly sceptical, perhaps particularly because of the often large amount of jargon that can be employed by some of Agile’s more enthusiastic supporters. This short article outlines why at Oriel Square we use the manifesto and principles of agile – rather than the rituals and technical language – to inform best practice in project leadership and personal effectiveness.
The Agile Manifesto
In 2001 a group of advocates of lean, agile or ‘extreme’ software development practices made a joint declaration, which they called the Agile Manifesto. As with all overnight sensations, it had been a long time coming, with roots stretching all the way back to the transformation of factory assembly lines in the early twentieth century. What made it revolutionary at the time – and what still raises hackles with some – is that it made a strong case for challenging the orthodoxies of project management: emphasising process, following a plan; then creating, making contractual and following to the letter a detailed requirements document.
The Agile Manifesto argues that although these things are valuable, there is more value in their opposites, particularly when thinking about the potential for flexibility afforded in software development: emphasising people, welcoming change, collaborating on requirements, and valuing a working product rather than the documentation which describes it.
Principles in practice
We believe that this manifesto is a good starting point for considering best practice in the management of any project, not just software development. It is true that in our training courses based on agile we tinker with the manifesto a tiny bit – replacing ‘working software’ with ‘working systems’ or similar – and that when teams in editorial or publishing departments discuss the next level of detail, the agile principles, there is often far more debate about how they best relate to working with education content. But we have found, consistently and over a number of years, that there is far more agreement with both manifesto and principles than one might expect.
That is why we rarely then go on to talk about agile practices and processes unless a team is specifically interested in investigating them. Too many of these relate directly to the business of managing software development teams and their relationships with the rest of a company to be readily transferable to publishing; whereas the manifesto and principles are clear, human and useful from the first moment they are encountered.
If you are interested in finding out more, have a look at our forthcoming live online course developed with BookMachine, and join us if you can.