L'ouverture au changement est une condition préalable à la «transition agile» (Image de Julia Lingertat)

Comment devenir agile - Guide de l'agence

Créer des conditions idéales pour les projets clients agiles

Cet article est également disponible en allemand.

Au cours des dernières années, «agile» est devenu un mot à la mode de plus en plus populaire sur la scène des agences. À peine une seule entreprise ne prétend pas travailler de manière agile. Mais qu'est-ce que cela signifie réellement? Comment savoir à quel point une entreprise est agile? Si on travaille dans les sprints, est-ce que ça veut dire qu'on est déjà agile? (Réponse: non.)

Chez Aperto Move, nous avons constamment analysé et perfectionné nos méthodes de travail au cours des deux dernières années et demie, faisant progresser notre vision de l'agilité sur le lieu de travail. L'une des réalisations les plus irréfutables est que la transition vers l'agile nécessite à la fois du temps et de l'expérience. On ne peut pas simplement passer à l’agile. Bien que nous ne soyons pas encore où nous voudrions être, les améliorations sont clairement perceptibles.

L'application de méthodes agiles dans une agence est tout à fait plus difficile que, par exemple, dans le développement de produits; car on crée des produits pour différents clients, où les conditions peuvent varier considérablement d’un projet à l’autre. Il est donc difficile de croire que chaque agence semble soudainement agile. Heureusement, certains facteurs peuvent aider à déterminer facilement à quel point une entreprise est en passe de devenir agile.

Les conseils présentés dans cet article sont basés sur des scénarios communs à la plupart des agences, qui sont apparus dans notre travail quotidien et qui ont été résolus une fois que nous les avons identifiés comme des problèmes. Ce ne sont pas des solutions miracles, mais plutôt un ensemble d’apprentissage qui nous convient le mieux.

1. Clarifier la terminologie

Lors de l’introduction de la technologie agile, il est essentiel que tous les membres de la société aient la même compréhension du terme, sans quoi un risque de mauvaise communication est dangereux. J'ai rencontré des personnes qui confondent l'approche agile avec le renoncement à toutes les phases de concept, la planification et les réunions régulières au profit de plonger directement dans un projet et de voir ce qui se passe. Il n’est pas difficile d’imaginer qu’un tel projet n’était pas facile à vivre.

D'autres ont simplement entendu parler de «Scrum» et entretiennent une certaine réticence à son égard, en le considérant comme «quelque chose pour les développeurs» qui étouffe le processus de création. La plupart du temps, ces déclarations proviennent de personnes qui n’ont pas elles-mêmes exploré Scrum ou les méthodes agiles. De plus, ceux qui ne le connaissent pas ne peuvent souvent pas faire la différence entre agile et Scrum, et les classer comme un seul et même.

Scrum et agile ne sont pas identiques

Scrum est un cadre qui définit des règles, des rôles et des processus de travail spécifiques pour développer des logiciels. Un exemple en est la définition des intervalles de temps dans lesquels un produit de travail est livré (appelé «sprint»). L’implémentation de Scrum contribue au développement logiciel agile, c’est pourquoi les termes sont souvent considérés comme synonymes, mais ils ne le sont pas.

«Agile», d’autre part, est une façon de penser ou une culture qui résume bien plus que ce que fait Scrum. Les principes qui définissent la culture agile sont énoncés dans le Manifeste Agile et sont illustrés dans la vidéo suivante:

Scrum n'est qu'une des approches possibles pour suivre les principes agiles. On peut aussi être agile sans utiliser Scrum. En revanche, le simple respect des règles de Scrum ne signifie pas qu’on travaille réellement de manière agile.

2. Faites vos adieux au rôle de chef de projet (dites bonjour aux rôles agiles)

Dans Scrum, les rôles suivants sont définis:

  • Propriétaire du produit
  • Scrum Master
  • Équipe de développement
  • Autres parties prenantes, telles que l'utilisateur final ou les personnes impliquées du côté du client

Il n’ya pas d’autres rôles, ils ne sont pas nécessaires non plus. Le gestionnaire de projet classique n’est plus requis dans cette configuration. Il ne ferait que gêner le processus, car toutes les tâches précédemment exécutées par le chef de projet sont désormais couvertes par les postes énumérés ci-dessus. La responsabilité du succès du projet ne repose plus sur une seule personne, mais sur l’ensemble de l’équipe.

Chaque rôle supplémentaire qui existe dans le projet - et se situe entre l’équipe Scrum et le client - constitue un obstacle à la communication directe et efficace entre l’équipe et le client.

Prendre les rôles et les responsabilités au sérieux

Si vous n’avez pas besoin d’un chef de projet, n’auriez-vous pas intérêt à faire appel à d’anciens chefs de projet dans le rôle combiné de Scrum Master et de Product Owner?

Non. D'une part, les rôles Scrum Master et Product Owner impliquent suffisamment de tâches pour que l'exécution de ces tâches entraîne la négligence de l'un des rôles. En fin de compte, les deux rôles ont des intérêts contradictoires. Le Product Owner reste en contact permanent avec toutes les parties prenantes et veille à ce que le bon produit soit livré avec la meilleure qualité. Entre autres choses, le Scrum Master doit s’assurer que l’équipe n’est pas surchargée de travail ni interrompue. Par conséquent, le Scrum Master n’a rien à voir avec le produit lui-même.

Une idée encore pire serait d’omettre complètement le Scrum Master. Sans Scrum Master par intérim, rien ne permet de garantir que l'équipe travaille de manière productive, respecte les délais ou apprend par le biais de rétrospectives et devient plus efficace. En bref, ce sont eux qui garantissent que le projet est mené de manière agile. Selon notre expérience, il s'agit d'un rôle particulièrement important dans un environnement d'agence avec des clients, des intervenants et des conditions changeants, car Scrum Master assume également un rôle de coach pour le client.

Cet article explique les différentes fonctions du Scrum Master et du gestionnaire de projet classique en termes d'analogie de trafic simple à comprendre:

3. Plus de planification des ressources (établissez plutôt le principe d'attraction)

Dans les agences, on travaille souvent simultanément sur plusieurs projets pour différents clients, ce qui pose un défi pour la répartition efficace du travail entre tous les employés.

L’approche classique de l’agence est la planification des ressources: un chef de projet crée des plans sur plusieurs jours ou plusieurs semaines et affecte des employés à des projets ou à des tâches. Cela nécessite beaucoup de temps pour la planification et la coordination et entraîne la rigidité, dans la mesure où il part du principe que toutes les projections et tous les plans pour le temps imparti sont respectés.

L'expérience nous enseigne qu'en réalité, de tels projets ne se concrétisent jamais: une livraison importante est retardée, des employés tombent malades ou d'autres circonstances imprévues surviennent, ce qui entraîne des tâches individuelles plus longues que prévu. Les conséquences sont une répartition inégale du travail entre collègues, davantage de stress et d'heures supplémentaires.

Ce principe dit de «push» (parce que les employés ont des tâches uniques «poussées» sur eux) n'est donc pas optimal. Alors, comment le travail est-il distribué sans chef de projet dans la constellation agile? Cette question nécessite une approche différente:

Le principe d'attraction

Le travail agile est basé sur une mentalité «d'attraction». Cela signifie que les employés décident de manière proactive des tâches qu'ils souhaitent entreprendre. Pour que cela fonctionne, les tâches à venir et leur progression doivent être communiquées de manière transparente.

Dans une situation idéale, cela ne se produit pas uniquement au niveau du projet, mais pour toutes les tâches à venir au sein de l'entreprise. Cela comprend l’évaluation de la portée, la création de présentations, la préparation d’ateliers, la participation à des entretiens ou même la rédaction de cet article. Ceci peut être accompli avec un tableau Kanban, par exemple:

Le principe d'attraction contribue à assurer une répartition uniforme du travail entre les employés, où chacun a la liberté de décider en toute indépendance, quand il a la capacité de travailler à ses tâches. Cela aide à éliminer la possibilité de surmenage de certains employés.

Pour que le principe d'attraction fonctionne, les conditions suivantes doivent être remplies:

  • Une communication constante est cruciale. Chez Aperto Move, le statut du projet est discuté trois fois par semaine au conseil d'administration.
  • Cela nécessite des personnes ayant la capacité de prendre l'initiative plutôt que d'attendre que les autres leur disent quoi faire
  • Il favorise les hiérarchies plates et nécessite une volonté de les mettre en œuvre.
  • La direction de l'entreprise doit faire confiance à ses employés pour leur permettre d'assumer davantage de responsabilités.
  • Il doit y avoir une distinction claire entre les tâches individuelles et les projets. Les projets ne sont pas tirés par une seule personne, mais par une équipe. Ceci sera approfondi dans la section suivante.

4. Établir des équipes stables

Il est typique dans les agences de travailler pour plusieurs clients simultanément et les tâches urgentes (telles que les évaluations de périmètre, les pitchs ou les corrections de bugs) surviennent souvent à court préavis. Par conséquent, les équipes de projet sont souvent créées en fonction des disponibilités actuelles. Ce type de planification des ressources empêche efficacement les projets agiles.

Les équipes agiles doivent être stables et idéalement se retrouver. Seules des équipes proches peuvent se développer de manière optimale et maintenir, voire accélérer, leur rythme en apprenant les unes des autres, en coordonnant leurs processus et leur communication, et en identifiant et en résolvant les problèmes grâce à une analyse rétrospective.

Les équipes peuvent identifier et résoudre les problèmes par le biais de rétrospectives régulières (Image de Andreas Plath)

Pour ne pas perturber des équipes de collègues efficaces qui travaillent bien ensemble et éliminer ainsi tous les effets d'apprentissage et de routine, les projets à venir ne doivent pas être planifiés avec des personnes à l'esprit, mais plutôt avec des équipes stables.

Cependant, il est irréaliste de penser que la transformation d'une agence entière avec toutes les disciplines en équipes stables et équilibrées peut se faire du jour au lendemain. Il est concevable que tout le monde ne veuille pas travailler en permanence dans la même équipe. Il est donc crucial de trouver un équilibre qui convienne à tous.

5. Créer des propositions agiles

Une phase de proposition classique et simplifiée entre un client et une agence prend généralement la forme suivante: Un client a une idée spécifique pour un produit et un calendrier indiquant le moment où il doit être terminé.

Le client informe ensuite l'agence des exigences (peut-être avec un argumentaire) et demande une proposition spécifiant un prix fixe pour le développement de ce produit. Afin de se protéger, les deux parties consacrent beaucoup de travail à l’élaboration de la proposition afin d’éviter tout risque de mauvaise communication.

Du point de vue du client, cela semble généralement une solution viable: ils savent ce qu’ils obtiennent quand et à quel prix.

Les exigences changent

Ce que la plupart des clients ne savent pas encore, c’est qu’ils veulent souvent quelque chose de très différent à la fin du projet, comme ils l’avaient fait au début.

Puisque tout est défini de manière concrète dans la proposition, il est presque impossible de modifier ultérieurement le projet sans renégociation, par exemple:

  • d'autres caractéristiques sont devenues plus importantes entre-temps
  • le projet souhaité n'est plus techniquement réalisable
  • les tests des utilisateurs ont révélé que le produit est mal compris ou qu’il n’a pas de sens
  • un concurrent a créé un produit similaire qui nécessite un pivot stratégique

Dans ce cas, une nouvelle hiérarchisation des priorités n’est pas facile si l’ancienne portée révisée est spécifiée dans la proposition.

Les autres aspects majeurs de l’agilité sont sapés par ce type de proposition. Une amélioration continue et collaborative du produit est beaucoup plus difficile, car le produit doit être clairement défini au début pour finaliser la proposition. Cela conduit à un flux de travail typique en cascade. La planification du sprint, y compris la planification du poker, devient tout aussi inutile, car une date limite et les résultats attendus ont déjà été définis.

Si la portée, la date limite et le prix ont déjà été définis au début, il n’est plus logique de tenter de mettre en œuvre un cadre agile tel que Scrum.

Dans ce cas, on ne peut plus utiliser les principaux avantages de la livraison agile, mais il reste une dépense supplémentaire liée aux réunions Scrum qui ne fournissent aucune valeur réelle. Ce processus est également appelé «pseudo Scrum».

Un autre type de proposition est nécessaire

Il est plus judicieux de facturer pour la quantité de travail effectuée (ce que l’on appelle les contrats de temps et matériels) plutôt que de définir les produits à livrer exacts dans la proposition. Ce n'est qu'alors qu'il est possible d'exécuter un projet de manière agile.

Le montant et le rapport qualité / prix du client sont déterminés par lui-même au cours du projet, en tenant la liste des exigences à jour et en hiérarchisant les priorités avec l'équipe.

L’élaboration de propositions agiles nécessite une certaine pratique (Source: https://unsplash.com/?photo=OQMZwNd3ThU)

Pour que le client ait une idée de ce à quoi il peut s’attendre, on peut donner une estimation approximative de ce qui est réalisable dans un laps de temps donné ou du temps qu’il faudra pour que certaines exigences soient mises en œuvre. Plus une équipe a longtemps travaillé ensemble, plus cette estimation devient précise, car il est plus facile de mesurer le rythme général ou la «vitesse» de l'équipe. C'est une autre raison pour laquelle il est préférable de travailler avec des équipes stables.

Cela étant dit, l’élaboration d’une proposition reste l’un des éléments les plus difficiles de la transition agile. À peine un client qui n’a pas déjà acquis de l’expérience dans un environnement agile veut-il signer un contrat à durée indéterminée. Pour les convaincre de son mérite, il est essentiel de faire preuve de compétence et d’établir d’abord la confiance avec le client.

D'après notre expérience, ce défi est facilement surmonté dès qu'un projet agile est terminé. C'est alors que le processus de projet parle pour lui-même; produisant des résultats rapides et tangibles grâce à un travail itératif, une collaboration étroite et des cycles de rétroaction plus courts, qui sont beaucoup plus proches de ce que le client envisageait que dans des projets de cascade classiques.

Il existe de nombreux ouvrages utiles sur les propositions agiles telles que ce livre:

6. Impliquer l'équipe de projet dans la phase d'acquisition le plus tôt possible

Dans les agences, la phase d’acquisition et de proposition est souvent isolée de la mise en œuvre du projet. Une nouvelle équipe commerciale est responsable des nouveaux projets et l’équipe de projet n’est pas confrontée aux détails jusqu’à la phase de mise en œuvre, ce qui augmente la probabilité de conflits.

La phase de proposition peut déjà être cruciale pour déterminer si un projet sera couronné de succès. Il est donc essentiel que l'équipe agile soit incluse dans la communication le plus tôt possible.

En conséquence, on peut évaluer assez tôt si une mise en œuvre agile est viable et combien de temps on peut en attendre. Le temps passé, par exemple le nombre de sprints requis dans un projet Scrum ne peut être évalué que par l'équipe elle-même, si elle en sait le plus possible sur le projet.

Il y aura parfois plus de demandes de projets que la capacité de les traiter. Afin de mettre en œuvre le principe d'attraction et de sélectionner le projet le plus approprié, l'équipe doit en savoir le plus possible sur tous les projets en attente. Ce n’est qu’ainsi qu’ils pourront prendre une décision éclairée et incorporer de manière significative de nouveaux projets dans les sprints des projets actuels.

Lorsque le nouveau projet commence, l'équipe doit connaître le plus tôt possible toutes les parties prenantes et leurs exigences afin de fournir le bon produit avec la meilleure qualité possible. Une mesure efficace pour y parvenir consiste à organiser un atelier avec l'équipe et les parties prenantes côté client.

De plus, il est important de communiquer les valeurs agiles au client, d'identifier le contact principal et d'expliquer la procédure de collaboration en détail.

7. Oubliez le rôle de fournisseur de services (et travaillez en équipe avec votre client)

Une relation client / fournisseur de services est contre-productive car elle repose toujours sur le principe que le client a attribué un contrat et attend un résultat spécifique. Un résultat de projet réussi, qui satisfait toutes les parties impliquées, nécessite généralement un travail de tous les côtés, en particulier une communication régulière entre eux.

Un préalable indispensable à la réussite d'un projet agile est une communication au même niveau. Cela signifie que le client et l’agence se considèrent mutuellement comme une seule et même équipe, travaillant ensemble sur un projet et identifiant et valorisant les points forts de chacun. L'agence est généralement un expert en stratégie, expérience utilisateur, conception et mise en œuvre technique; Par ailleurs, le client connaît ses propres processus et exigences internes, ainsi que son public cible. Ce n'est que lorsque ces informations sont partagées que l'on peut créer un produit véritablement orienté utilisateur et qui satisfasse toutes les parties prenantes.

Cela nécessite la présence d'un contact désigné du côté client, disponible pour répondre aux questions concernant le projet ou pouvant fournir à l'agence tout matériel manquant. Tous les clients ne peuvent ou ne veulent pas investir autant de temps dans un seul projet, car leurs propres processus de travail internes ne le permettent pas.

Selon notre expérience, les clients remarquent généralement très tôt la rapidité avec laquelle ils obtiennent des résultats de grande qualité grâce à une coopération agile. Cela correspond à leurs attentes et ils sont prêts à investir du temps.

8. Fournir un espace pour le travail d'équipe

Être agile signifie travailler de manière interdisciplinaire et avec une communication continue. Cela fonctionne mieux si l'équipe agile est assise ensemble, ce qui facilite la coordination de leur travail. Idéalement, chaque équipe devrait avoir son propre espace où elle peut travailler sans être dérangée tout en minimisant les perturbations pour les autres, par exemple. lorsque des dessins ou des fonctionnalités sont en cours de discussion.

Les équipes agiles doivent pouvoir travailler sans être interrompues (Source: https://unsplash.com/photos/5T6lSk2uI1A)

Les agences donnent souvent une image différente: le regroupement des employés en fonction de leurs disciplines respectives. Cela signifie que tous les concepteurs sont assis dans un coin du bureau, les développeurs dans un autre, et les testeurs et les gestionnaires de comptes souvent dans des salles différentes. Bien que cela puisse avoir un sens en termes d'échanges liés à une discipline, cela complique la communication au sein d'une équipe de projet. S'écrire les uns les autres est une possibilité, mais cela prend beaucoup plus de temps que de parler directement les uns aux autres.

Cela devient encore plus difficile lorsque tous les membres de l’équipe ne se trouvent pas au même endroit. Tout le monde sait à quel point les conférences téléphoniques et les vidéoconférences sont mauvaises, et si vous n’avez jamais eu à les subir, cette vidéo est recommandée:

9. Considérez chaque discipline et le processus de projet complet

Scrum étant né du développement de logiciels, il peut sembler pratique d'exécuter l'aspect technique du projet de manière agile, en laissant la phase créative intacte. Cependant, cela produit relativement peu, car la structure de la cascade n'est alors résolue qu'à la fin du projet.

Un processus classique en cascade est basé sur l'approbation de livrables spécifiques

Supposons que l’équipe agile est composée uniquement de développeurs; Le concept et la conception du site Web du client sont déjà terminés, mais au milieu du développement, il devient évident que d’importants États n’ont pas encore été définis ni conçus et que l’équipe créative est déjà engagée dans leur prochain projet. Et maintenant? Faut-il enlever les gens d'autres projets? Continuer à développer un produit incomplet? Il n’existe pas de solution simple si l’on implique dès le début toutes les disciplines pertinentes dans le flux de travail agile.

Un échange régulier au sein de l'équipe de projet améliore la qualité du produit (Source: https://unsplash.com/photos/gN_nIUnjYJI).

Commentaires, Commentaires, Commentaires

La collaboration interdisciplinaire et l’amélioration itérative des produits reposant sur un retour d’information rapide et régulier entre toutes les parties prenantes constituent un atout majeur, et une raison importante pour laquelle la qualité des logiciels développés de manière agile est supérieure à celle des projets en cascades sous gestion de projet classique.

En termes simples, cela signifie que tout le monde passe en revue toutes les phases du projet.

  • Le client et l’ensemble de l’équipe transmettent au client les commentaires des utilisateurs.
  • Les concepteurs d'interface utilisateur donnent des commentaires sur les structures filaires et l'exécution technique
  • Les concepteurs UX donnent leur avis sur les conceptions d'interface utilisateur et l'exécution technique
  • Les développeurs front-end font des commentaires sur les wireframes, les conceptions d'interfaces utilisateur, les interfaces dorsales et, le cas échéant, leur implémentation.
  • Les développeurs back-end font des commentaires sur les structures filaires, les conceptions d'interface utilisateur et l'implémentation frontale
  • L’assurance qualité (QA) donne un retour d’information aux structures filaires, à la conception de l’interface utilisateur et à l’exécution technique.
  • Les utilisateurs donnent des informations en retour via des tests d'utilisabilité tout au long des phases du projet (structures filaires, prototypes de conception, cartes de calcul, implémentations front-end)
  • Le client commente les incréments de produit lors des réunions de révision du sprint
Dans une configuration agile, l'équipe travaille ensemble plutôt que de manière consécutive

Un retour d'information régulier est l'atout le plus important du développement agile et garantit que le produit est développé à un niveau satisfaisant pour toutes les parties prenantes. Naturellement, cela ne fonctionne que lorsque tout le monde est impliqué dans chaque phase du projet.

10. Ne vous attendez pas à ce que tout fonctionne immédiatement (faites des erreurs et apprenez d’elles)

Espérons que les sections précédentes ont indiqué que, à plusieurs niveaux, il est nécessaire d’adopter des approches différentes de celles qui ont probablement été développées et établies au fil des ans. Il est donc d'autant plus important de comprendre que le passage à l'agilité est un processus, pas nécessairement facile, ni à fin définie.

La mise en œuvre des mesures décrites ci-dessus ne garantit pas automatiquement le passage à l’agilité. De même, il ne suffit pas de mettre en œuvre uniquement des aspects «techniques», tels que l’adoption de Scrum. Il est beaucoup plus essentiel de changer la culture de l'entreprise et d'établir un système de valeurs commun et agile à tous les niveaux hiérarchiques.

Il serait naïf de s’attendre à ce que de tels changements fondamentaux puissent être accomplis instantanément et sans anicroche. Les modifications apportées aux processus de l'entreprise peuvent également être traitées comme un projet agile et déployées de manière itérative.

En fin de compte, cela signifie que vous ne devez pas essayer de tout changer en même temps, mais mettre en œuvre une mesure à la fois. De cette manière, on apprend ce qui fonctionne, ce qui ne fonctionne pas et ce qui peut être amélioré. Il serait faux de s’en tenir à une mesure qui ne vous semble pas appropriée, simplement parce qu’un livre ou un blog l’a recommandée.

Un coaching externe peut être tout aussi utile pour initier les bons processus de pensée, mais on ne peut pas espérer trouver un remède rapide, ce qui le rend soudainement agile.

Il est également important d'établir un échange interne de connaissances et d'expériences et de convenir d'une approche commune. Pour ce faire, il est utile d’examiner régulièrement les douze principes du Manifeste Agile et de déterminer dans quelle mesure une entreprise les a déjà adoptés:

Dans notre équipe, le strict respect des directives du framework Scrum s’est révélé être la meilleure solution. Chaque fois que ces processus étaient déviés, cela entraînait des complications et davantage d'efforts. Cela ne doit cependant pas être le cas pour tout le monde. Chaque entreprise doit découvrir par elle-même ce qui fonctionne le mieux.

Conclusion

Même avant le début d'un projet client, certaines conditions d'agence standard peuvent compromettre ou même rendre impossible la réussite de projets agiles. C’est là qu’une nouvelle façon de penser est nécessaire à tous les niveaux et dans toutes les disciplines, ce qui implique des changements qui ne peuvent être mis en œuvre du jour au lendemain.

Les points soulevés dans cet article peuvent servir de guide pour reconnaître et discuter des situations et des problèmes liés à la planification de projets agiles, avant même qu’ils ne commencent.

Quelles sont vos expériences sur ce sujet? Connaissez-vous d'autres circonstances qui rendent les processus agiles difficiles? Faites-nous savoir dans la section commentaire de cet article.

Lectures complémentaires

Aperto Move - Une société IBM est une agence berlinoise de services numériques et mobiles comptant environ 30 employés. Et vous?

Suivez-nous: apertomove.com / Facebook / Twitter