Qu’est-ce que le coaching agile?

Le coaching agile consiste en guider vos gestionnaires de projet dans leur choix de la technique agile de développement de logiciel la plus adaptée à votre projet.

Le coaching agile couvre un large éventail de sujets. Dans la littérature sur le développement de logiciels, certains auteurs font la distinction entre le coaching agile et le consulting agile, tandis que d’autres font une distinction entre le coaching d’un groupe ou d’une entreprise et le coaching sur une base un-à-un.

L’activité de consultation consiste à appliquer une méthode agile spécifique. Cela pourrait par exemple être la peaufiner du carnet de commandes du produit. Évidemment, cela crée un grand pas en avant pour l’équipe et fournit également aux membres de l’équipe les outils et le savoir-faire pour être en mesure de travailler plus efficacement sans la présence du consultant agile.

Le coaching d’autre part consiste à guider une équipe pour trouver son chemin dans la méthodologie agile, en leur fournissant des réponses à une ou plusieurs des questions suivantes: « Qu’est-ce que Scrum nous dit au sujet? », « Quels sont les principes sous-jacents? », « Pourquoi les résultats ne sont-ils pas comme prévus ou prédits »?

Pour nous, il n’est pas important de réellement distinguer à l’avance si vous en tant que client êtes dans le besoin de consultation ou de coaching dans le domaine des techniques agiles de développement de logiciels. C’est quelque chose qui sera clair une fois que notre intervention commencera sur le lieu du travail.

Jusqu’à présent, nous avons traité l’aspect horizontal du coaching agile au sein d’une seule équipe. Cependant, il y a aussi une autre dimension au coaching agile. L’aspect vertical consiste à encadrer les individus pour qu’ils se comportent bien au sein d’une équipe et de prendre cette équipe pour qu’elle soit bien performante au sein d’un département ou de l’ensemble de l’entreprise.

Coaching

Le coaching sur le plan individuel pourrait généralement consister à guider un maître de Scrum dans l’exécution de ses tâches en tant que serviteur-chef, à définir précisément les tâches de l’ingénieur de train de libération dans le cadre de la méthodologie SAFe ou à rendre clair pourquoi le déploiement continu peut être important pour un DevOps-ingénieur en montrant que les inconvénients sont largement contrebalancés par les avantages. Au niveau de l’équipe, le coaching agile peut être d’une grande importance lors de l’intégration de différents départements de développement en un seul ou lors de l’intégration du département du développement avec celui des opérations. Finalement, aussi le service de comptabilité peut être influencé positivement en utilisant certaines des techniques DevOps ou en organisant des activités de maintenance sous forme de sprints.

LE CADRE AGILE

Le cadre

Le cadre agile consiste en une série de techniques qui a évolué à travers les années comme Scrum ou Kanban.

Une Charte importante, le manifeste agile, a été émise par certaines des personnes les plus célèbres dans le domaine des méthodes de développement, telles que Ken Schwaber de Scrum.

La Charte est raisonnablement courte et contient quelques-uns des principes qui devraient être satisfaits par toute méthode agile. En dehors de ceux-ci, toute méthodologie est libre d’inventer ses propres techniques aussi longtemps que les principes auxquels est fait référence précédemment sont respectés.

Sous cet angle, la fameuse technique de «Lean Management» en soi n’est pas considérée comme une méthodologie agile. Souvent, la gestion Lean fait partie d’autres méthodologies qui adhèrent aux principes du manifeste agile, comme Lean Six Sigma.

Toutes les méthodologies agiles n’ont pas été développées pour résoudre les mêmes problèmes. La simple construction de solutions logicielles est l’objet de méthodologies comme Scrum et XP, et en partie de kanban.

DevOps est plus orienté vers le déploiement réel du logiciel, alors que NEXUS ou LeSS ont tendance à proposer des méthodes pour intégrer efficacement les équipes de développement de logiciels.

Le cadre agile n’a pas vu la lumière à une date spécifique, mais est le fruit d’un mouvement qui évolue constamment. Il y a 30 ans, la technique de Scrum était une véritable révélation. Cependant, la limitation imposée par Scrum sur la taille de l’équipe qui s’occupe du développement d’un logiciel, le limitant à un maximum de 9 personnes, a fait que les gens se demandaient ce qu’il faut faire quand un projet est trop grand pour être traité par une seule équipe ou quand une équipe doit faire face à différents projets interdépendants ou distincts. Pour cette raison, Nexus, LeSS et SAFe ont émergés. Scrum tend à offrir peu de solutions en ce qui concerne le déploiement réel des logiciels.

Selon Scrum, cela se fait sans plus. Pourtant, dans la pratique, cela ne semble pas ou presque jamais être le cas. En conséquence DevOps et DAD sont venus offrir des solutions traitant de la question du déploiement. En plus de ce dernier, SAFe a également mis un certain travail acharné dans la réflexion sur les questions de déploiement et est venu offrir les concepts du « release train ».

Cette évolution constante peut également être remarqué en regardant la technique DAD – Disciplined Agile Delivery – qui consiste en une méthodologie qui indique comment choisir parmi d’autres techniques, mais qui est également une partie de DAF – Disciplined Agile Framework. Ce dernier cadre vise à fournir des solutions à un niveau interprojet (Portfolio) ou entreprise, mais les différents modules doivent encore être développés.

L’exemple de DAD nous montre un autre aspect des techniques agiles de développement de logiciels. La plupart d’entre eux se réfèrent les uns aux autres. DevOps par exemple se réfère à Scrum et kanban quand il s’agit de la partie qui a trait au développement même du logiciel et se concentre principalement sur les opérations.

D’autres techniques sont moins populaires ou sont déjà quelque peu obsolètes, mais elles peuvent encore être de valeur ou même conduire à des améliorations majeures en ce qui concerne l’efficacité d’une équipe de développement. Parmi ceux-ci sont DSDM, Agile Methods, Crystal et UP.

Mon point de vue personnel

En ce qui concerne la multitude de techniques agiles de développement logiciel, j’ai personnellement tendance à faire une note. Certains gestionnaires peuvent négliger le fait que le logiciel doit effectivement être développé par le biais de la programmation d’un ordinateur, tandis que la programmation réelle n’est jamais l’objet des techniques de développement. Ces derniers se concentrent uniquement sur la gestion du développement de logiciels. En conséquence, le développement du logiciel en soi peut parfois être un sujet qui n’est pas suffisamment abordé. À mon avis, il est à noter que la programmation en soi peut être une tâche longue, souvent présentant de nombreux défis.

Au fil des ans, le développement de logiciels est devenu une tâche toujours plus complexe à réaliser. L’architecture logicielle d’aujourd’hui a de nombreuses couches (trois niveaux à sept niveaux) et doit être mis en œuvre sur une multitude de clients tels que les smartphones sur Android, tablettes et des appareils professionnels dédiés tels que les lecteurs de codes à barres.

Aussi les serveurs ont tendance à devenir de plus en plus complexe. À mon avis, les différentes méthodes agiles existantes n’abordent pas les questions liées aux bases de données complexes. Les possibilités offertes par les serveurs Oracle d’aujourd’hui surclassent vraiment celles offertes par les serveurs de base de données d’il y a 15 ans.

Dans les premiers jours du développement de logiciels, le déploiement tendait à être plutôt facile. Le programmeur pouvait copier le logiciel directement de son dispositif de développement vers la plate-forme qui prendrait part au processus de production. Personnellement, je me souviens des nombreuses discussions de l’année de 2009 que j’ai eues avec des professionnels contractuels qui ont fait valoir que le fait d’avoir à développer leur logiciel sur une plate-forme dédié au développement n’était autre qu’une simple perte de temps car un mois plus tard, après avoir passé la phase de test, le logiciel serait de toute façon mis en œuvre directement sur la plate-forme de production. Pourquoi donc ne pas directement effectuer la programmation dans l’environnement de production, m’a-t-on dit à plusieurs reprise, ce qui à l’époque prenait beaucoup moins de temps.

Heureusement, de nos jours les voies de développement sont devenues courantes. Lorsque vous souhaitez appliquer Scrum, en tant qu’architecte de logiciels, on ne peut organiser des sprints de maximum un mois de travail. Ce sprint devra alors fournir une « incrémentation du produit, potentiellement prêt à été implémenté en pratique » : une fonctionnalité entièrement achevée qui a subi un test complet au niveau requis pour la mise en œuvre dans le processus de production. Et tout ça dans quelques semaines. Du point de vue de la méthodologie Scrum, ce raisonnement semble bien acceptable. Cependant, dans la pratique ce n’est pas le cas. Malheureusement Scrum ne semble pas être disposé à aborder cette question.

Le coaching agile est un art en soi et nécessite une approche spécifiquement adaptée à l’entreprise et à l’équipe.

Cela m’amène à un autre aspect des méthodologies agiles. Lors de l’examen des discussions sur les plates-formes dédiées sur Internet, je trouve que les gestionnaires de logiciels sont souvent aux prises avec la mise en œuvre de ces techniques. Ils sont prêts à modifier profondément le processus de développement ou même à essayer toutes sortes de techniques artificiellement construites pour combler les échappatoires en essayant de rester dans le concept de Scrum.

Le concept de Scrum est que vous devez intégrer toute personne dont vous auriez besoin pour développer le code dans une équipe de développement. En conséquence, cette équipe de développement peut se concentrer sur le développement du logiciel sans perturbations ou interférences. Dans le cas où des obstacles se produiraient, il incombe au maître Scrum de contourner ces obstacles et de trouver des solutions.

Wendel Van Hespen Consui

Wendel Van Hespen – Directeur

Un exemple classique d’un problème qui se produit souvent lors du développement de logiciels dans la pratique, se compose de la programmation de logiciels qui doit interagir avec d’autres logiciels. Ces derniers seront bien entendu souvent gérés par une autre équipe, souvent même pas au sein de la même entreprise. Scrum dicterait dans ce cas précis de laisser l’autre équipe qui gère les autres logiciels s’intégrer dans l’équipe de développement. Cela semble bien sûr être une excellente approche en théorie, mais cela ne sera guère possible dans la pratique. Souvent, cela ne sera pas faisable en raison de restrictions légales, mais souvent aussi, il y aura des problèmes organisationnels empêchant la mise en œuvre de cette approche. En effet, que peut être fait par le maître Scrum de l’équipe de développement initiale lorsque les membres de l’autre équipe ne souhaitent pas respecter les délais des sprints du maître Scrum, quand ces derniers ne se soucient pas beaucoup de participer à des réunions ou encore quand ils se soucient encore moins de voyager plus de mille milles pour participer à une réunion de feedback?/span>

Je voudrais conclure en déclarant que les entreprises ne sont pas des universités. Ainsi, il n’y a pas d’argent à gagner pour avoir mis en œuvre Scrum de la meilleure façon. À mon avis, la façon dont la méthodologie a été mise en œuvre n’est pas plus importante que le résultat final. La méthodologie de gestion des logiciels doit être mise à la disposition de l’équipe en développement en tant qu’outil, mais il ne faut jamais que ce soit l’équipe qui doit s’adapter à tout prix à la méthodologie. Dans le cas où la mise en œuvre de Scrum n’ajoute pas à la valeur créée par le processus de développement, mais au contraire tend à être contre-productive, une autre méthode ou une autre approche doit être recherchée, une qui améliore la productivité. Néanmoins, il peut également être utile de vérifier le processus d’élaboration actuel qui est en place. En effet, si une méthodologie de développement ne fonctionne pas, il se peut aussi que le processus ne soit pas bien rationalisé.

• Philosophie, méthodologie et cadre

Le coaching agile aide à faire la distinction entre philosophies et methodologies, dans le but de pouvoir appliquer un cadre agile au moment de l’implémentation d’une technique agile de développement de logiciel spécifique.

En discutant des techniques agiles de développement de logiciels dans les paragraphes précédents ou d’autres sections, les gens ont tendance à utiliser un étrange mélange de mots ou de termes pour se référer à ces techniques, souvent pas vraiment familiers avec la terminologie à respecter. Pour cette raison, il est très pertinent de donner certaines explications sur des termes comme la philosophie, la méthodologie et le cadre ou Framework.

Scrum, par exemple, est un Framework ou cadre et non une méthode. Il offre un cadre dans lequel on peut développer des logiciels, ce qui mènera finalement à une méthodologie concrète au sein de l’équipe de développement, mais une autre équipe de développement pourrait très bien avoir développé et mis en œuvre une autre méthodologie, qui répond toutefois encore parfaitement aux exigences imposées par le cadre ou Framework Scrum.

DevOps

DevOps, ou Lean, est plus une philosophie. Ces modes de pensée ont tendance à proposer des idées ou des visions différentes sur la façon de procéder lors du développement de logiciels, mais la façon de mettre en œuvre ces idées est laissée de côté de l’équation. Il est compréhensible que de nombreuses entreprises ont développé des méthodologies pour mettre en œuvre les idées proposées par DevOps ou Lean et il y a beaucoup d’autres entreprises qui suivent dans leurs pas, mais au départ DevOps ou Lean sont des philosophies fournissant principalement des principes théoriques et directeurs.

Kanban, d’autre part, est plus une philosophie et une méthodologie en même temps. Le système de travail avec les cartes et le tableau kanban ainsi que les méthodes mathématiques de calcul et de limitation du WIP (Work in Progress ou travail en cours) fournit vraiment aux développeurs une méthodologie décente. Bien qu’il ne soit vrai que le tableau kanban peut être implémenté sous des formes ou des manières très différentes (un tableau blanc au mur, un tableau noir avec la craie, un panneau en bois avec des post-its ou un site Web sur un ordinateur), la manière de travailler avec lui est très bien défini et pas ouvert à interprétation. Même si le système a été basé sur une philosophie utilisée par Toyota lors de la mise en œuvre de son processus de production, il offre toutefois aussi plein de mesures concrètes et peut donc également être considéré comme une méthodologie.

Lors de la discussion de chacune des techniques agiles de développement de logiciels, les principales caractéristiques de chacune seront clairement définies et la distinction peut être faite entre les philosophies, les méthodologies ou les cadres. Naturellement, lorsqu’on se réfère à ces techniques en tant que groupe, les mots choisis pour les décrire peuvent être moins précis et plus généraux.

UNE AVENTURE DÉLICATE OU L’IMPORTANCE D’UNE MISE EN OEUVRE CORRECTE

Une aventure délicate ou l’importance d’une mise en œuvre correcte

Scrum indique clairement qu’il n’est ni permis de modifier les modalités de Scrum, ni d’adapter en tout ou en partie la structure imposée par Scrum.

Il est toutefois permis d’ajouter des éléments au cadre. Dans la pratique, cela conduit souvent à l’ajout de « story points » et de l’outil de planification « poker planning » à Scrum. Bien sûr, ces compléments ne font pas partie du cadre Scrum et ont été développés pour XP. Ce fait n’est pas connu de beaucoup et il semble à certains que les « story points » font toujours partie de Scrum. Il est clair que ce n’est pas le cas. On pourrait également opter pour travailler avec des « Ideal days » comme le directeur du logiciel Mountaingoat Mike Cohn a suggéré.

On dit souvent que si Scrum n’est pas correctement appliqué, il ne garantira pas les effets bénéfiques de Scrum. Cela peut ne pas être clair pour le lecteur du « Guide Scrum », mais à la fin de la lecture d’un livre comme « Software in 30 days » (« un logiciel en 30 jours ») par le fondateur Ken Schwaber il n’y aura plus de doute. Il faut dire que Scrum a fait ses preuves depuis plusieurs décennies et s’est donc avérée une méthodologie fiable menant au succès. Par conséquent, la méthodologie de Scrum mérite d’être respectée.

En conclusion, il est juste de dire que l’application des techniques agiles de développement de logiciels est un travail délicat, le mieux est donc de confier ce travail à des spécialistes dans le domaine. La mise en œuvre correcte d’une méthodologie spécifique est d’une grande importance car sans elle, aucun succès ne sera atteint ou en tout cas en moindre mesure. Bien sûr, certains des principes ou des lignes directrices sont d’une plus grande importance que d’autres, mais comme il n’est pas facile pour un novice de distinguer entre ceux-ci, il est judicieux de ne pas se lancer dans une vraie aventure. Par conséquent, un coach agile est vraiment recommandé. Les résultats suivront sans aucun doute.

implementation

Le raisonnement ci-dessus est valable pour Scrum mais aussi pour toutes les autres techniques de développement agile.

Une définition et une explication claires du cadre aident souvent à la compréhension des principes et des lignes directrices d’une méthodologie agile spécifique, qui peut être très stricte dans le libellé, mais peut s’avérer moins sévère lorsqu’elle est mise en œuvre. En conséquence, les membres de l’équipe de développement seront plus à l’appui de la nouvelle mise en œuvre d’une des techniques agiles de développement de logiciel.