> Enjeux IT > Entreprises & décideurs : l’agilité pour tous ?

Entreprises & décideurs : l’agilité pour tous ?

Enjeux IT - Par Didier Danse - Publié le 02 novembre 2020
email

Tout autant que le monstre du Loch Ness ou le Big Foot, tout le monde a entendu parler de l’agilité en entreprise. Est-ce pour autant une légende ? L’agilité est souvent présentée comme la solution à l’ensemble des besoins et des problèmes.

Entreprises & décideurs : l’agilité pour tous ?

Pourtant, l’agilité a ses détracteurs et nombreux sont ceux qui décrivent une perte de contrôle après avoir introduit des méthodes agiles dans leur entreprise. Ainsi, 30 ans après l’apparition des premières méthodes, le sujet divise toujours et bon nombre d’organisations échouent dans la mise en place de l’agilité.

Lorsque l’agilité ne prend pas, cela est souvent perçu comme un échec. Les causes de ce ressenti sont multiples et partagent différents composants : un manque de connaissance de l’environnement dans lequel se trouve l’organisation, une application incorrecte ou incomplète des méthodes ou encore une incompréhension des enjeux de l’agilité elle-même.

Au travers de ce papier, nous discuterons ces risques au « devenir agile » et donnerons les bases d’une implémentation réussie, qu’il restera aux décideurs d’aborder en tenant compte de leur écosystème.

 

L’agilité, bien plus que des méthodes et des outils

De nombreux articles présentent des méthodes agiles telles que Lean et Scrum sans pourtant promouvoir une réflexion plus globale, perdant de vue les enjeux de cette agilité. Ces méthodes promeuvent l’humain, que ce soit dans la prise de décision et même la performance et requièrent un changement de paradigme : du paradigme projet au paradigme produit ou service. Avec un paradigme produit ou services, ce sont ces derniers qui définissent les objectifs des intervenants. Le manifeste agile, qu’il est bien souvent de relire à de nombreuses reprises pour bien le comprendre, est d’ailleurs rédigé en ce sens.

L’agilité doit permettre d’intégrer les imprévus et augmente le besoin de communiquer et de s’adapter au quotidien. Ainsi, la notion de cahier de charges et de livrable se voit également évoluer pour maximiser les échanges entre les équipes informatiques et les équipes métier, que ce soit de manière itérative ou en continu mais aussi de fournir un contexte où l’entraide et la gestion des points de blocage sont importantes. Enfin, un des points d’attention importants est la prioritisation. En effet, rien ne sert de fournir des fonctionnalités qui ne pourront pas être utilisées directement.

Concrètement, l’agilité doit permettre de répondre aux nouvelles règlementations, de réagir face aux nouveaux acteurs sur le marché, mais aussi à différents évènements tels que la récente crise sanitaire ou les cyberattaques, et ce à une vitesse en constante croissance. Être agile, c’est accepter ces changements externes, hors de notre contrôle, et être prêt à apporter des changements sur des éléments sous notre contrôle.

Comme on peut le voir, l’agilité va au-delà de la mise en place d’une méthode et d’outils. Il s’agit également d’adopter un état d’esprit dit agile. Ce n’est que l’ensemble de ces composants qui permet d’agir et de venir en support à l’organisation pour générer de la performance et favoriser un environnement où chacun peut se voir grandir, les deux étant liés. Bien qu’idyllique aux premiers abords, l’agilité ne s’avère cependant pas la réponse à tout.

Lorsque le contexte ne s’y prête pas, l’agilité s’avère impossible à mettre en œuvre, quel que soit le domaine d’activités ou l’activité elle-même.

 

L’agilité durant la crise sanitaire

La crise sanitaire amène son lot de changements dans l’ensemble des industries. L’impossibilité de se déplacer et le télétravail forcé qui en découle, les problèmes de liquidité mais aussi le changement très rapide des habitudes ont forcé tant les individus que les entreprises à s’adapter, notamment en favorisant des démarches locales et des interactions modifiées.

A ce petit jeu, de nombreuses organisations ont pu s’adapter, d’autres se sont trouvées dans l’incapacité de le faire tandis que les dernières ont essayé et ont simplement échoué Il est intéressant de voir que de nombreuses organisations se transforment temporairement pour fournir de nouveaux biens, notamment des masques et des respirateurs, pour ne citer que les plus visibles. Les entreprises qui fournissent du service tels que la garde des magasins se sont simplement redirigées vers la gestion du débit de personnes aux hôpitaux. Ainsi, par de petits changements rapides et ciblés, ces entreprises ont pu s’adapter à une situation hors de leur contrôle.

Pour beaucoup, le digital a apporté des solutions nouvelles. De nombreux établissements de l’HoReCa se sont mis à proposer des livraisons à domicile, en fournissant une carte adaptée mais aussi et surtout une interaction nouvelle avec leurs clients, notamment au travers des réseaux sociaux voire même d’applications. Cette transformation, un peu forcée, n’a pas été simple pour tous.

D’ailleurs, plusieurs reviendront en arrière. Les autres y voient une opportunité. Ceux-là devraient mieux s’y retrouver que les autres.

 

Pourquoi l’agilité échoue rapidement ? …

De nombreux méthodes existent. Ainsi, dans le domaine du développement informatique, on peut citer Scrum, Lean Software Development, eXtreme Programming et Feature-Driven Development et une petite dizaine d’autres. Celles-ci sont bien souvent idéalistes et adaptées à une situation donnée. La mise en place s’effectue généralement dans un contexte différent de celui préconisé et il est fréquent de voir des organisations qui ont introduit des méthodes sans faire d’analyse préalable du contexte et des différences. Cette absence d’analyse peut rapidement devenir une cause d’échec, les méthodes n’étant pas adoptées par les intervenants.

L’agilité va à l’encontre de l’organisation de notre société et des entreprises, qui se veut très cadrée au travers de lois, de codes et autres règlements. L’agilité requiert de revoir son approche pour s’orienter vers la notion de cadre et de gouvernance. Ainsi, pour être agile, en plus de l’analyse du contexte, il s’agit tout d’abord d’être convaincu de son intérêt et de le promouvoir en extirpant les éléments contraignants.

Être convaincu et connaître son environnement est un début prometteur. Reste encore à définir un objectif à atteindre qui sera décrit au travers de différents indicateurs de performance en lieu et place d’une liste d’activités à effectuer pour y parvenir.

En effet, ce sont les indicateurs qui doivent cadrer la démarche et peuvent être multiples : durées, niveaux de risque, coûts, et ressources. Ces indicateurs laissent place à la créativité, à l’inverse de nombreux indicateurs se focalisent sur le « comment », ce qui empêche les intervenants de s’exprimer, d’innover et de performer.

 

…ou s’estompe-t-elle après un certain temps ?

L’agilité en entreprise n’est jamais que la somme de l’agilité de chacune des équipes, elles-mêmes composées de l’agilité de chaque individu membre de l’équipe. Ainsi, il arrive fréquemment que les différents intervenants qui supportent l’agilité s’épuisent en tentant de faire la promotion de celle-ci alors qu’ils se sentent seul dans la masse. Ainsi, si la motivation des plus hardis tend à diminuer, il va de soi que l’initiative se verra abandonnée.

Mais l’agilité ce n’est pas uniquement un état d’esprit à avoir au niveau des équipes de production, elle doit être soutenue par le management, notamment au niveau des indicateurs. Les indicateurs doivent être soutenus par un comportement en conséquence. Comme le dirait P. Drucker, « La culture mange de la stratégie au petit-déjeuner ». Ainsi, clamer haut et fort que l’on souhaite être agiles mais réclamer des documents tels que fournis lors d’approches en cascade mènera rapidement à des conflits et des pertes, que ce soit en termes de confiance ou d’image pour toutes les parties en place. Ainsi, en plus d’un accord d’agilité explicite, un accord implicite se doit d’être visible, par les actes.

En aval de ce cadre agile implicite, il s’agit de libérer les différentes organisations (équipes) de leurs dépendances avec d’autres organisations au sein d’une organisation globale (l’entreprise). En effet, chaque équipe doit pouvoir être suffisamment autonome dans ses activités pour exploiter au mieux les innovations, la créativité et la performance de ses membres. Il est fréquent de voir des pôles « agile » être mis en place, souvent en rassemblant les évangélistes de l’agilité. Avec la structuration de la démarche, ces pôles ont alors des objectifs basés sur la méthode et qui rendent le groupe dépendant du besoin d’organisation et incompatible avec les attentes, menant à nouveau à un épuisement physique et moral. L’absence d’objectifs communs pour le pôle « agile » et les équipes met finalement assez vite les deux en opposition, ces dernières effectuant des actions dans le but de satisfaire les exigences du pôle « agile ». Une telle approche peut mener à une forme d’anarchie avec les employés qui voient dans le management une autorité de contrôle bien plus que le cadre et le support.

Comme nous l’avons vu, les méthodes agiles non maîtrisées mènent souvent à des incompréhensions comme la perception que les interactions remplacent le besoin de documentation. Les interactions sont en effet privilégiées à de longues documentations mais elles n’en suppriment pas le besoin et ce manque de documentation devient un frein à l’agilité, ce qui semble être un paradoxe.

Le management lui-même peut également être un frein à l’agilité, notamment par un manque de compréhension dû à un manque d’information sur l’agilité, le besoin d’autonomie des équipes et les pratiques où la gestion de ces équipes ne requiert plus un gestionnaire en permanence. Ce manque de compréhension peut amener une perte de repères pour les membres de l’équipe mais aussi de la lassitude et l’absence de prise d’initiatives par les plus impliqués, ces derniers ayant alors tendance à reposer sur le gestionnaire, voire s’en rendre dépendant.

Téléchargez gratuitement cette ressource

Sécurité & Zero Trust Mise en œuvre

Sécurité & Zero Trust Mise en œuvre

Identifiez-vous vraiment tous les individus qui accèdent à vos données ? Le Zero Trust permet la sécurisation de tous vos accès, d’où qu’ils proviennent. Découvrez, dans ce Livre blanc, comment mettre en place un nouveau périmètre de sécurité avec une approche Zero Trust.

L’agilité et le management

L’auto-gestion des équipes, dites aplaties, rend-elle donc inutile la notion de hiérarchie ? Pas exactement.

Comme nous l’avons abordé précédemment, le gestionnaire agile prend une position différente ayant pour but de clarifier un périmètre donné avec une vision long-terme au lieu de devenir l’intermédiaire de l’information et le passage obligatoire pour la prise de décision. Le gestionnaire se doit de supporter les membres de son équipe, notamment en s’assurant de la disponibilité d’une vision claire et réduire les dépendances avec les autres équipes. Il doit également veiller à ce que l’équipe dispose du nécessaire pour produire ou fournir du service de manière adéquate. Il doit, dans la mesure du possible, ne pas interférer ou intervenir dans l’ensemble des démarches.

Le climat positif où règne la confiance permet à tout un chacun de travailler avec une pression moindre afin de favoriser la performance collective au-delà de la performance individuelle et d’exploiter au mieux les expériences et les convictions de chacun tout en donnant du sens aux activités. Pour cela, il s’agit de fournir les informations adéquates au bon moment. Le gestionnaire doit donc garder une vision long-terme des enjeux, au même titre que l’on se focalise sur un produit. Il doit aussi être le mentor et guider ses collaborateurs, en les accompagnant.

Pour y arriver, le manager doit supporter l’équipe (bien souvent virtuelle ou temporaire) pour générer de la satisfaction au travers du changement, jusqu’à ce que cela devienne un élément clé de la culture. L’amélioration continue requiert de changer au quotidien. C’est ainsi que le gestionnaire se doit d’alimenter ce cadre fréquemment.

Enfin, les gestionnaires eux-mêmes doivent être accompagnés dans leur démarche, notamment au travers de formations.

 

L’agilité et le besoin de planification

Bien souvent les budgets sont définis sur l’estimation de la charge de travail pour effectuer l’une ou autre opération et délivrer un certain produit. En lieu et place, il s’agit de définir des objectifs et des enjeux ainsi qu’une enveloppe qui soit considérée comme adaptée au besoin.

En gardant ces enjeux en tête, cela permettra aux futures équipes de fournir des solutions adéquates en tenant compte des enjeux et non d’un processus ou des livrables d’ores et déjà inadaptés. Cette approche permet d’adapter le « comment » le produit est délivré en continu en tenant compte des nouveaux besoins et opportunités.

 

L’agilité et le développement

Cet aspect est certainement le plus connu notamment grâce à l’utilisation de Scrum. Scrum est une méthode définie qui permet au travers de ses cérémonials de promouvoir l’échange et la promiscuité avec le business. Scrum peut cependant devenir un frein pour bien des équipes de développement et les organisations.

En effet, malgré les rétrospectives qui visent les équipes Scrum, on voit finalement assez peu ou pas de changements au niveau du processus de déploiement et l’opérationnel ou encore l’architecture. Ces changements d’échelle sont nécessaires pour supporter l’agilité dans le développement.

 

L’agilité et la sous-traitance

La notion de contrat a pour but de cadrer et permet bien souvent à chacun de se protéger de l’autre partie, ce qui va à l’encontre d’une approche qui cherche à venir en support de l’agilité. Il est préférable de préparer un contrat cadre et de définir conjointement des enjeux à chaque itération.

Une telle approche permet en effet de s’assurer que les fondations d’une relation saine soient posées. Par ailleurs, en clarifiant les objectifs de l’itération de plus courte durée, il est plus simple de s’assurer que tous sont alignés avec ces objectifs. C’est aussi là que le gestionnaire d’équipe à un rôle à jouer : il doit s’assurer de la possibilité que chacun puisse faire au mieux son travail sans perdre de temps inutile dans un contexte bureaucratique et en opposition.

 

L’agilité et l’infrastructure

L’infrastructure est certainement la partie la plus statique de l’informatique par le fait qu’elle repose essentiellement sur des composants physiques. C’est justement cette pseudo-immutabilité qui pose des problèmes. La virtualisation permet de rendre l’infrastructure dynamique, notamment grâce à l’auto-scaling tant croissant que décroissant, mais aussi le provisioning en Self-service. Toutes ces techniques assez simples à orchestrer sont autant de manières de supporter l’agilité au sein des organisations. La mise à disposition de solutions Platform as a Service va au-delà de cette capacité puisque le dimensionnement se voit mis à jour en fonction de l’utilisation et ce, de manière invisible aux autres équipes.

Rendre l’infrastructure dynamique nécessite de revoir son positionnement, tant en termes de modèle d’orchestration mais aussi de facturation. Et c’est souvent à cet instant que le point de blocage intervient.

 

L’agilité et l’architecture

L’architecte veut une vue globale sur les produits et systèmes et en même temps une vue détaillée de ceux-ci. Il est fréquent de voir des architectes chercher à définir comment une solution devra se comporter dans les années qui suivent. Cependant, dans un environnement où les besoins évoluent au quotidien, l’architecture tend à évoluer au même rythme. C’est ainsi que l’architecte doit alors promouvoir une architecture qui puisse évoluer dans le temps et de manière simple mais aussi veiller à disposer d’un niveau de documentation qui tienne compte de cette évolution.

L’architecture vient alors en support au besoin d’évolutions rapides. A nouveau, le modèle de fourniture des services des architectes doit être repensé pour supporter ces nouvelles approches, notamment en incluant les architectes dans les équipes, avec ceux en charge de la mise en place des solutions en lieu et place d’une approche où tout est défini en amont par l’architecte ou validé, en aval.

 

Par où commencer ?

Nous l’avons vu, pour devenir agile, il s’agit avant tout de connaître son environnement, tant au niveau des facteurs internes qu’externes. Avec cette information en main, il est alors possible d’identifier les activités où l’agilité peut amener de la valeur. Aux premiers abords, le besoin d’une approche assez statique ressortira fréquemment et en effectuant l’exercice plusieurs fois, de nouveaux domaines d’activités ou des activités seront listés.

Ensuite, la manière dont le cadre est défini doit être revu. Qu’est ce qui est mis en avant ? La méthode ou les enjeux ? Quelle orientation est prise pour les indicateurs de performance ? qui finalement, s’inscrivent pour répondre aux besoins ? Comme on peut le voir, il s’agit de revenir à nouveau à la compréhension des enjeux, de l’environnement et du fonctionnement des équipes.

Ensuite, lorsque le tout est opérationnalisé, les indicateurs de performance se doivent d’être régulièrement analysés afin de s’assurer que l’initiative agile porte ses fruits afin de la favoriser ou d’analyser les causes pour y faire des ajustements. Cette analyse se fera par les équipes elles-mêmes, éventuellement du support externe. Imposer des ajustements irait à l’encontre de la démarche.

Mais surtout, il est nécessaire de garder en tête que devenir agile ne se fait pas en jour, c’est un état d’esprit, qui peut se heurter à la culture en place.

Enjeux IT - Par Didier Danse - Publié le 02 novembre 2020