Pentacomp utilise le cadre Nexus pour fournir efficacement des systèmes

Pentacomp utilise le cadre Nexus pour fournir efficacement des systèmes


Cet article a été initialement publié sur scrum.org

https://scrumorg-website-prod.s3.amazonaws.com/drupal/2021-04/Pentacomp2021%20%282%29%20%281%29.pdf

Le Défi

Pentacomp travaille avec son client, le Ministère de la Santé en Pologne, sur le développement de plusieurs produits logiciels, y compris une plateforme d’e-prescription qu’ils appellent e-santé. Le Ministère de la Santé travaillait sur ces produits depuis une décennie et avait besoin d’une nouvelle solution pour les aider à fournir leurs systèmes complexes.
Le Ministère de la Santé a testé différentes approches pour le développement de l’e-santé et a décidé que Scrum était le mieux adapté pour eux et a initialement travaillé avec 5 équipes Scrum distinctes. À mesure que des commandes supplémentaires sont venues du client, 2 autres équipes ont été ajoutées, dont une d’un deuxième fournisseur, totalisant ainsi 7 équipes Scrum, et encore une fois, ils ont ajouté 2 autres équipes, totalisant près de 100 développeurs répartis sur 9 équipes Scrum pour soutenir le système e-santé en pleine expansion.

À mesure que le système e-santé se développait, le nombre de capacités, de composants et d’assemblages augmentait, créant une complexité et des dépendances accrues. L’intégration devenait très difficile avec leur étendue de travail en constante augmentation. Les équipes rencontraient des problèmes de communication et de transparence parmi les développeurs.

La Solution

Pour résoudre ces problèmes, Pentacomp a décidé de mettre en œuvre le cadre Nexus pour l’initiative e-santé. Ils ont testé plusieurs autres approches avant de choisir Nexus mais ont finalement trouvé que Nexus était le mieux adapté. Le Ministère de la Santé était très impliqué dans la décision d’utiliser Nexus pour étendre Scrum et a trouvé que c’était le plus adapté pour leurs équipes puisqu’ils utilisaient déjà Scrum.
Passer de Nexus à Nexus+

Un défi majeur qu’ils ont rencontré quelques mois après l’utilisation de Nexus était qu’ils trouvaient que les équipes étaient désalignées, ce qui créait des défis lors de la commande de leur Product Backlog révélant que les équipes du Nexus travaillaient sur des flux de travail séparés. Ils ont décidé de se séparer en 2 flux de travail distincts. Chaque flux est devenu un Nexus, et ensemble, cela est devenu ce que l’on appelle un Nexus+, plusieurs Nexus travaillant ensemble représentant une famille de produits pour le Ministère de la Santé. Le premier flux était destiné aux logiciels axés sur leur domaine principal : Compte Patient en Ligne et services d’e-prescription. Ces produits comprenaient des e-références, des prescriptions transfrontalières, des patients mobiles et des capacités d’enregistrement de vaccins Covid-19. Le deuxième flux a mis en œuvre l’échange d’informations de santé, y compris la documentation médicale électronique et les rencontres médicales. Il y avait encore besoin d’une intégration entre les 2 Nexus afin de fournir une expérience cohérente pour les patients. À mesure que les équipes évoluaient, elles travaillaient à être cohérentes dans leur utilisation de Scrum, des principes, des valeurs et de la culture, une mentalité de produit collaborative et une agilité, tout en augmentant l’efficacité. Chaque Nexus était considéré comme un produit séparé, ils ont donc introduit un autre Product Owner, ce qui en faisait un pour chaque Nexus. Par conséquent, au sein du Nexus+, il y avait 2 Nexus (un pour chaque flux de travail ou produit). Chaque flux de travail avait son propre Product Backlog et Product Owner.

Initialement, en tant que Nexus+, chaque Nexus organisait des sessions séparées de planification de sprint Nexus, de rétrospectives de sprint Nexus, de réunions quotidiennes Nexus et de sessions de raffinement inter-équipes. Ils avaient des Définitions de Fait communes et conservaient les mêmes principes de conception à travers les Nexus. Ils avaient également une revue de sprint commune Nexus+.

Après plusieurs sprints, ils se sont rendu compte que la tenue d’événements de sprint Nexus individuels masquait les interdépendances entre les deux Nexus. Par conséquent, ils se sont adaptés pour avoir une session de planification de sprint commune Nexus+, définissant la direction commune du travail dans les deux domaines, les relations, les dépendances et les plans à long terme. Ils ont également commencé à avoir une rétrospective Nexus+ et une réunion quotidienne Nexus+ pour les deux Nexus ensemble. Ils ont gardé deux Product Owners séparés en traitant chaque Nexus comme son propre produit et ont tenu une session de raffinement inter-équipes Nexus+ en plus des sessions de raffinement inter-équipes dans les Nexus individuels. Il y avait un fort accent sur la communication cohérente vers l’intégration, l’élimination des déchets, la résolution des incohérences, les objectifs du produit et la valeur client.

En plus de synchroniser les événements au niveau Nexus+, les équipes ont également appliqué d’autres pratiques pour aider à résoudre leurs problèmes de transparence et d’alignement :

  • Assurer une Définition de Fait claire pour tous les éléments du Product Backlog
  • Développer des règles et des normes (gitflow, création d’une analyse, pyramide de test, règles pour la création de documentation, etc.)
  • Synchroniser régulièrement entre la Propriété du Produit et le client
  • Utiliser une réunion quotidienne Nexus+ pour faire émerger les dépendances entre les Nexus
  • Maintenir un seuil de 15 % de chaque sprint dédié à la gestion de la dette technique selon les besoins
  • Organiser un « Big Retro » : une fois tous les quelques mois après les principales mises en production avec les équipes Scrum et le client présents lors d’une réunion durant plusieurs heures. Les clients ont participé à ces rétrospectives et ont interagi directement avec les équipes Scrum, ce qui était très utile et motivant.

Les Résultats

Une fois que les Nexus étaient déjà opérationnels, la pandémie de Covid-19 est apparue. Ils n’étaient pas sûrs de la façon dont les Nexus allaient fonctionner à distance, mais cela a bien fonctionné et, plus important encore, leurs produits sont devenus plus critiques que jamais. Les patients pouvaient facilement obtenir leurs prescriptions sans se rendre chez le médecin grâce à leur produit e-santé. Le système qu’ils ont construit a aidé à sauver le système de santé polonais de l’effondrement. Ils ont reçu de nombreux éloges du Ministère de la Santé pour cela. (https://pacjent.gov.pl/e-recepta/porady-lekarskie-i-e-recepty)
Avant Nexus, le Ministère de la Santé publiait moins fréquemment :

“En 2018, nous avions 5 publications, en 2019 nous en avions 3, en 2020 nous en avions 6. En janvier 2021 (au moment de la rédaction de cette étude de cas), nous avons déjà eu 4 publications », a déclaré Hanna Ochmańska, Scrum Master.

Leurs temps de cycle continuent également de se raccourcir, actuellement en moyenne à 11 jours. Ils travaillent actuellement sur des modules de rendez-vous en ligne et de téléconsultation et prévoient de les terminer en 2021. En raison de la portée croissante des fonctionnalités, ils ont élargi la composition du projet avec une autre équipe en raison des commandes supplémentaires du client, et travaillent actuellement dans 9 équipes.

L’Entreprise

Pentacomp conçoit des solutions informatiques innovantes, maintient et entretient des systèmes informatiques, et fournit des conseils aux entreprises dans divers secteurs. En réalisant des projets stratégiques, l’équipe Pentacomp soutient depuis 25 ans les plus grandes organisations et entreprises dans leur quête de succès et de gain d’avantages concurrentiels. Cette étude de cas parle de son travail avec le Ministère de la Santé en Pologne.

À propos de Scrum.org

Scrum.org, la Maison de Scrum, a été fondée par Ken Schwaber, co-créateur de Scrum, en tant qu’organisation basée sur une mission visant à aider les personnes et les équipes à résoudre des problèmes complexes. Nous le faisons en permettant aux gens d’appliquer Scrum Professionnel grâce à des cours de formation pratiques, des certifications reconnues mondialement et un apprentissage continu basé sur un modèle de compétence commun.
Scrum.org soutient les gens où qu’ils en soient dans leur parcours d’apprentissage, du débutant au praticien très expérimenté, les aidant à évoluer au fil du temps avec des opportunités d’apprentissage et des ressources continues. Les membres de la communauté partagent leurs connaissances et acquièrent de nouvelles perspectives les uns des autres en utilisant des forums, des blogs et plus encore.