Étiquette : backlog

SCRUM DISTRIBUE : SCRUM avec une équipe OFFSHORE

Publié dans A la une, Agilité, ScrumTagué , , , , , , Laisser un commentaire

Une équipe SCRUM peut être renforcée par du personnel local ou distant.

S’agissant du renfort par une équipe distante, il s’agit bien de l’appel à des équipes de consultants OFFSHORE qui travailleront depuis leur pays.
S’agissant de renfort local, il s’agit bien de l’appel à des consultants locaux qui interviendront sur site.

Qu’ils soient locaux ou distants, ces nouveaux membres devront s’intégrer en tant que membre à part entière de l’équipe, car ils travailleront sur les mêmes engagements (exprimés lors de l’estimation) vis à vis du même SPRINT BACKLOG au sein de la même équipe SCRUM.

Le renforcement par une partie d’équipe distante devra se faire dans le respect de la méthode SCRUM ; il ne s’agit en aucun d’un contrat au forfait OFFSHORE

  • L’engagement des membres de l’équipe distante est individuel et exprimé lors de la réunion d’estimation
  • La taille de l’équipe renforcée doit rester raisonnable et compatible avec la méthodologie SCRUM
  • La responsabilité de la réalisation incombe à l’équipe locale et distante dans son ensemble

Dans ce cas de SCRUM DISTRIBUE, les artefacts agiles habituellement déjà incontournables ne peuvent être ignorés  :

  • intégration continue + testing d’acceptance continu
  • documentation partagée (wiki + documentation auto-générée)
  • renforts de l’XP : revue de code, pair programming

Ils sont utilisés de manière appuyée dans une optique de renforcement d’équipe SCRUM :

Objectifs Artefacts pour des renforts locaux Artefacts pour des renforts distants (type NEAR-SHORE ou OFF-SHORE)
Entrer au plus vite dans le projet Welcome pack sur le WIKI
Stories « d’apprentissage »		 Welcome pack sur le WIKI
Pair programming (entre personnes du site distant)
Stories « d’apprentissage »
Etre efficace Revues de code didactiques
Pack de bonnes pratiques sur le WIKI		 Outil SCRUM, intégration continue et source code (SVN/GIT) via VPN
Revue de code croisée (local – distant) réalisée en discussion video (partage d’écran + audio)
Faire partie de la même équipe Favoriser la prise de Stories difficiles avec du Pair programming (ancien/nouveau)
Conversation d’équipe (SKYPE/GTALK)		 Meetings SCRUM (daily, estimation, demo et retrospective) via des APPELS VIDEO(mur d’image)
Conversation d’équipe (SKYPE/GTALK)
Contacts 1 to 1 via des APPELS VIDEO OU AUDIO

 

L’outillage est relativement simple :

 

Objectif Outil Outillage
Communication d’équipe mur d’image pc + webcam + grand écran + skype (visualisation de l’interlocuteur et/ou partage d’écran)
Communication personnelle postes communicant 1 casque-micro par poste + skype ; webcam optionnelle mais recommandée
Collaborer dans l’agilité un outil SCRUM NUMERIQUE JIRA+GREENHOPPER ou TRAC+AGILO
Partager VPN pour accès aux outils

 

D’un point de vue SCRUM la mise en oeuvre avec l’équipe distante est la suivante :

Scrum meeting Modalité Difficulté
DAILY STANDUP Réunion d’équipe debout face au mur video ; équipe locale face à l’équipe distante ;  la vidéo montre les équipes dans leurs ensembles ; le déroulé est le même que dans la ‘normalité’ ; chacun parle à son tour Réunion facile à mettre en place
ESTIMATION Réunion d’équipe assis face au mur video ; équipe locale face à l’équipe distante ; la vidéo montre les équipes dans leurs ensembles ; le déroulé est le même que dans la ‘normalité’ ; le PO présente son Product Backlog, l’équipe pose ses questions, l’équipe procède à la création du SPRINT BACKLOG et estime les STORY Attention à la difficulté de la communication, cela peut créer de la frustation et du non engagement
DEMO Réunion d’équipe assis face au mur vidéo ; équipe locale face à l’équipe distante ; la vidéo montre prioritairement le produit et si possible la video de retour des équipes distantes ; la demo peut être réalisée localement ou de manière distante Attention à la difficulté de communication et à l’inaction du côté ‘auditeur’ ; le mieux est de partager la réalisation de la demo
RETROSPECTIVE Réunion d’équipe assis face au mur vidéo ; équipe locale face à l’équipe distante De par sa nature ouverte, réunion facile à mettre en oeuvre ; attention au rôle du SCRUM MASTER, il doit animer et orienter cette réunion, ce n’est pas évident avec une partie de l’équipe distante

 

Les difficultés peuvent être réelles :

Difficulté Source Résolution
Communications altérées/hachées Internet mondial Changement d’outil ?
Difficulté à synchroniser l’équipe Décallage horaire et organisation des journées Planning très précis, respect des horaires
Problèmes ‘culturel’ Cultures très éloignées (Europe/Russie/Inde/Chine) Intégrer la différence culturelle, respecter les us et coutumes
Distance professionnelle des interlocuteurs Distance géographique Localiser l’équipe distante pendant 2 semaines à 1 mois ; ‘échanger’ des membres :  ‘cross-pollination’ 

 

Certaines situations de blocage peuvent émerger au sein d’une équipe distante :

Constat Possible raison
Absence d’engagement Défaut de communication ? Défaut de mise à contribution ?
Faible ‘productivité’ Sensation de contractualisation ? Défaut de mise à contribution ?
Perte de conficance, frustration Défaut de communication ? Sensation de mise à l’écart ? Absence d’écoute et de partage ?

De tout ces blocages émergeront une perte de vélocité, une perte de qualité, ou un échec.  La résolution de ces micro-crises passe toujours par l’écoute, le dialogue et l’action dans le sacro-saint cadre l’amélioration continue proposé par SCRUM.

 

Taille d’équipe :

S’agissant de la taille idéale d’équipe distribuée, je n’ai jamais rien vu d’écrit à ce sujet.
De ce que j’ai pratiqué je dirais qu’un subtil 2/3 sur site + 1/3 distant fonctionne bien et qu’il ne faut pas franchir le cap symbolique de la moitié d’équipe distante

 

Localisatoin du SCRUM MASTER et du PRODUCT OWNER

Si le PRODUCT OWNER doit obligatoirement être sur-site, il n’en va pas forcement de même pour le SCRUM MASTER. Il est évidemment indéniablement efficace d’avoir un SCRUM MASTER sur site, mais c’est aussi fédérateur de proposer le SCRUM MASTERSHIP de temps en temps à la partie d’équipe distante.

Pour ce qui est des intervenants en spécialité au sein de l’équipe SCRUM (intégrateur, testeur, graphiste), rien ne s’oppose à ce qu’ils soient localisés dans la partie d’équipe distante, les résultats peuvent être très convaincants.

 

SOURCE :

Expérience personnelle à COACHCLUB (SCRUM DISTRIBUE avec l’INDE)
Corpus de cours Certified SCRUM MASTER

Patterns et anti-patterns agiles

Publié dans A la une, Agilité, ScrumTagué , , , , , , , , Laisser un commentaire

Loin de vouloir faire du manichéisme, voici une petite réflexion informelle et personnelle de ce qui me semble être de l’ordre du pattern et de l’anti-pattern dans la démarche de projet logiciel agile en général et avec Scrum en particulier.

On peut considérer deux types d’entreprise et de processus agiles :
– l’entreprise semi-agile : la demande et le produit ne sont pas gérés de manière agiles, ce n’est seulement qu’à la frontière avec la technique que l’agilité démarre.
– l’entreprise agile : tout les processus de création de valeur par l’entreprise sont agiles, de la réflexion à la réalisation

A ces deux types d’entreprises correspondent deux types d’exigence en terme de pratiques et processus.
L’ignorance des pattern agiles importants, ou l’emploi trop appuyé d’anti-pattern agiles,  doit plutôt être vu comme une incitation à :
– envisager la nécessité d’un travail autour de l’application de la méthodologie (travail dans le sens de…)
– à contrario envisager l’emploi d’une autre méthodologie agile (XP, concepts lean etc) si la résistance au changement est trop importante

Dans tout les cas, ne pas oublier que :
– les méthodes agiles ne font qu’agréger des pratiques ‘du bon sens’ issues de l’expérience
– c’est bien la méthode qui est au service de l’homme et pas l’inverse ; donc de facto, constituez votre trousse à outil agile et votre ensemble de règles basées sur les méthodes agiles

Priorité selon le manifeste agile Patterns (processus ou procédés consolidateurs) Anti-pattern typique (processus ou procédés contrariants)

Pattern nécessaire à l’entreprise agile

Pattern nécessaire à l’entreprise semi-agile
… aux personnes et aux interactions (plutôt qu’à des processus ou des outils) Echanges oraux mais consolidés par une trace écrite Echanges uniquement par email

X
réunions quotidiennes (daily) TTM imposée, milestones rigides 

X

X (daily scrum pour la partie agile)
cycle court avec estimation réunion d’avancement – point d’étapes réguliers

X

X (calage réunions vis vis des sprint)
planning poker – demo – retrospective kick-off + tunnnel + relase finale

X

X
Tableau public – scrum board Feuille excel gérée par un CDP

X

X (les artefacts non agiles sont consolidés vis à vis du product backlog et du sprint backlog)
… à la collaboration avec le client (plutôt qu’à la négociation contractuelle) Epic User story (résumé) Roadmap

X
Découpage des travaux en tâches (User Story) Spécifications fonctionnelles, use-case

X

X
(découpage des specs en story)
Cycle agile : itératif, incrémental et adaptatif Lotissements fonctionnels fermés, spécifications fonctionnelles, use-case

X
Retrospective, feedback Recette finale, pv de livraison, audit

X

X

(réunions agiles pour la partie agile)
Transition vers l’agilité, pioche de pratiques agiles au cas par cas (dans XP, SCRUM and co) Process figé

X
… à la production de fonction (pas à la documentation par exemple) Acceptance test, demo, iteration Recette fonctionnelle

X

  X
(pour la partie agile)
Délivrable potentiel à l’issu d’une itération timeboxée (sprint scrum par exemple) Définition/Négociation de Milestone

X

X
(1 milestone par x sprint)
Engagement sur les tâches sur un délai court (timebox) Engagement sur les dates et pas les tâches

X

X (si impossible envisager waterfall avec XP et pas SCRUM)
… à l’adaptabilité et aux changements (plutôt qu’à la poursuite des plans originaux) pair review, demo (product – dev) retours au spec

X

  X
(démo occasionnelle)
backlog liste des specifications priorisées

X

X
integration continue recette d’integration 

X

X (avec recette d’intégration si nécessaire)
x+1e sprint (intervalle de confiance) vsr (vérif. service régulier)

X

X
epic (user story allant être détaillée) lot fonctionnel/technique

X
test (acceptance, sanity) durant l’itération, tests unitaires recette d’intégration, sanity check à chaque milestone

X

Biblio :
http://www.entreprise-agile.com/HistoAgile.pdf
http://www.mountaingoatsoftware.com/system/presentation/file/123/Cohn-Agile-and-Deadly-Sins-of-Project-Management.pdf
http://www.agileopencalifornia.com/wiki/index.php?title=Semi_Agile_Projects
http://productmanagementjournal.blogspot.com/2009/08/agile-thinking.html
http://www.agilemodeling.com/essays/enterpriseModelingAntiPatterns.htm
Transition vers l’agilité – Livre blanc – 2e édition 2011 – Valtech

Product owner et Proxy Product Owner

Publié dans A la une, Agilité, ScrumTagué , , , , , , Laisser un commentaire

Si vous avez adopté la méthodologie SCRUM, les réunions, les artefacts et les intervenants de la méthodologie SCRUM n’ont plus de secrets pour vous. Si le positionnement du Scrum Master fait l’unanimité, celui du Product Owner fait souvent l’objet de nombreux questionnements alors qu’il s’agit d’un role essentiel dans la méthodologie SCRUM.

Le rôle de Product Owner se définit ainsi :
« Le Product Owner est le représentant des clients et utilisateurs. C’est lui qui définit l’ordre dans lequel les fonctionnalités seront développées et qui prend les décisions importantes concernant l’orientation du projet. Le terme directeur n’est d’ailleurs pas à prendre au sens hiérarchique du terme, mais dans le sens de l’orientation. » (source Wikipedia)

Il est cependant utile de compléter cette définition du Product Owner :
– il est le dépositaire mandaté dans la vision produit du ou des produits qui lui incombent
– il construit le produit en conservant une vision mesurée du retour sur investissement (ROI) de ces demandes
– il détermine les objectifs stratégiques de chaque itération et planifie ainsi l’évolution du produit

Usuellement le Product Owner gère :
– la préparation du backlog et dans une moindre mesure la vision d’entreprise du ou des produits
– la roadmap et dans une moindre mesure, par corrélation la plannification des releases
– sa collaboration avec les ‘métiers’ et l’accomplissement des évolutions ou créations
– sa collaboration avec l’équipe et le scrum master

Hors dans de nombreuses entreprises,
– les métiers sont complets, distincts et hétérogènes
– les métiers concentrent le pouvoir de décision et ont leur propre approche ROIste et ne souhaitent pas déléguer ce ‘pouvoir’
– les organisations et répartition des métiers se font en silos
– les cycles de décision et de réalisation sont réellement lents, ce qui créée concurrence entre les besoins
– les demandeurs ne souhaitent pas s’impliquer dans la réalisation
– il n’est évidemment pas possible d’avoir autant de Product Owner que de silos/produits/métiers (quid des projets transverses dans ce cas).

Ces anti-patterns agiles et cette réalité ont donc favorisé l’apparition d’un rôle, un peu plus subtil, peu spécifié, remplaçant le Product Owner ; il s’agit du Product Owner Proxy

Sur des projets transverses il est :
– l’interlocuteur unique des responsables produits
– l’interlocuteur principal (ou unique, à vous de voir) des membres de l’équipe scrum
– le gestionnaire des priorités
– la personne en charge de l’organisation des releases pluri-métiers
– le dépositaire d’une expertise métier spécifique à l’ensemble pluri-disciplinaire que forme le projet global d’entreprise (qui n’est pas l’expertise métier de tout les responsables produits ou métiers)

Il n’est pas :
– le dépositaire ‘produit’ et n’est mandaté que par le responsable produit
– acteur sur le ROI ; il est d’avantage un analyste
– le référent en terme de vision sur le produit

De l’aveu même de Ken Schwaber, Scrum ne définit pas comment utiliser le product backlog et pas plus ce que doit faire le product owner. Donc après c’est à vous de voir comment limiter ou augmenter ce rôle.

Qui peut être ce product owner ?
– un développeur senior (pour peu qu’il se soit aussi spécialisé dans la gestion de projet)
– un business analyst ou un chef de projet (pour peu qu’il soit réellement sensibilisé à développement et aux contraintes techniques et qu’il ait une réelle empathie vis à vis des développeurs)
– dans une certaine mesure,un responsable produit, pour peu qu’il soit réellement accepté en tant que tel par les responsables produits et les membres de l’équipe SCRUM

Comment consolider ce rôle de product owner proxy ?
Il faut impérativement outiller et enrichir les attributions de ce rôle clé en :
– outillant le rôle en process de gestion de de la demande
– organisant l’assistance de la part des responsable métiers ou produit dans le travail de tout les jours
– donnant des pleins pouvoirs dans la gestion et négociation de la priorisation (business value)

Les valeurs de ce product owner proxy doivent être :
– confiance totale des responsables produits
– confiance totale de l’équipe scrum
– autonomie et une capacité à prendre des décisions et à les faire accepter
– respect des besoins, respect des équipes, respect du travail réalisé

Pour le reste la base du métier, les artefacts, et les outils du Product Owner ne changent pas :
– le backlog
– la priorisation
– l’écriture des User Stories
– l’assistance aux différentes ‘cérémonies’ SCRUM

Sur des projets non transverses, le pattern du Proxy Product Owner est inutile.

En conclusion, demandeurs, responsables produits, directions, membre de l’équipe scrum, le Product Owner Proxy est votre meilleur allié. Certes, il est souvent issu de la technique informatique, mais l’aidez c’est vous aidez dans vos projets car il est le meilleur vecteur du bon accomplissement des travaux de la société car :
– il est autant sensible que les demandeurs aux objectifs business de la société
– il connait tout les besoins de la société et il est le meilleur allié pour faire progresser les projets des acteurs de la société
– il est un excellent filtre pour l’équipe SCRUM pour éliminer bruit et négocier en amont les fonctionnalités

Un peu de lecture :
http://kenschwaber.wordpress.com/2011/01/31/product-owners-not-proxies/
http://blogs.versionone.com/agile_management/2009/08/04/agile-product-owner-by-proxy/
http://agileworld.blogspot.com/2009/09/choosing-proxy-product-owner.html
http://www.leadingagile.com/2009/03/product-owner-by-proxy/
http://softwaredevelopmenttoday.blogspot.com/2008/04/proxy-product-owner-pattern-in-scrum.html
http://www.slideshare.net/xwarzee/le-product-owner-proxy-bertrand-dour
http://agileinthemix.com/fr/2010/02/illustration-dune-organisation-en-silo-leffet-dalton/
Corpus et notes de la formation Certified Scrum Master par Petra Skapa (Xebia)