Like any other field of activity, communication has its own set of company rules and detailed documented processes: how a press release is published, how the logo is used, what should happen and in what order during a crisis situation, and so on. At my current workplace, these policies were last updated 3-4 years ago, so they are well worth a minor dusting down. As these policies are company-wide - communication teams in every country and every business unit - it was decided to implement the project in a scrum framework: a small, mixed team, supported by a Scrum Master and guided by a Product Owner, will process and update these documents in a series of two-week sprints.
"Agile" has become a big buzzword throughout the company, but for many of us in the communications team, this was our first real encounter with a new way of working: daily scrum meetings, the world of sprint reviews, retrospectives and sprint planning, the constant updating of the ADO board, and the idea of working with colleagues we didn't know for months on something that none of us were really good at. Indeed, in our team of 6-7 people, there is only one technical writer who actually specialises in writing regulations and legal documents, the rest of us come from different fields of communication - and yet, together, we have been able to achieve quite amazing results in rewriting regulations, precisely because of the many different perspectives and ways of thinking that we represent. It's no secret that in the beginning it took 2-3 sprints (and a professional Scrum Master) to get all the elements of the methodology to become routine and make sense to the team, but since then we have been smoothly working through the rules one by one. The scrum events give us a great framework for our work, we have a clear picture of who is doing what, and we can work accordingly, with focus and continuous progress.
Not all areas of communication can be translated into an agile methodology, but policy writing was the perfect subject for this, mainly because of its repetitive nature: writing a document in legal language, consisting of bullet points, always follows a very similar pattern. The same template has to be used for all the rules, the same way of approaching experts and managers on the subject for a little investigation/interview, compiling and approving a draft, answering any questions and comments along the way. In practice, however, it can drag on for weeks or even months due to the difficult availability of colleagues and the complexity of the issues.
The project is also made more difficult by two factors: firstly, the fact that the participants are all working on the codes in addition to their own daily work, dedicating a small part of their daily working time to this, and therefore the capacity of the team varies from sprint to sprint in the light of current 'other' priorities. Sometimes, some members even drop out completely for weeks, and are replaced either by someone new who has to be introduced to the world of scrum from scratch, or by a temporary shortage of people. The other limiting factor is that the company does not yet have a full understanding of agility, and therefore it is not always easy to get our stakeholders to join the bi-weekly sprint review events; it is not clear to everyone how and why we work along these principles.
The good news is that we are already consciously addressing these challenges and have a complete plan to mitigate the risks they pose. We are far from the end of the journey, but this little glimpse into the world of agile working has made many of us want to dig deeper into the topic
The article was written by our guest author: Ádám Nagy , who works in internal communications, specialising primarily in large corporate environments.
