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 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

Voyage en mode agile : le bilan

Comme dans un projet informatique gèré en agile, un projet de voyage comporte une partie bilan.

C'est le moment où tous participants font le point ensemble, ils disent les choses qui se sont bien passés et les choses qui se sont moins bien passés.

Les points forts:

- adapter les étapes à la réaliser du terrain. Les espaces sont grands, les temps de trajets sont importants

- le rythme de vacances n'est pas aussi rapide que celui du travail.

Il faut tenir compte du décalage horaire à l'arrivée, prévoir 24h à 48h pour s'habituer à la nouvelle civilisation du pays: monnaie, différence des mesures, de la langue, conduite ....

Les points faibles :

- l'organisation macro entraîne régulièrement des questions : qu'est ce que l'on fait?  

Il faut pour chaque période planifier l'hébergement, recadrer éventuellement le parcours ....

En conclusion, l'agilité dans un voyage est plutôt réservé à des experts du voyage qui arrivent à s'exprimer au moins en anglais et qui acceptent en voyage d'improviser au jour le jour leur voyage en fonction de leurs inspirations mais aussi de leurs rencontres.

Je vous recommande un site internet fait par des voyageurs agiles

www.peoplewhotravel.com

Découvrir la méthode agile fut pour moi une révélation !

Vous allez trouver mon titre surprenant: découvrir la méthode Agile fut pour moi une révélation !
Je me décris comme un chef de projet multi-projetS : Projets pro, perso et associatif plutôt traditionnelle 
Vous pouvez retrouver cela dans mon interview à jeudi au féminin 

La méthode agile est plutôt une philosophie agile que nous utilisons tous, Comme Monsieur Jourdain faisait de la prose sans le savoir...
Je retiendrai ici  plutôt la souplesse et l’apprentissage.  La méthode agile permet de se tromper et comme on travaille de façon incrémentale d’apprendre de ses erreurs. Elle prône l’esprit d’équipe plus important que l’individu. 
Quand il y a un problème, on ne cherche pas quel est le coupable mais comment s’en sortir comment capitaliser.
 Cette méthode apporte un vrai changement par rapport à la méthode de cycle en V.
La relation client / fournisseur ne peut plus être la même. On doit remplacer le forfait bien bordé juridiquement par une relation win / win.  Cela entraîne un changement  de conduite du projet qui concerne toute l’équipe fournisseur et toute l’équipe client. 
Êtes-vous prêts à changer ? A apporter un peu plus de souplesse dans vos projets ? Un peu plus de communication ?
Soyons agiles !
A jeudi prochain 
Christine

Réalisation du blog en mode agile

Ce blog se veut être agile, il est constiué  d’un back log d’un stock d’articles plus ou moins défini.

Certains articles sont déjà écrits, d’autres sont au stade d’idées à développer.

La durée du sprint est d’une semaine , la publication se fait le jeudi en référence au réseau féminin : jeudi au féminin auquel j’appartiens

Comme dans un sprint, la régularité de parution est importante, elle permet à l’internaute d’avoir des points de repères temporels. Dans un projet  agile, la durée  d’un sprint est courte et défini et permet de produire un élément indépendant, testable et ayant une valeur busines. 

Le format de l’article de mon blog est  court 250 mots et une image adapté à l’internaute zappeur.

Le sujet de la semaine peut être puisé dans le stock ou inspiré par un évènement de la semaine.

Le contenu d’un sprint est décidé lors de réunion appelé planning poker. Lors de ce meeting ; l’équipe choisi quels sont les users stories qui seront produites lors de ce sprint. 

Les articles peuvent être planifiés à l’avance permettant une  meilleure organisation  grâce aux fonctions du blog. 

La diffusion est sur les réseaux sociaux facebook, twitter, linkedin permet  de toucher un maximum de personnes

Partagez et soyons agiles!

*********************************************