les questions que le management se pose…

Capture d'écran 2014-08-25 16.11.55

Demain, la direction d’une grande banque internationale m’a demandé d’intervenir pour expliquer Scrum.

Nous nous connaissons déjà depuis de nombreuses années et leur expérience en matière de Scrum est importante ainsi que la maturité générale en matière de gestion de projet: Lean Six Sigma, Prince 2, ITIL, TOGAF (pour les puristes, ITIL et TOGAF ne peuvent être considérées comme méthode de gestion de projet). Cela ne signifie pas que je vais débarquer en terre inconnue, mais plutôt qu’ils ne vont pas se gêner pour me challenger. Ce qui, soit dit en passant, est une excellente étape vers plus d’agilité.

Comme notre réunion sera time-boxée, les questions m’ont été envoyée ce soir. Et, je me ferai un point d’honneur d’y répondre le plus clairement possible. Après lecture de celles-ci, je me suis dit que celles-ci reflétaient une grande partie des interrogations sur le sujet de l’agilité dans la direction des grandes organisations matures.

  1. Comment implémenter Scrum dans une entreprise?
  2. Quels profils sont les mieux adaptés pour cette méthode?
  3. Partage d’expérience qui se sont bien passées, mal passées en quelles en sont les causes?
  4. Comment est défini un cadre de sprint?
  5. Que ce passe-t-il avec les items exclus du Sprint?
  6. Comment le produit final est-il assemblé avec toutes ces petites pièces?
  7. Les  différences entre un chef de projet et un scrum master?
  8. La meilleur manière de tester dans un environnement agile?
  9. Comment combiner le modèle en cascade et scrum?
  10. Les contrôles clefs applicables à chaque point d’étape sachant que ces points sont un peu flou à présent?
  11. Avec Scrum, atteignons-nous nos objectifs courants et comment les mesurer?
  12. Comment serait une mesure d’amélioration continue avec Scrum?
  13. Comment fonctionne Scrum dans un développement constitué de participants clefs répartis sur 2 sites off-shore?
  14. «La proximité au métier / parties prenantes du projet est l’un des facteurs clés de succès dans l’approche de Scrum. Comment cela fonctionne pratiquement dans un modèle de scrum distribué (sur site ou offshore ->global delivery model) »
  15. «La gestion du changement est la clé lors de l’introduction / l’exécution des projets basés scrum alors que l’organisation utilise  largement les modèles SDLC traditionnels. En outre, il n’y a pas seulement l’équipe informatique qui a participé dans les livraisons ou les sprints de livraison de scrum de base mais cela touche également les autres parties prenantes de l’entreprise, etc infra ainsi être engagé et impliqué. Comment pouvons-nous permettre cela dans une organisation qui utilise largement les modèles traditionnels SDLC. »

Quelques éléments de réponse :

  • Comment implémenter Scrum dans une entreprise?

Dans un monde idéal, on démarrerait l’implémentation de Scrum sur un projet pouvant répondre à l’ensemble des questions habituelles qu’un projet puisse répondre à l’organisation de l’entreprise: livrer en temps et en heure, livrer de la qualité, avoir des clients content du résultat, ne pas générer de risques ingérables pour l’organisation, faire progresser la maturité des employés.

Une fois que le premier Scrum a rempli sa mission ou que la solution livrée se complexifie ou que le produit s’agrandisse, l’équipe du premier Scrum est éclatée et plusieurs sous équipes Scrum sont constituées. Forts de l’expérience acquise lors du premier Scrum, les "développeurs" sont appelés à s’engager sur l’un des deux rôles ou Scrum Master ou Product Owner. Le Scrum Master et le Product Owner du premier projet pourront monter en maturité en abordant une nouvelle approche de Scrum au niveau de la gestion de programme: coordination des scrums, alignement, scrum-of-scrums, gestion de portefeuille.

Une des conséquences de cette démarche est que les Scrum Master et Product Owner du départ disposeront toute la connaissance nécessaire sur le cycle de vie du produit.

  • Quels profils sont les mieux adaptés pour cette méthode?

Scrum nécessite 3 types de profils: Scrum Master, Product Owner et Développeurs.
Les développeurs sont des personnes ayant les compétences nécessaires pour permettre le développement du produit.
Scrum Master sont les animateurs. Cela signifie que les gens ayant un sens de la facilitation, la coordination, l’esprit d’équipe, le coaching, soucieux de conduire le changement. Dans un monde parfait de «agile», je choisirais gens des ressources humaines.
Propriétaires de produits sont «chefs de produits» conduite le produit ou la fonction pour faciliter la livraison rapide de l’augmentation potentiellement livrable du produit. Ils sont responsables de la ROI et Time-to-market. Si j’étais libre de choisir, de nos jours, je choisirais quelqu’un avec UX (expérience utilisateur) connaissances.
Les deux Scrum Master et Propriétaires de produits n’ont pas les compétences techniques. C’est à l’équipe de développement avec le soutien de responsables techniques externes ou architecte si nécessaire.

  • Que ce passe-t-il avec les items exclus du Sprint?

Le principe que nous utilisons dans Scrum est le burndown du backlog qui permet une discussion au niveau des participants du projet lors des revues. Les items exclus du projet peuvent prendre deux directions:

- soient ils sortent du sprint backlog et retournent dans le product backlog pour un développement ultérieur: dans la même Release ou dans une prochaine Release

- soient ils disparaissent tout simplement car ils n’apportent plus aucune utilité au développement du produit.

Cette gestion est sous la responsabilité du Product Owner.

  • Comment le produit final est-il assemblé avec toutes ces petites pièces?

Le but de Scrum est de fournir incrément potentiellement livrable du produit. Cela signifie que toutes les pièces du produit doivent être assemblés à la fin du Sprint. Parfois, cela est plus compliqué en raison de plusieurs fonctionnalités ou des streams, mais gardez toujours à l’esprit que tout doit être assemblé à la fin du sprint. Si non, vous devez améliorer le cycle de vie de développement de produits et hiérarchiser le product backlog en fonction des dépendances émergentes.

  • Les  différences entre un chef de projet et un scrum master?

Si vous comprenez Scrum, vous pouvez découvrir que le rôle central du chef de projet n’existe plus. Ce rôle est entièrement distribué dans l’équipe Scrum (Product Owner, Scrum Master et l’équipe de développement).
Le Project Management Institute décrit qu’un projet est basé sur deux éléments: le produit et le processus.
Dans Scrum, nous avons un rôle pour les deux parties. Le Product Owner gère le développement de produits et suit le time-to-market et le retour sur investissement du développement. Le Scrum Master, qui travaille en paire avec le Product Owner, est responsable pour le processus (Scrum) et gère les capacités et les risques.
L’équipe de développement est en charge de l’ingénierie et de la qualité.
Nous découvrons que Scrum a permis d’augmenter la maturité de la gestion de projet parce que toutes les compétences sont réparties au sein de l’équipe Scrum.
Un point d’attention: dans Scrum, l’équipe est entièrement dédiée au projet. Cela signifie que si un membre de l’équipe doit sauter dans un autre projet pendant le sprint et sauter en arrière plus tard: c’est contre-productif. Donc ici, la gestion des capacités ne signifie pas l’allocation de ressources transverses dans le portefeuille projet, mais la mesure de la disponibilité des membres.

  • La meilleur manière de tester dans un environnement agile?

Jetez un oeil de votre développement si vous testez après le développement. Ce qui se produit? Tester sont en train de perdre beaucoup de temps et les développeurs doivent rester disponibles pour corriger les défauts. En d’autres termes, le développement n’a pas vraiment arrêté à la date d’échéance.
Le défi dans le développement agile est de faire du développement et de tests en parallèle.
Comment tester en agile dépend de votre stratégie de développement et du la taille de votre équipe.
Pour une petite équipe. test sera intégré en tant que partie intégrante du processus de développement de test de l’unité de l’intégration.
Pour des programmes plus importants, peut-être vous avez besoin d’une équipe d’intégration en parallèle avec d’autres développements équipes. Cette équipe intègre les incréments de chaque équipe et tester. Une stratégie est que cette équipe commence un sprint après les sprints de développement de sorte que, dans le cas du refactoring, équipes de développement ne perdent pas la connaissance du sprint passé pour fixer la dette.

  • Comment combiner le modèle en cascade et scrum?

Scrum et waterfall s’est un peu comme mélanger l’huile et l’eau. C’est presque un point de la stratégie.
Si vous avez un grand programme où les gestionnaires, Comité directeur, le sponsoring ne sont pas passés agile, vous pouvez garder un soupçon de waterfall pour ne pas trop les stresser. A ce niveau, vous pouvez fixer une charte de projet, une gouvernance, une feuille de route et des points de qualité.
Si vous jetez un coup d’oeil à un sprint, vous trouverez du waterfall de séquençage dans l’approche. Ce n’est pas contre Scrum si c’est la décision de l’équipe.
Le vrai problème n’est pas cascade mais le «coût de retard" dans le waterfall à savoir si le waterfall soutient l’approche empirique et la culture agile, alors vous pouvez l’utiliser.

  • Les contrôles clefs applicables à chaque point d’étape sachant que ces points sont un peu flou à présent?

En ce qui concerne les contrôles clés à chaque stade, nous essayons de garder les choses simples et visibles dans Scrum.
Au stade du Sprint, je m’attends à voir
– Product Burndown, qui visualise le montant des travaux à faire jusqu’à ce que nous atteignions notre release
– Vélocité, qui est la somme des éléments finis dans le sprint. Cela aide le Product Owner à prévoir quand nous pourrons livrer ou les fonctionnalités qui seront faites dans une sortie fixe
– L’Impediment Backlog est un excellent outil mettant en évidence les obstacles et les risques émergents. Cet arriéré améliore la visibilité réelle de la capacité de l’équipe et favorise la prise de décision de la direction des mesures si les obstacles sont plus larges que l’équipe.

Des contrôles supplémentaires sont réalisables pour des programmes plus vastes où nous utilisons Cost-Performance-Index et Schedule-Performance-Index d’ EVM.

L’ajout de KPI ajoute de la discussion. Nous recherchons des mesures aidant à prendre des décisions.

  • Avec Scrum, atteignons-nous nos objectifs courants et comment les mesurer?

Avec Scrum nous arrivons à la plupart de nos objectifs actuels lorsque ces objectifs sont clairs depuis le début. Si la vision, le cadre et la Definition-of-Done du projet n’ont pas été clairement définies (à haut niveau) et le management s’attend à ce que leurs réponses émergent du travail d’équipe, nous allons espérer avoir un coup de chance que nous allons découvrir quelque chose d’inconnu.
En revanche, comme je l’ai décrit avant, vous commencez un Scrum avec un Product Backlog initial qui devrait être consommé. C’est un premier indicateur.
A la fin de Sprint, nous avons la revue de sprint qui n’est pas seulement une démo mais plus le Inspect-and-adapt des parties prenantes. Ici lors de la réunion, le Product Owner accepte des articles "done" et rejète les "not-done".
Pour s’assurer que tous les objectifs sont atteints, nous utilisons "Definition-of-Done" et "Definition-of-Ready», selon différents niveaux de Done nécessaires. C’est le travail du Product Owner, sur une base quotidienne.

  • Comment serait une mesure d’amélioration continue avec Scrum?

L’amélioration continue est au cœur de Scrum c’est pour cela que nous appelons Scrum un processus de développement empirique.
A la fin de chaque Sprint, l’équipe Scrum a une rétrospective où les membres réfléchissent sur les leçons apprises et comment ils peuvent améliorer leur travail. Le résultat de cette réunion sera utilisée dans le prochain sprint.
L’ensemble de Scrum est basé sur l’amélioration continue:
– Daily scrums sont les Inspect-and-adapt de l’équipe Scrum
– Sprint examen sont les Inspect-and-adapt des parties prenantes
– Rétrospective
– Sprint Planning utilisera les résultats de ces améliorations pour la prochaine itération.

  • Comment fonctionne Scrum dans un développement constitué de participants clefs répartis sur 2 sites off-shore?

Scrum peut être très utile pour la gestion offshore. Plusieurs points doivent toujours être pris en compte:
– Équipe Scrum co-localisée
– Faciliter la communication
Équipe Scrum co-localisée signifie que le Product Owner et le Scrum Master doivent travailler au sein de l’équipe. Les réunions de synchronisation peuvent être facilement suivies à travers des dispositifs de communication.
La grosse erreur serait d’avoir le Scrum Master et le Product Owner sur ​​site et le développement offshore. Si vous êtes organisé de la sorte, il y a de forte chance que votre équipe ne suive pas Scrum.

  • «La proximité au métier / parties prenantes du projet est l’un des facteurs clés de succès dans l’approche de Scrum. Comment cela fonctionne pratiquement dans un modèle de scrum distribué (sur site ou offshore ->global delivery model) »

Dans la pratique, dans Scrum, nous avons prévu des réunions où le métier est impliqué ou invité à participer comme la planification Sprint et la Sprint Review. La Revue de Sprint est obligatoire, parce que c’est le seul moment où le métier peut officiellement rencontrer l’équipe de développement.
Tout au long du sprint, le Product Owner travaille toujours avec le métier pour prioriser les items produits du product Backlog ou pour discuter de résultats attendus ou d’une stratégie de release.
Cela est vrai pour le modèle de livraison offshore ou pour le Global Delivery Model  mais aussi pour le développement sur site . Il devrait y avoir aucune différence.
Pour le Global Delivery Model, vous pouvez trouver un groupe de Product Owners restant connecté avec le métier.
Enfin, le projet ou la gouvernance du programme doit fixer une ou plusieurs réunions dédiées à obtenir un engagement de l’entreprise dès le début.

  • «La gestion du changement est la clé lors de l’introduction / l’exécution des projets basés scrum alors que l’organisation utilise  largement les modèles SDLC traditionnels. En outre, il n’y a pas seulement l’équipe informatique qui a participé dans les livraisons ou les sprints de livraison de scrum de base mais cela touche également les autres parties prenantes de l’entreprise, etc infra ainsi être engagé et impliqué. Comment pouvons-nous permettre cela dans une organisation qui utilise largement les modèles traditionnels SDLC. »

Le modèle SDLC fournit une approche traditionnelle de la cascade. Agile et Scrum en particulier challengent  l’ancien système, par l’augmentation de la rapidité de livraison.
Cette question a une grande portée et implique un nouveau type d’approche organisationnelle.
De nos jours, dans la communauté agile nous testons de nouveaux concepts comme LESS, DAD et SAFe où le développement est tiré par l’intégration. Les principales idées sont venues de DevOps qui prennent en considération le fait que "potentiellement livrable» signifie «livrable». C’est une vue panoramique.
Dans mon expérience, j’ai travaillé pour une société mondiale 24/7 utilisant Scrum et nous avons utilisé ce processus:
– L’équipe Scrum à base Europe a travaillé pendant une journée de travail européen
– L’après-midi, l’équipe américaine «child» prend son travail et ajoute de nouveaux travaux du Sprint Backlog commun
– Au cours de la nuit, les testeurs de Pékin s’occupent de tous les tests (sauf les unitaires)
– Le lendemain l’équipe Europe peut travailler sur de nouveaux articles ou refactorer.

Les gens de l’infrastructure font partie des équipes de développement, ainsi que QA.
Les réunions Scrum sont prévues pour que toutes les parties prenantes participant aux sessions en ligne et celles-ci sont enregistrées.
En ce qui concerne l’entreprise, QA, UX, l’Infrastructure ou l’Architecture, sont dans plusieurs «flux» ou «tribus» pour consolider et apporter leur support aux différentes équipes.