Ou comment gérer agilement une équipe transverse

J’avais déjà posté par le passé une description de ma mission actuelle, et où j’expliquais les rôles d’une équipe transverse, et surtout la difficulté d’y appliquer un outil de type scrum.

Pour rappel, l’équipe est multi-tâches, multi-projets, avec une assez forte activité de maintenance, d’assistance et de suivi.

Mon client ayant gagné en grade et en responsabilités, s’est déchargé sur moi de son rôle de scrummaster. J’ai essayé tant bien que mal d’appliquer un scrum plus rigoureux, plus proche de la théorie telle que définie ici.

Les limites et écueils sont apparus assez vite :

• Le product owner n’est pas identifié.
• Des demandes d’assistances, nombreuses et ultra-prioritaires par rapport au reste.
• Cette indisponibilité, estimée à 50% du temps de travail de toute l’équipe, est très variable d’une itération à une autre, et empêche les calculs de vélocité et de prédictibilité.
• Ces demandes d’assistance, si on les prenait en compte pour l’établissement du burndown chart, on obtiendrait quelque chose d’assez « sinusoidal », puisque les taches “d’urgence” non planifiées s’ajoutent à ce qui était planifié.

Last but not least, scrum est un outil demandant un minimum de rigueur (attention, j’ai dit rigueur, pas rigidité, ça reste une méthode agile !) Les participants doivent mettre un peu de bonne volonté pour que cela fonctionne, et il reste (et restera) toujours des « agilosceptiques ».

Scrum, tout n’est pas à jeter :

• Le daily-meeting du matin, ça doit rester !
• La rétrospective, ça doit rester !
• Les démonstrations, s’il y a lieu, ça doit rester !
• Un graphe, ou quoi que ce soit qui reflète le travail de l’équipe, doit rester !
• Le couplage avec un outil de workflow (type Redmine) pour historier, doit rester !

A partir de cette constatation, il est évident qu’une approche plus « adaptative » et moins « normative » que Scrum doit répondre aux besoins de l’équipe.

C’est tout naturellement qu’une migration vers KanBan s’est imposée.

Kanban : c’est quoi ?

Un bon lien valant mieux qu’un long discours, Voici là dedans tout ce qu’il faut savoir sur kanban.

En synthétisant ce qui nous intéresse :

• Kanban signifie en japonais « étiquette ».
• Le cycle itératif devient optionnel (!).
• L’efficacité d’une équipe se mesure en « temps de cycle » .
• Le « kanban board » est plus profond et plus élaboré qu’un scrumboard.
• Le board n’est plus réinitialisé, cela devient un tableau perpétuel.
• Kanban conseille très fortement la limitation du WIP (pour work in progress), c’est-à-dire la limitation de tickets dans une colonne donnée.

Kanban reste, et c’est cela le principal, un outil empirique : à l’équipe de l’adapter à son contexte et de se l’approprier.

Comment j’ai procédé.

Toutes les décisions ont été prises conjointement avec l’équipe, il est nécessaire qu’une adhésion, sinon une absence de réticence des participants existe pour rendre l’outil opérationnel

Les étiquettes

Sur les post-its doivent figurer :

• Un résumé de la tache à faire
• Une estimation (en heures) de la durée de résolution. Cela est du à un couplage avec un outil de workflow (redmine) imposé par le client
• Le thème ou le projet auquel la tache se réfère
• La priorité
• La ou les personnes assignées

Le board

Pour faire un bon KanBan board, il faut :

• Un mur large.
• Du scotch de couleur (on en trouve aux stands « tout à un euro » des marchés).
• Des ciseaux.
• Des gros feutres de couleurs
• Des post-its de couleurs.
• Des gommettes.

• Premièrement, définir les colonnes.
  Pour notre activité, nous avons gardé le triptyque « todo, doing, done », auquel nous avons rajouté « pursue » (accompagnement).
  Puis nous avons subdivisé chaque colonne :
  • Todo : c’est les tâches à faire
    • Selected backlog : taches du backlog (notez la suppression du complément « product ») à exécuter dans les prochains temps
    • Urgently : taches prioritaires, à finaliser d’urgence, au moins pour le sprint en cours
  • Doing : tâches en cours
    • In progress : développées actuellement
    • Peer review : revue par les pairs, avec retour critique, que nous essayons de systématiser
    • Test : taches testées fonctionnellement après développement
    • Blocked : nécessite l’intervention d’une équipe externe
  • Pursue : tâches “d’accompagnement”
    • Follow up : suivi d’une tache (par exemple le monitoring lors de la montée en charge d’un serveur)
    • Acceptance test : Lorsqu’il est demandée à une équipe de faire une recette.
  • Done : tâches finies
    • Closed : tache commitée, close.
    • Delivered : tache livrée et utilisée.
• Deuxièmement, définir les limites du WIP

Nous avons matérialisé cela par un scotch noir et large au bout de chaque colonne. Aucun post-it ne doit sortir de la zone délimitée.

• Troisièmement, élaborer les post-its.

La couleur des post-its définit le thème, le projet…
La gommette de couleur définit la priorité. L’intérêt est de pouvoir en changer lorsqu’une tâche devient plus urgente
Les autres informations sont simplement écrites dessus.

• Quatrièmement, expliquer et accompagner.

D’où l’intérêt d’engager l’équipe, de faire en sorte que l’équipe propose des évolutions / améliorations de manière collective.

En pratique cela donne ça :

Les cycles.

Nous avons gardé les anciens sprints de trois semaines, rythmés par les réunions de rétrospective et de démonstrations.
En ce qui concerne les planifications des taches, pour l’instant ce n’est pas encore très clair :

Doit-on alimenter la colonne « Todo » au fil de l’eau ? Quand recentrer les priorités ? Doit-on faire des réunions de planning de manière régulière ou des que le besoin s’en fait ressentir ?

Pour l’instant, ce qui a été retenu, ça serait l’alimentation au fil de l’eau, avec une réunion de planif en même temps que les autres, de sorte qu’on garde le burndown chart. On garde par la même un des intérêts qu’offrait scrum, c’est-à-dire un but à atteindre, une motivation engendrée par le fait qu’au bout du sprint, le graphe doit être à zéro.

Et maintenant ?

Les réunions de rétrospective à venir affineront et adapteront plus au contexte de l’équipe l’outil. Les tailles des zones WIP changeront probablement, des colonnes vont peut-être être supprimées, d’autres créées. L’équipe saura sûrement comment faire des planifications plus efficaces… Je ne manquerai pas de faire un retour d’ici quelques itérations.

Mise à jour 1

Entre le moment où j’ai écrit ce post et le moment où il a été publié, une première rétrospective s’est passée.

Voici la liste des ajustements faits par l’équipe :

Sur le tableau :
Les colonnes « urgently », « test »  et  « acceptance test » disparaissent. Avant de crier au scandale, il faut noter que :
« acceptance test » était la colonne signifiant qu’une recette était à faire par l’équipe. Cela arrive au final assez rarement, et cela s’apparente beaucoup à du suivi.
« test  » devient caduque du fait qu’on pratique (tant bien que mal) la TDD, et qu’on essaie de systématiser les peer reviews.
« urgently » disparaît, la priorité des post-its peut se trouver sur les tickets

Sur les post-its :
On s’est très vite aperçus que trop de couleurs nuisent à la lisibilité. Si les thèmes des tickets restent définis par les couleurs de post-its, leur priorité n’est plus définie par la couleur des gommettes, mais par leur nombre.

Sur les planifications :
Les réunions de planification resteront et marqueront les début de sprints, à l’image de ce qui se fait en scrum. On essaiera de limiter la venue de tickets TODO au fil de l’eau, sans pour autant l’interdire.

Ce que cela donne :

A part cela, l’équipe a pour l’instant bien adhéré à l’outil.

Le mercredi 7 Décembre, Valtech accueillait dans ses locaux la ScrumNight du French Scrum User Group

Cette soirée était dédiée aux “Serious Games”, ces jeux sérieux qui nous permettent d’apprendre notre métier d’agiliste tout en nous amusant.

La soirée était composée de 2 séries de sessions avec jusqu’à 5 salles en parallèle. Les organisateurs nous avaient demandé de nous pré-inscrire pour les ateliers, afin de réguler le remplissage des salles. C’est la première fois que je vois ça, et j’ai trouvé ça pas mal. Ça m’a tranquillisé de ne pas avoir à décider sur le moment. J’ai appris que certaines personnes n’ont pas été bien prévenu et ont trouvé l’expérience moins agréable !

Première partie (19h00 -> 21h00)

Pour la première partie, j’ai du faire un choix difficile entre le Kanban Game et le Leadership des talents. J’aurais bien voulu participer au jeux de plateau sur kanban organisé par Dimitri Baeli et Guillaume Lours, mais j’ai préféré en fin de compte assister à la présentation de Ralph Hippolyte, Philippe Houssin et Patrice Petit.

Avant le démarrage, je suis allé voir la préparation du Kanban Game. Tout était en place pour animer deux parties en même temps, Guillaume Lours ayant réussi à se procurer deux sets identiques du jeux de plateau en version 1.0… Si vous participez à ce jeux, vous pouvez apprendre à faire fonctionner un kanban, à constater les engorgements et prendre les décisions de régulation qui conviennent. J’aurais bien voulu voir le système en action.

Ceci dit, je n’ai pas regretté d’avoir assisté à la présentation sur le leadership des talents. Excellente session sur le coaching, animé par trois coach, Ralph Hippolyte, coach sportif, Philippe Houssin, coach individuel et de group et Patrice Petit, coach Agile et CST.
J’ai noté deux idées en début de présentation :

Puis je me suis laissé prendre par la présentation…

Ce que j’en ai retenu :

J’ai beaucoup apprécié cette approche du coaching par le corps. Ralph nous a fait plusieurs démonstration où il identifiait les préférences psychologiques de quelques volontaires, par l’analyse de leur expression corporelle.
J’ai été touché par le témoinage de Philippe qui est venu au coaching après avoir fait un burnout.

Deuxième Partie (21h00 -> 22h00)

En deuxième partie, je suis allé assister à “Jouer pour transformer” animés par Laurent Sarrazin et Oana Juncu.
Par groupe de 8 personnes environ (4 groupes) nous avons joué à “Remember the Future”. Nous nous sommes imaginés collectivement être en décembre 2012 sur une planète entièrement convertie à l’agilité. Puis nous avons regardé quel avait été notre chemin pour en arriver là. La démarche est vraiment intéressante. J’ai été convaincu que le changement de perspective permet vraiment de découvrir des choses. Malgré tout, le résultat concrètement obtenu était un peu décevant. Difficile de former un groupe efficace aussi rapidement !

A partir du travail effectué, nous avons ensuite participé collectivement au jeu “Spot Yourself” inventé par les animateurs. Ce jeux permet de constituer rapidement des groupes d’actions dans un mode purement auto-organisé. Ce jeux est inspiré de la sociocratie. La suite de l’exercice que nous n’avons pas mis en œuvre aurait été d’élire un représentant du groupe par un exercice d’élection sans candidat.

22h15: Cocktail

Je suis ensuite resté à discuter autour du buffet jusqu’à plus de 23h. Puis, finalement, je suis rentré me coucher car cela était nettement plus raisonnable pour moi. Les plus résistants ont profité de la troisième mi-temps au bar.

Valtech lance le podcast “Fréquence Valtech” où nous parlerons de technique et d’agilité. Le rendez-vous se veut mensuel.

Dans ce 1er épisode, Grégory Paul interviewe Etienne Charignon et Eric Le Merdy au sujet de TDD.

Vous pouvez télécharger ce podcast au format ogg ou mp3 ou encore vous abonner via le flux rss dédié (itunes est capricieux et n’arrive pas à charger l’épisode, l’investigation est en cours pour résoudre ce problème).

N’hésitez pas à nous faire part de vos retours par email à l’adresse <podcast-at-valtech.fr> ou alors via les commentaires ci-dessous.

Le thème musical provient de podcastthemes.

Le 2^ème jour de l’Agile Testing Conference a commencé avec la keynote d’Esther Derby intitulée « People & Patterns ».

Selon Esther, l’une des erreurs communément répondues est de vouloir attribuer les problèmes “système” aux individus et les problèmes “individuels” aux systèmes.

Esther souligne qu’au sein d’une seule équipe, on peut trouver plusieurs groupes, plusieurs patterns et des structures pratiquement invisibles.

Esther explique par la suite, comment l’environnement Agile peut aider l’organisation à se rendre compte des patterns existants. Son modèle d’équipe Agile (pluridisciplinaire et partageant le même niveau d’information et le même rôle) rend visible les patterns de l’entreprise, ainsi ils pourront être identifiés, puis adressés.

Esther propose d’inverser la pyramide de Lee Tucker et de mettre au sommet la question « Pourquoi ? »

Voici quelques phrases d’Esther à méditer :

“In the business world you are paid to be decisive. It’s better to be certain and wrong than uncertain and right.”

“If you want to see what’s going on, you don’t watch the person who’s speaking – you watch the others in the group.”

(more…)

Une fois encore, l’événement Agile Testing Conférence qui s’est déroulé à Berlin du 14 au 17 Novembre 2011 a tenu toutes ses promesses. Il faut dire que l’exercice était facile vu la brochette de stars d’Agile Testing qui était présente, comme Lisa Crispin, Janet Gregory, Gojko Adzic, Liz Keogh et bien d’autres.

L’édition 2011 de l’Agile testing Conférence a été marquée par des réflexions autour des thèmes sur le rôle du Test au sein de l’organisation, les stratégies d’automatisation des tests intelligentes et surtout les immenses défis auxquels est confrontée aujourd’hui l’industrie IT.

Il est évident que les professionnels du Test ont tout intérêt à repenser profondément leur stratégie, repositionner le Test au sein de l’organisation et adopter des principes et pratiques en adéquation avec les défis d’aujourd’hui. Désormais, le rôle du Test est de livrer le plus rapidement de la valeur au client avec le moindre risque ” business ”.  Je reviendrai sur ce point lors de mon résumé du 2^ème jour.

(more…)

Certification Scrum Master :
Dernièrement, nous recevions Dave Pior pour une session Certified ScrumMaster animée en anglais. A cette occasion, nous avons produit une vidéo présentant les particularités de cette formation de 3 jours.

Certification Agile PMI :
Avec la parution du catalogue 2012, nous avons le plaisir de vous annoncer l’arrivée d’une formation de préparation à la certification Agile PMI.

Agile UX :
Du 27 au 28 octobre, Jean-Claude Grosjean animera la formation sur l’intégration de l’expérience utilisateur agile dans les projets.

Coaching Agile :
Notre offre de service vient de s’enrichir d’une offre de coaching sur les méthodes et pratiques agiles. ces missions d’accompagnement peuvent s’adresser à une personne comme à une équipe projet.
Par ailleurs, nous venons de planifier des dates de formation au coaching d’équipe projet agile.

Intégrer l'expérience utilisateur agile dans vos projets (Agile UX)

Comme je le disais récemment dans un tweet, j’ai finalement réussi à configurer le build Maven pour que la couverture du code par les tests, affichée dans le dashboard Sonar, tienne compte des tests Fitnesse.

En voila un sujet pointu ! Pourtant, à la suite de ce tweet, plusieurs personnes m’ont demandé une version longue. Je vais donc essayer dans ce message de décrire en détail la configuration complète que nous avons mise en place. J’espère que vous saurez comprendre le fonctionnement de cette solution, pour ensuite l’adapter à votre situation personnelle. Pour ceux qui ne comprennent pas les 3 premiers mot du titre, vous pouvez si vous le désirez vous plonger dans une bonne demi-heure de perplexité et lire la suite de ce message.

Intégration de Fitnesse dans le build Maven

Nous utilisons Fitnesse comme base de documentation pour notre projet. Le wiki contient toute sorte de documentation, technique ou non, concernant le projet ainsi que, bien entendu, tous les spécifications fonctionnelles automatisées.

Remarque : dans la suite de cet article, je parle indifféremment de spécifications fonctionnelles automatisées, de spécifications exécutables ou de tests Fitnesse. Toutes ces appellations désigne la même chose.

Fitnesse n’utilise pas de base de données, mais une hiérarchie de répertoires et de fichiers textes qui représentent les pages du wiki. L’intégralité du projet Fitnesse est contenu dans un répertoire qui est installé dans la gestion de configuration (sur notre projet, nous avons utilisé Git). Cette solution a l’avantage de permettre à tous les développeurs de l’équipe d’avoir une version complète du site en local sur leur poste. Ils peuvent ainsi exécuter les spécifications localement sur leur poste, avant de soumettre le code et les pages Fitnesse correspondantes à l’intégration continue.

Au niveau du build Maven, nous avons dédié un module à Fitnesse. Voici un extrait du répertoire racine de notre projet :

Vous voyez que dans notre répertoire lcwp-fitnesse (lcwp est le nom du projet) se trouve un fichier pom.xml. Le répertoire src ne contient pas de code. Toutes les pages du wiki sont dans le répertoire FitNesseRoot. Vous voyez aussi le fichier fitnesse.jar qui est l’exécutable proprement dit. Bien qu’il ne soit pas recommandé de mettre des binaires en gestion de configuration, nous faisons une exception pour celui-ci car c’est vraiment plus pratique comme ça.

Le plug-in Maven pour auto-générer le classpath utilisé par Fitnesse

Il s’agit du plugin maven-fitnesse-cpgen-plugin qui se trouve être un plugin développé par Valtech. Pour la documentation, suivez le lien suivant : http://source.valtech.com/maven-sites/maven-fitnesse-cpgen-plugin/usage.html

Installation du plugin

Pour utiliser ce plugin il suffit de référencer le dépôt Maven de Valtech (voir le lien ci-dessus) dans votre fichier setting.xml et d’ajouter la section XML suivante dans le fichier lcwp-fitnesse/pom.xml

<plugin>
	<groupId>com.valtech.source.maven</groupId>
	<artifactId>maven-fitnesse-cpgen-plugin</artifactId>
	<version>1.0</version>
	<configuration>
		<fitnesseRoot>${basedir}/FitNesseRoot</fitnesseRoot>
	</configuration>
	<executions>
		<execution>
			<phase>package</phase>
			<goals>
				<goal>gencp</goal>
			</goals>
		</execution>
	</executions>
</plugin>

Contenu de la page “root”

Vous devez ensuite modifier le fichier lcwp-fitnesse/FitNesseRoot/content.txt pour qu’il contienne exactement le texte suivant. Ce fichier correspond à la page “root” du site (http://localhost:9090/root) :

!define TEST_SYSTEM {slim}
 
!include ProjectPath
 
# begin of maven classpath
# end of maven classpath

La première ligne ne concerne pas notre sujet. Elle indique que tous nos pages Fitnesse seront exécutés avec le moteur SLIM.

Le plug-in ajoutera tout le classpath maven, dont les dépendances sont décrites dans le pom.xml du module lcwp-fitnesse, entre les deux dernières lignes du fichier.

La page ProjectPath contient des chemins spécifiques qui ne seront pas ajoutés par le plugin et que nous devons donc ajouter nous même. J’en reparlerai plus tard. Elle contient une partie de l’astuce ultime de notre solution.

Problème : ce fichier lcwp-fitnesse/FitNesseRoot/content.txt sera modifié à chaque build et le classpath inséré par Maven sera potentiellement différent pour chaque poste de développeur. Ce fichier ne peut donc pas être géré dans Git (il faut l’ajouter au fichier .gitIgnore).

Astuce : Pour que chaque développeur ne soit pas obligé de créer ce fichier sur son poste, nous avons ajouté la configuration suivante dans notre pom.xml :

<plugin>
	<artifactId>maven-antrun-plugin</artifactId>
	<version>1.6</version>
	<executions>
		<execution>
			<phase>generate-sources</phase>
			<goals>
				<goal>run</goal>
			</goals>
			<configuration>
				<tasks>
					<echo>Fitnesse root</echo>
					<copy file="src/test/resources/fitnesseRootContent.txt"
						tofile="${project.basedir}/FitNesseRoot/content.txt" overwrite="true" />
				</tasks>
			</configuration>
		</execution>
	</executions>
</plugin>

Le contenu standard du fichier lcwp-fitnesse/FitNesseRoot/content.txt est enregistré dans le fichier src/test/resources/fitnesseRootContent.txt qui lui est géré dans Git. Ce fichier est recopié au moment du build, juste avant l’éxécution du plugin maven-fitnesse-cpgen-plugin.

Propriétés de la page “root”

Enfin, vous devez changer une propriété de la page root pour quelle soit de type “Suite”. C’est nécessaire pour que le plugin maven trouve la page. Vous pouvez le faire par le wiki en vous rendant à l’URL http://localhost:9090/root, en cliquant sur le bouton “Properties” et en sélectionnant “Suite” pour la propriété “Page type”. Alternativement, vous pouvez aussi directement modifier le fichier lcwp-fitnesse/FitNesseRoot/properties.xml pour qu’il contienne la balise <Suite/>. Voici par exemple le contenu de notre fichier :

<?xml version="1.0"?>
<properties>
	<Edit/>
	<Files/>
	<Help></Help>
	<Properties/>
	<RecentChanges/>
	<Refactor/>
	<Search/>
	<Suite/>
	<Suites></Suites>
	<Versions/>
	<WhereUsed/>
</properties>

Le contenu de la page ProjectPath

Le plugin décrit précédemment nous a permis de gérer simplement le gigantesque classpath des dépendances vers les composants externes de notre projet. C’est la page ProjectPath qui contient les chemins vers le code proprement dit de notre projet. Voici son contenu dans notre cas :

!path ../lcwp-web/target/generated-classes/cobertura
!path ../lcwp-web/target/classes
!path ../lcwp-core/target/classes
!path ../lcwp-integration/target/classes
!path ../lcwp-web/target/test-classes
!path ../lcwp-test-support/target/classes

Le chemin est indiqué relativement au répertoire lcwp-fitnesse, c’est pourquoi tout les chemins sont précédés de “../“.

Et voilà la solution du problème : Pour que la couverture des tests affichée dans le dashboard Sonar tienne compte des tests Fitnesse, il faut que ces derniers soit exécutés sur le code instrumenté par cobertura. Le code instrumenté est généré dans le répertoire target/generated-classes/cobertura. Avec la première ligne de notre fichier nous obtiendrons donc la couverture du code du module lcwp-web.

En développement, le répertoire generated-classes/cobertura est vide et c’est la ligne suivante qui permettra de trouver le code du module lcwp-web.

Pour information, nous avons mis le code des fixtures Fitnesse dans l’arborescence de tests du module lcw-web. C’est donc la ligne ../lcwp-web/target/test-classes qui permet de le trouver.

L’exécution des spécifications par Maven

Tout ce que je viens d’expliquer nous permet d’exécuter les spécifications depuis le wiki.

En local sur le poste d’un développeur, vous devez démarrez Fitnesse avec les commandes suivantes :

cd lcwp-fitnesse
java -jar fitnesse.jar -p 9090 -e 0

Ensuite, vous pouvez vous rendre sur le site à l’URL : http://localhost:9090/FrontPage, naviguer jusqu’à la page de spécification qui vous intéresse et cliquer sur le bouton [Test] (dans la colonne de gauche) pour l’exécuter.

Mais ce que nous voulons, c’est que toutes les spécifications Fitnesse soit exécutées lors du build maven, c’est à dire à l’exécution de la commande mvn clean package

Fitnesse vous propose une ligne de commande pour exécuter tous ses tests :

java -jar fitnesse.jar -c DetailedSpecifications?suite&format=text

DetailedSpecifications est la page du wiki, racine de toutes nos spécifications. Elle est de type “Suite”.

Nous avons tout d’abord ajouté au build un appel à cette commande en utilisant le plugin ant de maven, mais il nous a paru finalement plus simple de faire un appel système dans un tests unitaire jUnit. En effet, la seule façon de savoir si les tests se sont exécutés correctement est d’analyser la sortie standard, le code de retour de cette commande (code de retour de la JVM en fait) étant zéro dans tous les cas. Il est nettement plus facile d’analyser cette sortie en java qu’avec la configuration XML du plug-in ant de maven.

Ce test unitaire doit faire parti des tests du module lcwp-web (c’est la couverture sur ce module qui nous intéresse). Il doit donc se trouver dans l’arborescence lcwp-web/src/test/java/...

J’ai posté le code sur GitHub à l’URL suivante :
https://github.com/etienneCharignon/FitnesseTools/blob/master/fitnesse/tools/FitnesseTest.java

Conclusion

Une belle image vaut mieux qu’un long discours. Nous sommes passés d’un peu plus de 25% à 65,20 % :

Agile 2011, la conférence mondiale sur l’agilité s’est déroulée à Salt Lake City aux Etas-Unis du 8 au 12 août 2011.
Que faut-il retenir du plus important rassemblement d’agilistes de l’année (1600 personnes) ? A travers cette revue de presse, nous allons le découvrir ensemble.
(more…)

L’Agilité est aujourd’hui reconnue comme l’une des solutions incontournables pour conférer aux entreprises la maîtrise et la souplesse nécessaire à la création de valeur.

A l’occasion d’un cocktail apéritif à Paris le 7 juillet, le Cercle des Dirigeants Agiles vous invite  à découvrir par l’exemple la mise en place d’une transformation Agile au sein de votre organisation.

Au programme :

Transformation Agile : de la PME au grand Groupe international…