réflexion sur les agendas des managers Agile

"Une entreprise dont l'agenda des managers est pleine n'est pas Agile".
Managers et vous, vous êtes dans quelle queue?  citation et photo de Oana Juncu Founder at cOemerge, Agile Organisation facilitator

 C'est de cette citation et photo que ma réflexion a commencée.

Les cérémoniaux de la méthode Agile sont :
-la planification de la release
-planning poker
-revue de sprint
-rétrospective de sprint
-scrum quotidien 

Ils ont chacun  un rôle qui sera  décrit dans un prochain post, il est bien sur indispensable de les planifier et de les respecter. La régularité est importante pour réussir le projet.

Comment le manager va s'organiser avec ces réunions et l'agilité ?  C'est de la gestion du temps.

Il doit dans son planning prévoir du temps pour l'imprévu: Avoir des plages de réunions planifiées et des plages de temps pour les réunions non planifiées.
par exemple :
10h à 12h et 14h  à 17h pour les réunions plannifiables
Il se garde de 9h à 10h,  12h à 13h et de 17h à 18 h  pour gérer les imprévus.
Pour cela, il doit mettre dans son agenda partagé que ces plages horaires sont occupées.

Ceci est un exemple bien sur, qui doit être adapté en fonction de la vie du projet et de l'entreprise. Il faut garder comme idée qu'il doit y avoir du temps pour l'imprévu. C'est à chacun de s'organiser en fonction de ses contraintes.

Qu'est ce qu'un planning poker ?

 C'est une méthode qui permet d'estimer les Users Stories (US)  du Back Log

Chaque Story doit être estimée afin de faire la planification des stories dans un sprint.
L'estimation se fait en fonction des autres User Story. Elles n'ont pas toutes la même taille ou la même complexité même si on essaye de la simplifier au maximum.

 L'usage courant est de faire une estimation collective au cours d'une séance appelée planning poker.
 C'est une scéance d'estimation en groupe avec des cartes qui combine le jugement d'expert et l'estimation par anologie.

 Déroulement du planning pocker.

Chaque participant reçoit un jeu de cartes. Sur chaque carte, il y a une valeur possible pour l'estimation  d'une story:
- le PO présente la Story
- les membres de l'équipe posent des questions pour bien comprendre et débattent brièvement
- tous les participants présentent en même temps la carte choisie pour l'estimation.
- le groupe discute des différences éventuelles
- le deuxième tour de vote permet à l'équipe de se mettre d'accord sur l'estimation de la story

La suite de Fibonacci est trés souvent utilisée. Cette suite prédéfinie  {0, 1, 2, 3, 5, 8, 13} permet  d'estimer la taille de la US par rapport aux autres. Si la US est trop complexe (supérieure à 13), c'est quelle a besoin d'être retravaillée par le PO.

Le planning poker est présenté comme une technique d’estimation. C’est vrai, mais en forçant un peu le trait les estimations ne sont qu’un bénéfice secondaire de l’exercice. Estimer via le planning poker permet surtout de:

• d’éclaircir et partager de manière itérative et incrémentale les fonctionnalités du produit que nous développons ;
• de le faire de manière collaborative et avec un cérémonial qui permet à tous de s’exprimer ;
• tout en promouvant le design logiciel collaboratif et émergent.

Qu'est ce qu'un ScrumMaster ?

Définitions:
 
SrumMaster est un terme utilisé dans la méthode Agile Srum 
Un SrumMaster n'est pas un chef de projet car dans la méthode agile Srum il n'y en a pas.

L'équipe de développement s'auto organise : les membres de l'équipe s'organisent eux même et non pas besoin de chef pour leur assigner le travail à faire.

Le SrumMaster a pour responsabilité essentielle  d'aider l'équipe  à réaliser les travaux demandés par le Product Owner, en appliquant Srum dans le contexte de l'organisation.

SrumMaster signifie littéralement maître de la mélée. Le terme Scrum vient du rugby. Le poste de demi de mêlée est celui qui se rapproche le plus de l'idée de ScrumMaster.

Travaux du ScrumMaster

Tâches périodiques

Mettre en application Scrum en organisant et animant les réunions qui constituent le cérémonial :

• Planification du sprint.
• Mêlée quotidienne.
• Revue du sprint.
• Rétrospective.

Tâches sur évènement

• éliminer les obstacles : prendre en compte les problèmes qui surviennent à tout moment sur un projet pour les éliminer au plus vite, en évitant qu'ils ralentissent l'équipe. Il protège l’équipe des interférences extérieures.

Tâches de fond

• faire en sorte que l’équipe reste concentrée sur le véritable objectif du projet, qui est de réaliser les éléments du Backlog en collaboration étroite avec le Product Owner, et soit productive. Il s'assure que chacun participe pleinement aux travaux de l'équipe.
• communiquer avec le management. La transparence est de mise avec des rapports d'avancement comme les burndown charts ou mieux des burnups.

Quelles sont ces compétences ?

Les compétences et l'expérience souhaitées dépendent de la taille, de la complexité technique et du type de gouvernance. Les qualités nécessaires pour jouer efficacement ce rôle :

• bien connaitre Scrum,
• avoir des facilités de présentation, de communication et de négociation,
• guider sans imposer,
• faire preuve de qualité de meneur d'hommes et savoir motiver une équipe,
• savoir résoudre les conflits et les problèmes,
• communiquer honnêtement sur le degré d'avancement,
• garder le respect de l'objectif essentiel, qui est de livrer un produit qui apporte de la valeur.

Qu'est ce qu'une User Story?

Une User Story est une fonctionnalité du back log. 

Dans la méthode Srum on appelle cela un Item. 

Cet élément doit être le plus élémentaire et le plus simple possible. 

Modèle de structure d’une User Story

-En tant que <rôle, persona, user type>

-Je veux <fonctionnalité, tâche, action>

-Afin de <valeur ajoutée, résultat>

Pour qualifier la taille et la qualité d'une US, on peut utiliser le Pattern et  critères de qualité INVEST

I – Independent

N – Negotiable

V – Valuable

E – Estimable

S – Size

T – Testable

La réaction des users-stories est de la responsabilité du PO. Il doit  penser à faire simple. 

Ce qui ne veut pas dire simpliste.  Einstein disait  : Rendez les choses aussi simple que possible, mais pas plus simple. *.

 Il faut continuer à expliquer les règles de gestion, les règles de calcul (au travers de tests d'acceptation c'est encore mieux). 

Et pour finir des citations de  Léonard, Antoine et Steve : 

• La simplicité est la sophistication suprême. Leonard de Vinci
• La perfection est atteinte, non pas lorsqu'il n'y a plus rien à ajouter, mais lorsqu'il n'y a plus rien à retirer. Antoine de Saint-Exupéry
• La simplicité peut être plus difficile à atteindre que la complexité : il faut travailler dur pour arriver à faire simple. Steve Jobs

Qu'est ce qu'un backlog produit?

Une première définition du Product Backlog peut être :

« l'ensemble des fonctionnalités du produit que l'on veut développer »

 Mais ce n’est pas un cahier des charges !

Les fonctionnalités sont stockées dans le back log mais sont détaillées au fur et à mesure du projet. Elles sont priorisées régulièrement et ainsi on ne développe que les fonctionnalités nécessaires aux utilisateurs.  On simplifie le produit.

Alors que lorsque l'on doit tout spécifier dès le départ dans une expression de besoin "exhaustive", on a tendance à mettre absolument tout ce à quoi on pense, et de peur d'en oublier on s'efforce de penser à tous les cas de figure imaginables.

Les fonctionnalités du  Product Backlog  sont priorisées afin de fonctionnalités, le but étant  d'implémenter en premier ce qui rapporte  le plus de valeur. On considère en premier les items ayant une plus grande valeur métier.

Un élément  du Product Backlog n'a raison d'exister que si il apporte de la Valeur.

Le product Backlog peut être alimenté au fil de l’eau. 

Les Items ou Users Stories pourront donc être alimentés  ou supprimés lors de la vie du projet afin de produire uniquement les fonctionnalités utiles à l'utilisateur.

Ce mode itératif d'alimentation du backlog permet de ne pas rester figé dans une vision initiale mais permet en fonction des premiers sprints et de ses résultats d'adapter le produit au besoin des utilisateurs. 

Qu'est ce qu'un product Owner?

Le Product Owner a un rôle important dans un projet conduit en mode Agile.
C'est l'équivalent d'un Moa dans un projet en cycle en V.

Il est le représentant des utilisateurs . Il n'est pas un directeur de produit, il donne bien la direction fonctionnelle  mais n'a pas de responsabilité hiérarchique  sur des personnes.

Il prend des décisions de niveau stratégique comme la décision de la date de livraison du produit et de son contenu.

Le product Owner doit avoir une bonne vision du produit. La vision se construit au début du projet et se consolide ensuite. 

Tous les membres de l'équipe et tous les parties prenantes du projet doivent partager la même vision et c'est au PO de s'en assurer.

Voici le rôle du Product Owner

- être le représentant du client ou des utilisateurs.

- récolter les attentes, besoins, exigences du client ou des utilisateurs et les priorités associées.

- formaliser le backlog de produit avec le niveau de précisi on adapté à la priorité

- être en mesure de les expliquer au Scrum Master et à l’équipe de

développement ou d’inviter le client et/ou un utilisateur pour le faire.

- définir le planning des releases dans lesquels les Sprints s’inscriront

Google est il Agile ?

J'ai eu l'opportunité lors de mes dernières vacances à San Francisco de me  rendre sur le campus de Google.  Nous avons aussi pu avoir accès au show room réservé au visiteur.

Suite à cette visite, j'ai eu envie d'analyser l'agilité dans cette grande entreprise de plus de  10000 développeurs et de plus de 30 000  personnes.
La visite du  show-room nous a permis de faire quelques photos mais pas d’apprécier en détail  leur méthode de gestion de projets.
Mon point de vue s'est alors basé à la fois sur ma connaissance de Google, mes impressions de ma visite sur le campus et sur les références ci dessous:

http://blog.beule.fr/analyses-dexpert/lagilite-chez-google/


https://youtu.be/3DfZi3ooyfE

Et en voici mon résumé et ma conclusion :

La taille et l’organisation de Google sont des paramètres à prendre en compte impérativement pour comprendre les contraintes et enjeux :

• plus de 10 000 développeurs répartis sur plus de 40 pays
• 50% du code existant change tous les mois
• plus de 20 modifications sont décomptées par minute

Google travaille en effet en méthode agile, en mettant en production des versions quotidiennement.

Des équipes de  5 personnes travaillent à la réalisation d'une fonctionnalité. L'équipe est dissoute à la fin du projet pour aller travailler sur une nouvelle fonctionnalité.

Au niveau des réunions , Google suit bien les  cérémoniaux de la méthode agile : daily scrum, planning poker, sprint planning, démo, rétrospective mais les réunions sont courte  15 mn environ pour une rétro hebdo à 1h pour une rétro mensuelle.

Au niveau du back log une spécificité la ICE Box, des idées congelées en amont qui serviront à l'alimentation future du back log.

Cependant si l'on reprend les manifestes de l'agilité :

1. Les individus et leurs interactions plus que les processus et les outils
2. Des logiciels opérationnels plus qu’une documentation exhaustive
3. La collaboration avec les clients plus que la négociation contractuelle
4. L’adaptation au changement plus que le suivi d’un plan

Je ne doute pas des points  2 et 4, pour le point n°1 je n'ai pas suffisamment de recul pour juger.
Quand au point numéro 3, les clients de Google ne payent pas mais il n'y a pas de collaboration ou de négociation entre les équipes Google et les utilisateurs.
 La réponse est donc oui Google travaille en mode agile!!