Organisation Agile

L’agilité est la capacité d’une organisation à fournir tôt et souvent des services procurant de la valeur, tout en s’adaptant à temps aux changements de son environnement

Avec cette définition on voit que l’agilité ne s’adresse pas uniquement aux équipes mais à l’organisation. Si vous souhaitez réussir une transformation Agile il est nécessaire que l’ensemble de l’organisation soit aligné sur cet objectif.

Et je rejoins Claude Aubry sur ce point. De nombreuses organisations (souvent grosses) veulent se transformer vers Agile mais en réalité uniquement l’équipe de développement aura un fonctionnement plus ou moins Agile. Nous avons donc une optimisation locale qui est entravée par une organisation globale qui n’a pas changé ; ainsi la valeur, le temps, le coût gagné par l’équipe de R&D et reperdu par le processus en amont et en aval

Mes questions sont donc :

  • de savoir s’il est réellement possible pour une « grosse » entreprise de mettre en œuvre la philosophie Agile globalement (et pas uniquement dans l’équipe de dev) ?

  • Existe-t-il des ouvrages pour une transformation Agile niveau organisation

  • Dans le cas où c’est peine perdu (ce que je pense) vaut-il toujours la peine d’avoir une équipe de développement Agile ? Est-ce que mettre en place cette philosophie puis un framework aura une réelle plus-value ?

Pour cette dernière question, je pense qu’au niveau humain oui, en centrant le processus sur l’humain nous allons « fidéliser » les développeurs mais maintenant au niveau produit je ne pense pas ; qu’on soit resté sur un ancien système ou en adoptant la philosophie Agile, la valeur, le temps et le cout du produit sera identique

Même si ce n’est jamais très poli, je me permettrais de répondre à ta première question par une autre question : est-il réellement souhaitable pour une « grosse » entreprise de mettre en œuvre la philosophie Agile ? Et si oui, qu’est-ce que signifierait concrètement cette philosophie Agile ?

Effectivement tu soulèves un point essentiel, et ma réponse est « Je ne sais pas », je n’ai pas le recul professionnel nécessaire pour y répondre.

Néanmoins j’ai ceci, une affirmation d’une cac40 : « nous souhaitons mettre en place Agile dont Scrum pour nos équipes de développement »
Avec cette phrase j’ai l’impression que l’entreprise n’a pas compris la philosophie Agile, elle l’a vu comme une buzzword à mettre, comme une hype. Mais d’un autre côté j’ai du mal à croire qu’il n’y ait personne dans cette entreprise qui a compris la philosophie Agile … Donc j’ai un sentiment mitigé entre une réelle volonté et l’incompréhension de la philosophie Agile

Donc pour revenir à ta question est-il réellement souhaitable pour une « grosse » entreprise de mettre en œuvre la philosophie Agile

  • Dans cet exemple, l’entreprise laisse pensé qu’il y a un intérêt mais lequel ? je ne sais pas. Où du moins elle estime que seul l’équipe de développement devra être Agile et que ceci règlera l’ensemble des problèmes …

Je note que la déclaration précise bien « pour nos équipes de développement », et non pas à l’ensemble de l’entreprise.
Cette entreprise du CAC40 me semble donc effectivement bien au courant de la philosophie Agile, qui produit des résultats intéressants dans le domaine du développement logiciel, mais qui montre ses limites à d’autres domaines et peut même se révéler contre-productive, pour des raisons qui seraient un peu longues à expliquer ici mais on trouve pas mal d’articles sur le net à ce sujet. Il n’y a qu’à voir le backlash actuel contre l’Agile, peut-être un peu sévère, mais nécessaire pour que tout le monde remette un peu les pieds sur terre.

Ah, je me suis mal exprimé quand je dis pour nos équipes de développement

Je parle bien uniquement de l’équipe de dev (codeur) mais la réflexion (analyse du produit, des exigeance) est faite en amont avec des réunions (C’est ce que je souhaitais représenter sur l’image du premier post).

Donc la philosophie Agile n’est que pour l’équipe qui code le produit. Les autres personnes impliqués (stakeholder) eux ne fonctionne pas de manière itérative et incrémentale (si on simplifie) mais en cascade en prévoyant en avance les tâches, le planning, etc …

D’où ma question, est-ce bien bénéfique d’avoir une équipe de développement (les codeurs) qui fonctionne en Agile sachant que le reste du travail est en « cascade »

Why not (ton provocateur !).
Opinion 100% personnelle : Même si je reconnais une efficacité certaine à l’approche Scrum dans le monde du développement logiciel, on n’a pas attendu Scrum pour que des gens développent des logiciels (j’utilise ce même argument quand quelqu’un essaie de me vendre la nouvelle méthode projet révolutionnaire)
Ce qui est clé dans l’industrie du logiciel, si on a une approche produit Time-To-Market / Amélioration Continue, c’est le pipeline du Continuous Integration/Delivery. Il est plus rapide de pondre des exigences que de les implémenter. Le chemin critique, à optimiser, ce n’est pas vraiment les phases amont qui peuvent éventuellement rester en « cascade ». Mais c’est surtout ce qui concernent les développeurs en eux-mêmes.
Donc si la boite assimile CI/CD à Agile, alors, ça peut se tenir et ça peut tout à fait fonctionner.

Oh, effectivement, je n’avais pas du tout pensé à cela (manque d’expérience)

L’optimisation globale doit passer par une vision d’amélioration continue, mais le phase la plus critique / à risque est bien la phase de développement ⇒ d’où l’effort.

Ainsi les 2 stratégies suivantes mèneraient aux mêmes résultats :

  • Str1 : une entreprise entièrement Agile (itératif, incrémental, feedback régulier, etc.)
  • Str2 : une entreprise qui fait du CI/CD et qui ne réalise de l’agilité que sur sa phase de Développement ?

Également autre question (je vais également faire mes recherches) qu’est-ce qui différencie CI/CD de Agile, car les deux visent une livraison régulière d’un produit à haute valeur afin d’obtenir un feedback rapide du client ?

@adrien, d’où vient cette définition de l’agilité ? Elle est de toi ? Si non, il est important d’attribuer aux sources.

Je ne pense pas. Je pense que ce n’est même pas souhaitable.

Il y a des ouvrages qui le prétendent, mais à ma connaissance aucun ouvrage ne propose une méthode valide. Il y a surtout beaucoup de poudre de perlimpinpin.

Tant mieux que ce soit peine perdue. Oui, c’est utile qu’une partie de l’organisation applique des méthodes agiles sans que le reste de l’organisation le fasse. @adrien, je relève deux erreurs dans ton raisonnement :

  • Tu supposes que pour qu’une organisation soit agile, il faut que toute partie de l’organisation le soit. Ce n’est pas vrai.
  • Tu passes de l’organisation entière à seulement l’équipe de dev. Il y a plein de possibilités entre ces deux extrêmes.

Au niveau organisationnel, je pense qu’il faut plutôt se tourner vers le concept de résilience : la capacité à survivre avec une continuité d’identité. Pour être résilient, il y a des moments où il faut être agile, et des moments où il ne faut pas l’être. Il n’y a pas de méthode universelle. Il est donc important d’être capable de donner du sens à son contexte et de sélectionner une méthode cohérente. [Product Management Contextuel | William Bartlett | Oct, 2023 | Medium]

Il est important de réaliser :

  • que les méthodes agiles ne sont pas capables de provoquer une innovation de rupture
  • qu’une organisation qui applique la même méthode (ou famille de méthodes) partout n’est pas résiliente

Réponse courte : oui :wink: mais ca va demander pas mal de remise en question

Donc avant cela on se demande

  • → En a-t-elle envie (prête à en soutenir/sponsoriser les contraintes et moyens) ?
  • → En a-t-elle le besoin ? Le sait-elle ?
  • Comment les parties non « dev » de l’organisation réagissent à la vidéo de la chaine
    : L’agilité : synthèse pour dirigeant | scrumlife.tv
  • En quoi ça va concrètement changer les choses pour l’entreprise ?
  • Comment va-t-elle gérer le changement que cela fait dans tous les niveaux de l’organisation ?
  • A-t-elle conscience que ce n’est pas l’organisation qui va changer sa façon de travailler, c’est l’organisation qui va changer. Des gens vont changer de métier, des postes vont nécessiter des glissements, disparitions, apparitions de compétences, de valeurs, de mesures, de repères…,
  • Ça ne va pas marcher du premier coup, comment gérer la transition ?
  • de savoir s’il est réellement possible pour une « grosse » entreprise de mettre en œuvre la philosophie Agile globalement (et pas uniquement dans l’équipe de dev) ?

Mouais… Faut définir beaucoup de choses : c’est quoi une grosse entreprise ? C’est quoi la philosophie agile ? Honnêtement, si on revient à la base, Agile c’était Léger. Une grosse entreprise légère, ça me semble un peu antinomique… Un éléphant peut s’alléger, mais par rapport à un être humain, il restera toujours plus lourd !

1 « J'aime »