Agile pour quand les choses tournent mal : l'élément manquant de votre plan de réponse aux incidents

By adapting the values found in the Agile Manifesto, you can crush incident response and build user trust. 

 

Shannon Winter Shannon Winter
Parcourir les rubriques

Les méthodologies Agile se propagent au-delà des frontières du développement traditionnel, dans tous les domaines d'activité, y compris le marketing ! Nous devons donc réfléchir à quoi ressemble l'agilité dans l'univers de la gestion des incidents ? Chez Atlassian, nous définissons Agile comme une approche structurée et itérative de la gestion de projet et du développement de produits. Agile permet à votre équipe de répondre au changement sans dévier de sa route.

Since bugs in production, incidents, and downtime can definitely be classified as times when things "go off the rails", we figured a methodology like agile -- built to help teams stay on the rails -- would have a natural place in incident management – specifically, incident communication.

Application des valeurs Agile à la réponse aux incidents

While there's no shortage of tools to help your team detect, alert, swarm on, and resolve incidents, tools alone can't replace clear communication to stakeholders. And let’s be real: The stakes can be high. Reputation, customer attrition, time spent on damage control, just to name a few. Agile methodologies can help keep these stakes as low as possible.

Bon nombre d'entre vous connaissent probablement déjà les quatre valeurs clés du Manifeste Agile : 1) Les individus et leurs interactions plutôt que les processus et les outils, 2) Un logiciel fonctionnel plutôt qu'une documentation complète, 3) La collaboration avec les clients plutôt que la négociation des contrats et 4) L'adaptation au changement plutôt que le suivi d'un plan. Voyons ces valeurs plus en détail et découvrons comment elles peuvent être exploitées pour obtenir une communication sur les incidents plus Agile.

Principe de communication sur les incidents : communication sur les incidents axée sur l'humain

This principle is based on the agile value, individuals and interactions over processes and tools. Processes and tools are important for any incident management process, but they mean nothing when viewed as separate from the people trying to use them and the culture that's been formed around them. What's the glue that fills the gaps between people, processes, and tools? Communication, of course!

Communication is crucial when an issue arises, whether it is a small bug in production or a full-blown system failure. Even the most complete incident plan requires frequent communication in order to reach resolution and maintain trust.

Lors d'un incident, les utilisateurs affectés rencontrent certainement des erreurs frustrantes (voire handicapantes) et doivent savoir ce qui se passe au plus vite. Beaucoup vont très vite envoyer des e-mails, des tweets ou des tickets à propos du problème. Il est donc dans l'intérêt commun de prendre rapidement la situation en main en envoyant un message qui montre que vous êtes conscient du problème et que vous cherchez à le résoudre. Chez Atlassian, nous utilisons Statuspage pour communiquer avec les parties prenantes internes et externes au cours d'une panne. Il devrait vous être utile pour communiquer les informations sur un incident à vos utilisateurs de façon rapide et à grande échelle. En réalité, Statuspage a permis aux utilisateurs d'accélérer leur communication sur les incidents de 50 % (incroyable !).

Vous voulez essayer ?

Sign up or log into Statuspage >>

Once you are in, learn more about best practices for subscribing your end-users and effectively communicating during an incident:

Mais peu importe l'outil que vous utilisez pour donner à vos clients le 4-1-1, la communication axée sur l'humain est essentielle. Des personnes en chair et en os comptent sur vous pour les tenir informées lorsque quelque chose ne va pas. Si les modèles sont utiles dans un monde parfait, vous devrez pouvoir compter sur des personnes capables de rédiger des messages clairs, concis, empathiques et pertinents pour renforcer la confiance des clients dans les moments difficiles. Prenons Dyn, par exemple. L'entreprise a été victime d'une panne importante lors de ce qui devait être la plus grosse attaque par déni de service de l'histoire, mais les utilisateurs l'ont tout de même remerciée pour sa franchise lors de cette interruption de service :

Comme l'a déclaré Werner Vogels, Chief Technology Officer chez AWS, lors de la panne majeure qui a touché AWS S3 en février 2017 :

"Customers don't like advice that says 'sit still, don't do anything.' No, that's not what they want, and for that you need to give them really good information, make them understand what's happening, given an expectation of when the service will be coming back online if you have such information."

Principe de communication sur les incidents : Création d'une page et mises à jour aisées des incidents

For this principle we look to the agile value, Working software over comprehensive documentation. Documentation about your product should be clear and user-friendly and we think incident updates should be too! Your users shouldn't have to read between the lines (or skim lengthy paragraphs) to know what is going wrong and when they can expect a fix. While you do need to put thought into your incident updates and make sure you being empathetic and human in your communication, you shouldn't let approval gates or multiple revisions get in the way of frequent, honest updates.

Talking a look again at the Dyn incident, you can see their team wasted no time when communicating updates to their users. Over the course of the 11+ hour incident, they updated their status page 11 times (an average of 61 minutes between updates). Their status page enabled them to have one single place to communicate about the incident, rather than spending time finding the mailing lists to e-mail or figuring out how to fit updates into 140 characters on Twitter. In other words, they got the message out there while still primarily focusing on reviving their service.

Un outil de communication de l'état prêt à l'emploi est très utile : une page fiable est fonctionnelle en un rien de temps. Moins de 30 minutes sont nécessaires pour créer une page d'état, et comme Agile, votre page d'état peut et doit être itérative. Pensez à mettre en ligne une page de travail pour vos clients, puis améliorez-la au fur et à mesure. Après avoir rencontré quelques incidents avec une page d'état dans votre processus, vous pouvez l'améliorer au fur et à mesure.

Ready to create your own status page? Sign up or log into Statuspage >>

N'attendez pas le prochain incident pour créer une page d'état. Prenez quelques minutes maintenant, afin d'être prêt en cas de problème. N'oubliez pas, pas besoin de passer des heures sur la configuration d'une page pour qu'elle soit efficace :

Principe de communication sur les incidents : Communication transparente pendant et après les incidents

This agile value Customer collaboration over contract negotiation is all about working with your customers to provide the best product and experience possible. To us, this means having proper feedback channels set up so customers can voice concerns and alert you of any issue they are having (using tools like Jira Service Management, Twitter, etc.). World-class companies understand that customers are expecting a response to their feedback and want to be involved when it comes to making improvements to your product and your incident response process. Some empathy and an explanation goes a long way – and customers are not timid to ask for it – as shown through these tweets:

This also means maintaining transparency around your uptime so users know exactly what they are getting when they sign-up. When you sign-up for a cloud service, you're trusting that service to be reliable. It is not always a physical contract, but rather an inherent contract negotiated between customer and service provider that when things go wrong, the two parties will collaborate to make sure things are resolved quickly and everyone is kept in the loop from investigation to resolution. Which brings us to our final value around responding to change...

Principe de communication sur les incidents : Rétrospectives Agile

Même les plans les mieux élaborés… Vous connaissez la suite. Rappelant la valeur Agile, L'adaptation au changement plutôt que le suivi d'un plan, nous savons que même les plans les mieux conçus devront inévitablement changer pendant et après un incident. Agile consiste à être capable de s'adapter immédiatement à une nouvelle situation et d'obtenir un feedback rapide pour améliorer votre produit et votre culture.

Wistia, an internet video and analytics hosting company, learned just how important it was to remain agile during an unexpected incident in 2013 that left their stats infrastructure grinding to a halt. They weren't prepared, leaving them swamped with support tickets from disgruntled customers. Their first pivot was creating their own status page to help make their lives easier in situations like this. But by creating their own status communication tool, they were now supporting a new product in addition to their core product. It become clear this was a cost their 20-person team at the time could not afford. The second pivot was to call their homegrown solution quits and move to Statuspage.

Jordan Munson, ingénieur de support chez Wistia a décrit la migration comme suit : « Après quelques mois de frustration avec notre solution interne (presque dépourvue de fonctionnalités, mais néanmoins utile), nous avons décidé que nous avions besoin de plus, d'une solution qui ne nécessiterait pas autant de support. Nous sommes passés à Statuspage. Depuis la migration, nous avons pu réaliser tout ce que nous souhaitions, tout en tenant rapidement et facilement nos clients au courant de l'état de l'application. Il aura seulement fallu une panne massive et la création d'un nouveau produit pour y arriver. Quelques années plus tard, notre processus semble beaucoup plus fluide. Les gens reçoivent des mises à jour directes en cas de panne, ils savent où rechercher des informations, et les mises à niveau apportées à notre page d'état sont directement envoyées à différents destinataires. »

Munson's team truly took lemons (the 2013 outage) and made lemonade (a new and improved – and scalable – incident communication process). This is an agile response to change at its finest.

Retrospectives are also a key part of this agile value. A retrospective gives your team the chance to take a step back and discuss what worked well during your incident communication, what did not work so well, and most importantly, what you will do to prevent the same issues from happening again. Don't don't give in to the temptation to skip over a retro after an incident is marked "resolved" or if you think your team performed great. There is always room for improvement when it comes to incident communication and always a chance to build better rapport and trust with your users.

Conseil d'expert :

Essayez ce scénario du Playbook des équipes Atlassian : il fournit un espace sûr à votre équipe pour réfléchir et discuter des choses qui fonctionnent (et qui ne fonctionnent pas !) afin de vous améliorer.

Revisitant notre premier Manifeste Agile, les rétrospectives nécessitent une communication axée sur l'humain pour aboutir et générer des résultats durables. Jetez un œil ci-dessous à quelques formulations à considérer lorsque vous faites une rétrospective sur la résolution d'un incident. Certains de ces termes devraient également être intégrés dans la revue post-mortem ou post-incident (PIR) que vous envoyez aux utilisateurs après le rétablissement de votre service. Être agile signifie améliorer continuellement non seulement la façon dont vous exécutez les tâches liées à l'incident, mais également celle dont vous contactez vos coéquipiers et exercez votre rôle dans une situation stressante.

Langage humain

Langage des produits

Hypothèses, espoirs et craintes

Tâches, tickets et actions

Motivations, mécompréhensions et comportements

Sprints, epics, stories et versions

Préférences, relations et respect

Étapes importantes, dépendances et dates

Rôle et responsabilités

Réunions, calendriers, e-mails et fichiers

N'oubliez pas la confiance

We talk a lot about trust in agile and it is no different for this use case. Effective incident communication requires trust and empowerment. Teams across the organization should feel empowered with the approval and the knowledge required to communicate to users around incidents. Individuals should also be able to trust that everyone will perform their assigned duty during a incident response – and will not hesitate to jump in and embrace a break in process when the unexpected occurs. Trusting your teams to effectively communicate around incidents will allow customers to be informed more quickly, and in turn, will increase user trust and loyalty to your service (67% of Statuspage customers say that Statuspage has helped increase their users' trust!) A true win-win.