Posted by jc-Qualitystreet on 3 mars 2012
Le métier de Manager évolue… et l’Agilité n’est pas étrangère à l’émergence de ce sentiment d’urgence poussant les managers à revoir leur rôle au sein des organisations.
Voici le quatrième volet consacré aux responsabilités du manager Agile
Créer un environnement organisationnel propice au succès et booster le changement…
- C’est favoriser la diversité et la proximité
- C’est communiquer la Vision de l’Entreprise et donner du sens au travail de chacun
- C’est adopter un style de management adapté,
- C’est simplifier les usages,
- C’est rechercher la performance au travers d’outils et de processus adaptés fondés sur l’amélioration continue et la chasse aux gaspillages
- C’est booster et anticiper les changements
Ambitieux tout cela… non ? et pourtant c’est ce qu’on attend de nos managers, et c’est encore plus vrai dans un contexte agile.,
Environnement Agile, Environnement propice au succès ?
Oui mais…. Oui parce que l’agilité propose des conditions favorables sources de bien être et de performance ; donc oui mais ce n’est pas suffisant et les efforts des managers sur leur environnement organisationnel doivent être permanents : vision, culture, changement, espaces de travail, processus, outils. Le boulot est énorme… et disons-le éphémère sans un soutien fort du Top management.
Culture d’entreprise? Culture Agile…
Là oui, définitivement oui!
Diversité et proximité sont des éléments majeurs de la culture d’entreprise intimement liés à l’agilité. Ce sont deux forces considérables que le manager agile doit pousser de manière inconditionnelle, y compris dans les grandes organisations, celles-là même qui ont la fâcheuse tendance d’éloigner les personnes plutôt que de les rapprocher.
Les méthodes agiles permettent d’assurer la proximité intra équipe, l’action du manager agile pour établir une relation de confiance permet de réduire la distance entre ses collaborateurs et lui-même. Plus largement, le manager agile peut désormais s’appuyer sur une approche Agile & Lean pour DÉCLOISONNER, sortir de la logique des silos en facilitant la collaboration entre des entités qui jusqu’alors communiquaient peu et peinaient à travailler efficacement ensemble…. Là encore entre opportunités et nécessités, l’agilité casse les cloisons et pousse à la collaboration dans toute l’organisation (Métiers, Dév,’Exploitation…) Des mouvements comme le LeanStartup ou devops vont dans ce sens : managers , profitez-en !
Culture d’entreprise et proximité se jouent aussi simplement au quotidien avec des gestes simples comme le “Face Game” mis en place chez Zappos. Pour se connecter au système, en plus des login/password, chaque employé Zappos a droit à une étape supplémentaire : la photo d’un autre employé s’affiche avec un petit quizz pour trouver le nom de celui-ci. Une fois trouvé, une courte bio de la personne s’affiche…Connaitre les gens, qui ils sont, ce qu’ils font, recréer le lien.. Tiens si on faisait ça chez nous… Valtech grandit mais garde l’agilité dans ses gènes, cultivons-là… Sebastian (@s_valtech), Lubomira (@ljubomira), Henri (@henrivaltech), si vous me lisez 
Favoriser la diversité en termes d’expériences, de savoirs, d’idées et de point de vue est le second enjeu du manager agile.
Googleplex: ouverture et interactions
A lui de se positionner en facilitateur de cette diversité, de devenir ce facilitateur d’innovation et de chercher les différences qui font la différence, et provoqueront les coups de chance pour le plus grand bonheur des personnes, de l’organisation et de se clients.
Soutenir la diversité n’est pas seulement un réflexe humaniste, c’est croire avant tout en une pensée constructiviste et adaptative conduisant au succès.
Pour beaucoup de managers, cela passera par la mise en place d’espaces d’échanges, pas seulement virtuels mais physiques, pour lesquels le management visuel sera d’une aide précieuse…
“habiller vos murs”
Googleplex: Diversité, ouverture..
Cela sera aussi par tous les moyens faciliter les moyens d’échanges et d’interaction (Zappos, Google) en multipliant les points de rencontre informels ou événementiels (type Open Space Technology).
Tout était prêt !!!
Open Space Technology... pas mal de sujets
Partager encore et toujours la Vison d’Entreprise
La vison; ça se joue à deux niveaux, et dans les deux cas, cela s’avère essentielle .
Niveau produit, la Vision est portée par un Product Owner. Elle donne une direction moyen /long terme, fixe le cap et donne du sens dans les tâches quotidiennes du développeur par exemple.
La Vision du Produit en mode Agile...
Au niveau de l’Entreprise, la Vision permet quant à elle de donner du sens au Travail, d’apprécier sa boite, son environnement de travail et de se sentir bien dans son job. Quand on ne croit pas à son entreprise, qu’elle ne vous inspire pas, ça ne va jamais très loin… Au management de jouer sur ce gros levier de motivation, source de performance et de bien être…
A quelle entreprise cette vision appartient-elle?
Et le changement dans tout cela?
La manager agile n’est plus simplement un acteur (parmi tant d’autres) du changement. Cette nouvelle posture managériale, Agile & Lean, l’amène à en devenir le premier supporter, et plus encore, à le booster voire l’anticiper.
A la fois Actif, Réactif et Pro Actif … et sur les chantiers de transformation Agile & Lean de l’organisation il ya de quoi faire.
Le Manager Agile: Un chef d'orchestre
Au quotidien, c’est encourager les nouvelles idées, challenger et défendre, informer, expliquer dans des RDV collectifs ou individuels (One on One).
C’est promouvoir, évangéliser, convaincre les sceptiques, communiquer en interne, en externe, flairer les tendances (Laurent, sur ces points c’est bien toi le meilleur!) ; vaste programme certes mais un travail qui à terme porte ses fruits. Certains managers agiles l’ont donc compris et commencent à se faire connaître et à partager leurs expériences.
Vers une entreprise apprenante…
Le manager est l’élément clé du dispositif d’apprentissage et d’amélioration continus, fondement du Lean Management :
- Hansei réflexion continue
- Kaisen l’amélioration continue
Concrètement pour le manager, il va s’agir de:
- favoriser le partage de connaissance,
- donner du temps pour innover (comme chez Google, WL Gore, Altassian…)
- encourager toutes les formes d’apprentissage,
- récompenser ceux qui pointent les axes d’amélioration ou découvrent les problèmes (on apprend par la pratique (et donc) on apprend aussi de ses erreurs) ,
- exploiter le résultat des différentes rétrospectives agiles (s’il n’y participe pas),
- capitaliser et standardiser
C’est sur la base de ces éléments que le manager agile sera en mesure de simplifier les usages, définir les processus adéquates et choisir les outils les plus appropriés pour servir au plus juste l’activité des personnes… Les managers peuvent ici s’appuyer sur l”agilité est une vraie force : développement itératif et feedback sont des outils clés dans cette quête acharnée de la connaissance!
Un style de management adapté à des configurations nécessairement multiples
Parce que l’Homme au travail
… a sa propre personnalité,
… qu’il s’intègre dans une Equipe,
… elle-même située dans une Organisation (qui a sa propre culture d’Entreprise)
… au sein d’une Culture Nationale,
le mode de management ne peut être que situationnel et non pas unique ! (Ok c’est mon côté psy qui ressort ).
Et c’est bien là tout la difficulté mais aussi l’art du manager dont vous êtes peut être familier: AJUSTER son style de management selon la personne qu’il a en face de lui, selon la situation et le contexte… c’est à dire de la somme de tous les éléments cités précédemment.
Difficile certes mais pas insurmontable ! Dans tous les cas, apprendre à connaître la personne et établir une véritable relation de confiance restent les clés pour adapter son style de management. Le style Manager-Coach, “celui qui va faire progresser les autres“, a apparemment le vent en poupe (y compris chez Google avec le programme Oxygen). Je dirais, à juste titre , mais sur le terrain, est-il le plus utilisé ? Nous en sommes loin, malheureusement !
Maintenant, doit-il être utilisé partout et en toutes circonstances. Est-t-il la réponse miracle, universelle ? Là encore, non! car d’autres styles de management (type meneur, démocratique, partenaire voire directif) peuvent s’avérer tout à fait approprié selon les cas (et le triptyque: personne - situation - contexte). Et puis, tout est ensuite une question de mesure…
Au final, voilà un 4 eme volet bien dense, aussi dense que cette activité est cruciale pour le Manager, ses collaborateurs et son Organisation!
Posted by jc-Qualitystreet on 27 février 2012
Un titre qui peut vous sembler exagéré… et pourtant ce RDV en cours de sprint est tout simplement crucial pour l’Equipe qui se veut Agile !
Mon message est clair :
Sans Backlog Refinement, vous n’atteindrez pas cette agilité bien huilée que vous recherchez et ces résultats que vous attendez
et simple :
Ceux qui le négligent, ceux qui l’oublient le paient inévitablement ; ceux qui l’adoptent et le réalisent dans de bonnes conditions en redemandent…
Une équipe performante à l'oeuvre
Le Backog Refinement est un workshop qui se déroule une à deux fois par sprint, souvent à mi-sprint. Comme son nom l’indique, ce workshop est centré sur le Backlog de produit (c’est à dire la « liste de tous les éléments sources de valeur et nécessaires à l’équipe pour réaliser un produit »). Alors affinage, nettoyage, entretien, maintenance, ou en anglais « grooming », les mots varient mais j’avoue avoir une très nette préférence pour le terme Refinement, popularisé par Craig Larman.
Définitivement collaboratif, le Backlog Refinement doit impliquer tout le monde, du Product Owner (soutenu ou pas par un expert UX ou un Business Analyst), au ScrumMaster en passant par TOUS LES MEMBRES DE l’EQUIPE. Durant mes formations et mon coaching, je présente le Backlog refinement comme un must, le 5 eme RDV incontournable, qui vient s’ajouter aux 4 cérémoniaux Scrum décrits par Sutherland et Schwaber, inventeurs de la méthode Agile la plus populaire… des auteurs qui persistent à limiter la visibilité de cette activité essentielle de préparation tout en reconnaissant paradoxalement son existence!
“Product backlog grooming is the act of adding detail, estimates, and order to items in the Product Backlog. This is an ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items. During Product Backlog grooming, items are reviewed and revised. However, they can be updated at any time by the Product Owner or at the Product Owner’s discretion.
Grooming is a part-time activity during a Sprint between the Product Owner and the Development Team. Often the Development Team has the domain knowledge to perform grooming itself. How and when grooming is done is decided by the Scrum Team. Grooming usually consumes no more than 10% of the capacity of the Development Team.” Scrum Guide July 2011 p13
Et je persiste à penser que “légitimer” son existence en tant que cérémonial Scrum ferait gagner du temps et de l’énergie à pas mal d’Equipes, car même si le format et la durée peuvent varier (3 à 4 heures à mi sprint en une fois ou plus courts en deux temps une fois par semaine), les objectifs, l’agenda, éléments d’entrée / sortie sont clairs, pour une valeur évidente.
Agenda- Facilitation Backlog Refinement
Vous l’aurez compris, le Backlog Refinement est un RDV avant tout collectif qui dans les contextes webs et digitaux devient un moment d’expression et de facilitation privilégié pour les experts UX où il s’agira en priorité de décortiquer, d’explorer, de modéliser collectivement le contenu potentiel du sprint qui va démarrer quelques jours plus tard.
Ni trop tôt, ni trop tard dans le Sprint…
Tenir ce Refinement à mi-sprint permet au spécialiste UX, au product Owner ou même à l’équipe de de disposer de suffisamment de temps pour pouvoir le cas échéant peaufiner son besoin, faire un travail de spécifications supplémentaire, explorer une problématique technique ou confirmer des hypothèses auprès des utilisateurs finaux.
Le début-milieu de la seconde semaine sur un sprint de 3 semaine ou la fin de la première semaine pour un sprint de 2 semaines sont des moments propices pour organiser le Backlog Refinement. Le faire le dernier jour du sprint ne présente donc que peu d’intérêt.
Ce workshop peut à son tour donner lieu à des mini workshops spécifications côté Product Owner et/ou Equipe.
Focus sur le sprint n+1… mais pas seulement
J’attends que les équipes se focalisent sur le sprint qui arrive et qu’elles soient en mesure de répondre à cette question :
« Serons-nous Prêts à développer les user stories se trouvant en haut de la pile, ces user stories que nous sommes susceptibles d’embarquer au Sprint suivant ? ».
Ce questionnement implique une activité de modélisation ainsi qu’un travail portant à la fois sur les conditions de satisfaction et sur des exemples (lien avec l’approche ATDD) illustrant les fonctionnalités à développer. Il implique aussi le découpage de certaines users stories trop grosses être développées dans un sprint.
Néanmoins, le focus sur la préparation du sprint suivant n’est pas le seul objectif du Refinement. C’est aussi le moment idéal pour discuter des changements sur le backlog (rappelez-vous mon backlog est DEEP, évolutif, des items peuvent disparaitre, d’autres peuvent émerger, les priorités changent inévitablement.)
Il aussi souhaitable d’anticiper les risques ou impacts de certains éléments prévus à moyen terme dans les sprints n+2, n+3… besoins de spécialistes, impact techniques, ergonomiques, en terme d’activités de déploiement, de tests ou de support…
Le Backlog refinement: que des bénéfices si on joue le jeu!
Ce workshop collaboratif:
- Donne du contexte et des élements de conversation aux User Stories, pourquoi pas en se basant sur la checklist User Story pour s’assurer qu’on n’oublie rien
- Assure une certaine fluidité et de la sérénité dans le déroulement des sprints
- Illustre et précise les exemples et conditions de satisfaction, qui seront confirmées au moment du Sprint Planning
- Offre un pur moment d’intense collaboration: interactif, visuel, concret et source de feedback…
Bref, le Backlog Refinement, adoptez le sans modération !
Posted by jc-Qualitystreet on 21 février 2012
C’est u’un des premiers outils du toolkit du facilitateur et du coach agile.
Le check-in est si simple à utiliser qu’il en est souvent ignoré… malheureusement!
« Alors, comment vous sentez-vous aujourd’hui ? »
Vous êtes amené à faciliter des workshops, des rétrospectives ou cérémoniaux Agiles alors usez, et abusez du Chek-in. Que de bénéfices en effet pour ce petit tour de table ! Jugez-en plutôt :
- Il vous permet de briser la glace,
- Il fait la transition entre la vie hors-meeting et le workshop qui démarre: remarquable en ouverture de workshop
- Il va libérer la parole de tous.
- Il permet à chacun de partager l’état dans lequel il se trouve: c’est une opportunité de savoir ce que ressentent les autres et potentiellement d’adapter son comportement en conséquence
- Il contribue à terme à créer une vraie cohésion de groupe
Comment ça marche ?
Très simple mais voici quelques petites règles que j’aime bien suivre…
- Demander à un volontaire de commencer
- Se joue à tour de rôle
- Pas d’interruption durant le check-in de quelqu’un (après on peut commenter évidemment…)
- Orienté boulot ou pas: parlez de tout ce qui vous affecte à l’instant T
Côté facilitateur, il s’agit de rappeler ces quelques règles, lancer le check-in puis une fois que chaque personne a parlé, et si c’est possible, faire une petite phrase de récap (ex : « on dirait que vous allez tous bien c’est cool » ; « un peu de tension suite à la démo, on dirait… », « fin de sprint difficile semble-t-il »…)…
Le check-in moi j’aime bien!
Posted by jc-Qualitystreet on 4 février 2012
Activité#4 du praticien AgileUX…
Le praticien AgileUX va initier puis construire l’architecture de l’information de manière collaborative
L’architecture de l’information c’est l’organisation du contenu et des fonctionnalités d’un point de vue cognitif et graphique pour répondre aux besoins et attentes des utilisateurs finaux.
Architecture de l'information : un élément d'UX
L’architecture de l’information est une activité incontournable de toute projet IT ; outre le fait de donner du sens, dans un contexte de développement Agile, cette activité va proposer la fameuse Big Picture, tant attendue par mal d’intervenants, et va rassurer à la fois les Equipes IT et le Business. Elle facilitera ensuite le travail de tests.
Arborescence
La Big Picture : High level et structurante
Entrer dans une dynamique agile signifie l’ABANDON de spécifications détaillées, travaillées pendant des mois et figées au démarrage du projet, AU PROFIT d‘un travail de spécification plus léger au départ, mais aussi progressif et surtout continu (notamment au travers des workshops User stories et du travail portant sur le Backlog de produit).
Concept Model par Daniel M. Brown
Néanmoins, et je dirais encore plus sur un projet SCRUM, même si ce travail de spécification ergonomique peut sembler plus léger au départ, les premiers éléments d’architecture d’informations sont à maîtriser dés les premiers sprints du projet (sur la base d’informations potentiellement recueillies au préalable, tri de cartes, Kano…).
Modèle de Kano
Il s’agit pour le praticien AgileUX d’aller à l’essentiel, de réflechir en terme de valeur pour sa prore activité et de se mettre au service à la fois du Product Owner et de l’Equipe.
La TO DO List du praticien AgileUX pour l’architecture de l’information
- Clarifier et catégoriser les informations
- Soutenir le PO dans son effort de priorisation des fonctionnalités et des contenus
- Initier puis approfondir de manière collaborative une première structure d’informations efficace
- Déterminer les système d’information le plus approprié
- Tester puis affiner ces éléments structurants
Système de navigation - Pages intèrieures
