OCTO organise le mardi 07 février 2012 à partir de 8h45 un petit-déjeuner gratuit, aux Salons Wagram  « L’agilité à grande échelle » : retour d’expérience en partenariat avec Strator.

Un projet de développement logiciel impliquant 80 personnes, distribuées sur 9 équipes réparties dans 4 pays.
Un produit devant soutenir une activité de plus de 5 000 000 de transactions de vente par jour.
Une première mise en production au bout de 6 mois.
Et de nouvelles fonctionnalités tous les deux mois.

Qui a dit que l’agile n’était pas adapté aux gros projets ?

Strator et OCTO Technology se proposent de partager avec vous un retour d’expérience sur la mise en place de méthodes agiles à large échelle : feature-teams, communautés de pratique, interactions avec des équipes off-shore, livraisons fréquentes et mises en production par un simple clic, prise de décisions collaboratives…

A l’issue de ce séminaire nous aurons partagé avec vous :

• Nos Do’s & Don’t à propos des méthodes agiles lorsqu’elles sont appliquées à de gros projets
• Les modèles d’organisation que nous avons mis en oeuvre
• Nos meilleures pratiques pour diriger des équipes projets géographiquement distribuées
• Les outils et les compétences clés pour démarrer un tel projet

Ce petit-déjeuner s’adresse aux :

• DSI
• Chefs de projets
• Responsables Innovation / e-business / Internet
• Responsables MOA / MOE
• Architectes

Intervenant(s) :
Philippe Chevalier – Strator, Directeur Technique
Hervé Lourdin – OCTO, Delivery Manager
Mathieu Despriee – OCTO, Manager

Ce petit-déjeuner est à destination de nos clients et prospects en priorité.

Cliquez ici pour vous inscrire au petit-déjeuner : Agilité

Suggestion d'articles :

1. Vidéo du petit-déjeuner « Comment bâtir votre Cloud ? » organisé par OCTO Technology
2. OCTO organise un petit-déjeuner Gestion des Identités le 27 janvier – Témoignage d’Air Liquide
3. OCTO organise un petit-déjeuner sur l’agilité, jeudi 12 novembre

Le praticien agile, c’est qui  ?

Il a lu « Scrum & XP from the trenches » un soir, il l’a gardé 2 semaines comme livre de chevet, il l’a rangé, et il a participé à un ou plusieurs projets agiles au sein de sa DSI. il a atteint un certain niveau de maturité sur les projets agiles et a pris du recul sur la méthode. Il se pose aujourd’hui des questions comme « Peut-on vraiment concilier TMA et agilité? »ou alors « Comment pérenniser la dynamique d’amélioration continue au sein de mes équipes » ou bien encore « Comment fluidifier les process en amont et en aval de mon équipe Scrum? », etc.

Le format Open Space c’est quoi ?

C’est un format ouvert sur une demi journée, où les participants proposent et choisissent eux-mêmes les sujets sur lesquels ils vont ensuite travailler par petits groupes lors de sessions de 40 minutes. A l’issue de chaque session, chaque groupe présente à l’ensemble de l’assemblée un compte-rendu des échanges. La philosophie de l’exercice est très bien décrite ici.

Et pourquoi un Open Space pour praticiens agiles ?

Parce que la communauté de praticiens agiles est de plus en plus grande et que nous, OCTO, constatons que les questions qui reviennent chez nos clients Agiles sont souvent focalisées autour des mêmes problématiques.

Après avoir organisé plusieurs ateliers découvertes de l’agile sur le format Open Space ces dernières années, nous avons donc organisé et animé une première session dédiée au praticiens agiles le 24 Novembre dernier, à laquelle ont participé des acteurs comme Médiametrie, FigaroCMS, Viadeo, Danone et Allocine.

Nous avons eu le privilège d’accueillir l’illustratrice Véronique Olivier-Martin (vous trouverez une présentation de ses interventions par Pierre Haski sur Rue89) dont le rôle consistait à capter en direct et faire émerger sur une fresque murale géante les principaux échanges au sein des groupes de travail : le résultat est détonnant et nous souhaitions partager le fruit de ce travail collaboratif riche avec vous.Vous pouvez télécharger la fresque en qualité originale ici. Et pour le plaisir, voici ci-dessous quelques illustrations issues de cette fresque et très représentatifs de nos échanges :

Waouh ça déchire ! La prochaine session c’est quand ?

Nous avons donc décidé de pérenniser l’événement sur le fond et sur la forme ! La prochaine session aura lieu Mardi 14 Février de 14h à 18h chez OCTO.

Super, je suis praticien agile et je souhaite prticiper, comment je m’inscris ?

Vous pouvez d’ores et déjà confirmer votre inscription ici!

Suggestion d'articles :

1. Open Space OCTO : nouvelle session praticiens agiles le 14 Février
2. Open Space pour les praticiens agiles le 24 novembre chez OCTO
3. Open Space « La Pilule Rouge – Comment faciliter la collaboration distante dans nos organisations ? »

Cet article est une synthèse d’un échange sur une mailing-list interne Octo, qu’il nous a paru intéressant de partager. Merci à Jonathan Scher, Ludovic Cinquin, Yannick Martel, William Montaz et les autres pour leurs contributions. Bonne lecture !

Un de nos consultants est embarqué chez l’un de nos clients, dans un projet de dev d’une application web innovante, à interface très riche. Ce projet est conduit par le client suivant une bonne vieille méthode en cascade…

Il se trouve dans l’équipe en charge du développement du « front ». Le reste du projet (web-services et stockage) est réalisé par une autre équipe.

Et il et se désole tous les jours des freins qu’il rencontre à la production d’une application de qualité : IDE imposé et obsolète, système de gestion de versions inutilisable, batailles sans fin avec l’équipe d’architecture transverse qui impose des technologies obsolètes et incompatibles avec l’ambition du projet.

Les specs sont relativement contraignantes et conduisent au développement d’une appli assez pauvre sur le plan architectural (domaine anémique, code passe-plat…)

Au-delà de ces aspects techniques, le projet souffre également des défauts de la cascade : les écrans sont produits par une web-agency depuis longtemps, et l’intégrateur web à déjà créé 2 mois de stock en amont des développeurs, quand notre consultant se rend compte que le HTML produit sera inutilisable en l’état. Il faut reprendre HTML et CSS, ce qui donne des sueurs froides au chef de projet (planning), et à l’intégrateur web (qui n’a pas très envie de revenir sur 2 mois de travail).

Stocks, défauts qui s’entassent dans la chaîne de production … c’est-à-dire des freins à une production efficiente (cf Lean ou encore la théorie des contraintes de Goldratt)

Autant de raisons qui poussent notre consultant à argumenter en faveur de l’Agile auprès de notre client… mais il se voit opposer un certain nombre de contre-arguments.

Le design émergent voué à l’échec ?

L’agile ne serait que le développement de petites fonctionnalités les unes derrière les autres, sans penser au lendemain, et où l’on passe un temps très coûteux à refactorer. Notre client, lui, préfère penser au logiciel dans son ensemble tout de suite, prenant en compte immédiatement les besoins fonctionnels et non-fonctionnels pour définir dès le début l’architecture cible.

Pour Jonathan :

On est dans le pari classique du « Big Design Up Front » vs « architecture émergente ».

Lorsque je fais du BDUF, je fais le pari suivant :  »Je passe du temps à concevoir quelque chose de générique et de réutilisable ».

Dans la pratique, on se rend compte que dans 80% des cas, la généricité n’est pas utilisée. Et elle ajoute une couche de complexité.

D’autant que dans le Big Design Up-Front, il faut penser à tout, tout de suite. Hors, nos projets sont de plus en plus complexes : appréhender le système dans sa globalité (infra, intégration, stockage, performance, sécurité, ergonomie…) est mission impossible. Surtout dans un contexte d’innovation.

Jonathan :

Lorsque je fais du design émergent, je fais le pari suivant : « Je fais du spécifique. Je passerai ensuite du temps à réutiliser mon code. Mais je passerai moins de temps à le faire que ce que j’aurais perdu à rendre TOUT réutilisable ».

La facture se paye, mais d’un côté on la paye tout au début, par une grande analyse, et de l’autre côté on la paye en refactoring. Et le refactoring, nous faisons tout pour qu’il soit le moins cher possible, notamment grâce au harnais de tests.

Enfin, quelque chose que je recommande sur tous mes projets : prendre en compte très tôt dans le projet les besoins non fonctionnels. Il faut 10’000 utilisateurs en même temps ? Je mets en place un test le prouvant dès le début, et je surveille tout au long du développement.

Mais comme le souligne William :

Le client a généralement du mal à accepter de passer du temps (ie. dépenser de l’argent) sur une révision de l’archi en cours de projet. Il perçoit ça comme une trahison, un mensonge sur la vitesse de livraison. Mais en fait l’agile ne promet pas d’aller plus vite.

L’une des promesses de l’Agile, c’est qu’au contraire, on PEUT se permettre une révision de l’archi. Introduire un ORM dans une couche d’accès aux données, découper un modèle de données en sous-parties et les déplacer dans l’infrastructure, changer de framework d’IHM … tout ça sont des chantiers qui bousculent le socle d’une appli et qui sont certes difficiles, mais néanmoins faisables. Surtout si on a mis en place un harnais de tests suffisamment complet.

Ce genre de chantier est carrément irréaliste en cascade, car on s’en aperçoit souvent trop tard, et il serait trop risqué et/ou coûteux de changer son fusil d’épaule.

En fait, faire du « design émergent » ne signifie pas qu’on arrête de travailler sur l’archi, bien au contraire ! Ca permet même aux architectes de se concentrer sur des problématiques moyen-terme (au travers de dossiers d’archi, de POC, de tests…), en faisant confiance aux développeurs pour prendre un certain nombre de décisions plus court-terme par eux-mêmes.

L’agile inadapté au « monde réel » ?

Mais au-delà de cela, pour ce client, l’agile est une belle utopie qui ne résiste pas au « monde réel » : celui de la contractualisation. Un budget doit être évalué en amont, le projet doit aboutir à la date convenue, le livrable doit être conforme au cahier des charges (obligation de résultat), et le tout doit respecter le « droit » en vigueur (contractualisation interne ou avec le fournisseur).

Jonathan :

Effectivement, le modèle même du forfait est la cause de beaucoup de problèmes. Faire un forfait « dans le monde réel », c’est :

- Réfléchir à ce dont j’aurai besoin dans un an

- Rechercher un prestataire capable de s’engager à y répondre.

Et ça ne marche pas.

Si tu pars de l’idée que tu ne sais JAMAIS ce que tu veux un an à l’avance, ce qui est vrai pour tous les projets « innovants », l’agile devient une solution. On va construire ensemble ce que vous utiliserez dans deux mois, puis on améliorera. Et, oui, c’est très difficile à contractualiser.

C’est le modèle même, qui diffère :

D’un côté, la vision prônée par l’Agile : L’informatique doit être un centre de gains, non de coûts. Pour cela, il faut répondre au plus vite et au plus près des besoins utilisateur.

En face, il y a le « vrai » monde. Celui qui contractualise, qui ne prend pas de risque, qui a plus à coeur de respecter un droit informatique que d’évoluer.

Et, oui, introduire un modèle d’innovation, c’est prendre un risque.

Et, comme le rappelle William, passer d’un modèle au forfait à un autre modèle beaucoup plus impliquant pour le client, car beaucoup plus collaboratif, ne se fait pas sans peine :

Dur à vivre pour le client en fait, habitué à être serein tout le long du projet et à serrer la vis sur la fin…

Habitué à serrer la vis sur la fin, ou encore qui trouve normal de passer des nuits blanches à intégrer les projets en provenance de plusieurs équipes et qui ne s’intègrent pas comme prévu dans la spec !

Alors, comment introduire le changement ?

Comment convaincre ce chef de projet ? Comment lui-même peut-il convaincre sa hiérarchie d’aller vers l’Agile ?

Pour Ludo,

On est dans les contre-arguments classiques de l’agile. Et on est modèle contre modèle, ce qui ne mènera pas bien loin.

Il a visiblement sa conception du monde et aucune douleur qui ne justifie qu’il la change.

Il a donc raison… :)

Yannick :

La douleur est encore le meilleur facteur pour pousser quelqu’un au changement, mais il faut encore que celui-ci reconnaisse qu’il puisse être aidé et te laisse une ouverture, te fasse une demande, bref comme dirait Sinek que son cerveau reptilien soit réceptif…

Et en général sa demande va être pour l’aider à lever la douleur, et pas se voir proposer un modèle (plus ou moins controversé et à la mode : SOA, Agile, programmation objet… on les a tous vu).

Voilà peut-être le coeur du problème : considérer l’Agile comme un modèle à déployer comme ce qu’il-est-écrit-dans-le-bouquin.

L’entreprise, ou l’organisation, doit penser son propre modèle de production, adapté à son besoin d’innovation, son business, ses collaborateurs.

Et puiser dans la boite à outil de l’Agile (ou d’autres approches : Lean, DevOps…) ce qui est adapté à son contexte.

Suggestion d'articles :

1. Quand 01 déraille …
2. A quand de vraies architectures Stateless?
3. Python + doctest : quand la doc devient test

On a maintenant l’habitude de voir des principes du Lean Management derrière beaucoup des pratiques Agiles. Par exemple :

• Les tests unitaires et l’intégration continue, sorte de Andon et de Poka Yoke à la fois ;
• Les rétrospectives, support privilégié du Kaizen, sorte de cercle de qualité des équipes de développements ;
• Les taskboards, « kanban boards » et autres radiateurs d’information comme outil de management visuel ;
• etc.

Plus intéressant est l’exercice de voir les bonnes pratiques DevOps comme des instanciations du Lean Management aux activités de livraison, intégration, tests, déploiement, suivi du run.

Les analogies et principes sous-jacents du Lean pouvant alors nous aider à mieux comprendre la « magie » des pratiques DevOps ou même à en imaginer de nouvelles !

Les pratiques DevOps comme instanciation du Lean

Jidoka, l’autonomation

Le Jidoka est le premier pilier du Système de Production Toyota. C’est l’automatisation avec une touche humaine, ou comment automatiser les opérations simples et répétitives, tout en conservant un contrôle humain pour orchestrer tout cet outillage, et prendre en main les situations complexes. La légende veut qu’un fondateur Toyoda ait ajouté un système de détection d’anomalie et d’arrêt automatique sur des métiers à tisser.

En IT, DevOps poursuit la même démarche en poussant au maximum l’utilisation des robots d’intégration continue, de déploiement automatique, de configuration ou de supervision. Tools matter.

Just in Time, le juste à temps

Le Just in Time est le second pilier du Système de Production Toyota. C’est la mise en flux pour livrer juste à temps (ni avant ni après) le produit demandé, dans la quantité demandée. Les outils du Jidoka sont le lissage, la réduction de la taille des lots (livrer plus souvent de plus petits lots) et surtout la diminution du coût de traitement d’un batch avec SMED.

La comparaison avec DevOps saute aux yeux lorsqu’on cherche à mettre en production plus régulièrement de plus petits lots de fonctionnalité.

Une fois le principe du JIT saisi, nous avons entre nos mains les outils théoriques pour mieux comprendre nos problèmes de fréquence de livraison, notamment :

• débusquer les opportunités de « SMED » et de diminution du coût de traitement d’un lot dans notre process dev⇒prod afin de diminuer le coût d’un déploiement, pour tendre vers le déploiement en continu ;
• déterminer la taille de batch optimale, i.e. la taille de MEP optimale pour un niveau d’outillage et de process donnés (à optimiser par SMED en parallèle).

Kaizen, l’amélioration continue

Pilier du Modèle Toyota, le Le Kaizen, consiste à tirer des leçons des problèmes, enrichir notre « système » et ceci à travers une démarche structurée et des outils d’analyse éprouvés (PDCA, 5 pourquois, diagramme de Pareto etc). On a tous envie de s’améliorer, le Kaizen nous aide à structurer et rendre efficace ces efforts d’amélioration.

La communauté DevOps n’est pas en reste et reconnaît qu’elle fait face à des systèmes complexes qui échoueront tôt ou tard, les champions étant ceux qui tireront vite et bien les leçons des échecs petits et grands. A titre d’illustration, le livre Web Operations y dédie un chapitre entier : « How to Make Failure Beautiful: The Art and Science of Postmortems ».

L’autre aspect souvent négligé ou mal compris de l’amélioration continue en DevOps vient de la réduction de la taille des lots (i.e. l’augmentation des livraisons de plus petit « batch » de code). Le Lean prend l’image suivante : diminuer le niveau de l’eau fait apparaître les rochers entre lesquels ils faut naviguer.
L’eau c’est le stock, dans notre cas tout ce qui n’est pas déployé, les rocher sont les problèmes. Quand on livre plus souvent on découvre plus souvent des problèmes. On peut dire qu’on met aussi en flux la découverte/résolution de problème !
Les problèmes sont plus fréquents, plus visibles, plus petits (moins de code), plus maitrisables.

Management de la performance

Le Lean Management, comme d’autres corpus de management insiste sur la pré éminence des métriques, les fameuses « KPI », pour factualiser la performance actuelle et l’écart à l’objectif et ainsi mieux piloter le navire. Gardons aussi à l’esprit la mise en garde de Deming qui nous explique que gérer une entreprise seulement par des métriques fait partie des 7 « maladies du management ».

DevOps insiste sur l’importance des métriques, aussi bien sur le système technique (utilisation des ressources, temps de réponse..) que sur le processus (« Time to Diagnose » d’incidents, Lead Time dev⇒prod etc). Mesurons plus nous disent les top performers du web.

Equipe pluridisciplinaire

Dans l’industrie Toyota a initié les cellules en U dans lesquelles un opérateur est multi compétent, passant d’un poste à l’autre, en suivant la pièce le long de la chaîne (à l’opposé du Charlot mono tâche des Temps Modernes).
En Lean Product Development, Toyota a réduit à l’extrême ses délais de conception, notamment en rapprochant designers, motoristes et ingénieurs responsables de la production en série.
DevOps : des dev plus ops, des ops plus dev, des dev et des ops qui binôment.

Conclusion

Il reste un dernier rapprochement entre devOps et le Lean. Womack et Jones ont inventé le terme « Lean » (« léger », « maigre » en anglais) car il trouvait la méthode japonaise plus légère que ses concurrentes occidentales (par exemple ISO), plus explicable, plus « maniable ». C’est ce même caractère de pragmatisme et d’utilisabilité qui frappe quand on compare DevOps à ITIL. Sur les problématiques communes DevOps/ITIL (notamment gestion des changements, gestion des alertes, capacity planning, amélioration continue…), les intentions sont identiques et les recommandations se recouvrent parfois. N’empêche : dans un cas le corpus de pratique est organique et actionnable, dans l’autre il est complexe et nécessite une expertise et une exhaustivité intimidante.

Redécouvrir et approfondir les principes et pratiques du Lean Management nous permet alors d’apporter des gains substantiels au traitement des problématiques DevOps.

Les gurus de la communauté Lean (par exemple Jez Humble, auteur de Continuous Deployment ou les top performers de Wealthfront ou IMVU) ne s’y sont pas trompés lorsqu’ils basent leurs réflexions DevOps sur des outils du Lean comme le Value Stream Mapping, placent la littérature Lean en bonne place dans leur bibliothèque, ou envisagent les problèmes DevOps avec les mots et les concepts du Lean.

Ces derniers mois, les consultants OCTO ont régulièrement pioché dans la « mallette Lean » afin de rendre encore plus efficaces leurs interventions touchant au domaine DevOps.

En définitive, on redécouvre l’étonnante réponse à la question « qu’est-ce que des techniciens de l’industrie automobile peuvent apprendre aux stars de l’IT ». Beaucoup.

Suggestion d'articles :

1. OCTO accueille le 3ème meetup devops parisien le 16 mars
2. 2ème compte rendu du séminaire « Lean dans les Services »
3. Du Lean Software Development au Lean IT

• Demander à chaque participant de donner son rôle sur le projet et ses attentes pour cette rétrospective
• Les noter sur une feuille de paperboard
• Demander au groupe s’il y avait d’autres membres qui ne sont pas présents, importants sur le projet, et leur rôle

L’animation du recueil des événements importants peut se dérouler de la façon suivante:

• Demander à chacun de noter les événements importants du projet pour lui avec les consignes d’écrire en majuscule un seul événement important par post-it: « Quels ont été les événements importants pour vous sur ce projet ?
• Demander à chaque participant d’aller présenter les post-it qu’il a écrit. La consigne pour les autres est de poser des questions de clarification. En fonction, le post-it peut être réécrit pour être plus lisible pour les autres
• Demander ensuite aux participants si d’autres événements leur viennent à l’esprit à partir de ce que chacun a présenté: « Avez-vous d’autres événements qui vous viennent à l’esprit ? »
• Nettoyer la timeline et permettre aux participants de bien l’avoir à l’esprit: « Y’a t-il des événements en doublon ? », « Selon vous, est ce que les événements sont bien positionnés dans le temps ? »
• Redemander aux participants si un événement important a été oublié: « Y’a t-il un événement important qui a été oublié ? »

Conseil d’animation:

• Dans l’étape 1, vous pouvez demander aux participants de trouver 10 événements importants pour leur donner un défi et solliciter leur mémoire. Cette étape se fait en silence pour permettre plus facilement la remémorisation
• Les étapes 3,4,5 permettent « d’ancrer » la timeline dans l’esprit des participants et de solliciter leur concentration grâce à une répétition
• N’hésitez pas à demander aux participants si les post-it sont lisibles et à demander de les refaire sinon (qualité first !)
• Si vous avez des graphiques projets (burndown chart, velocity chart), il peut être pertinent de les afficher à côté de la timeline

La deuxième partie correspondant à la construction du sismographe d’énergie:

• Demander à chaque participant de prendre individuellement un temps de réflexion sur comment était son niveau d’énergie au cours du projet et visualiser la courbe
• Demander à celui qui souhaite, de commencer à tracer sa courbe d’une couleur et de mettre son prénom ou trigramme
• Puis au suivant

Une fois terminé la construction de la timeline et du sismographe, il est alors possible de retirer quelques apprentissages utiles pour d’autres projets.

Exploiter la timeline

L’exploitation de la timeline peut se faire de la façon suivante:

• Inviter les participants à se lever et parcourir la timeline silencieusement pendant quelques temps et une fois qu’ils sont prêts d’aller s’asseoir
• Faciliter une discussion autour de ces questions:
  • Quels sont les événements qui vous ont marqués ?
  • Qu’est ce qui vous surprend sur la timeline ?
  • Qu’est ce que vous a révélé la construction de cette timeline ?
  • De quels éléments souhaitez vous discuter avec le reste du groupe ?
• Après cette discussion, demandez au groupe de se répartir en 3 sous-groupes, chacun répondant à une des questions suivantes sur une feuille de paperboard en s’appuyant sur la timeline et le sismographe:
  • Qu’est ce que nous avons bien réussi ?
  • Qu’est ce que nous pouvons améliorer ?
  • Quelles recommandations pouvons nous faire à une nouvelle équipe projet qui démarre ?
• Demandez à ce qu’un rapporteur de chaque sous-groupe vienne présenter le travail
• Les autres peuvent poser des questions de clarification
• Une fois que le rapporteur a terminé, demandez aux autres participants s’ils ont d’autres choses à ajouter, les noter le cas échéant
• Passer aux autres questions

En clôture de la rétrospective, il est possible de poser deux questions à chaque participant:

• Où en êtes vous par rapport à vos attentes ?
• Quelle est la chose que vous gardez en tête et que vous allez amener dans vos prochains projets ?

Il est important de passer du temps dans la construction de la timeline pour permettre à l’équipe de se remémorer les moments importants du projet car parfois la rétrospective ne se fait pas toute de suite après la fin du projet. Il peut arriver qu’après un atelier comme celui-ci que les personnes aient l’impression d’avoir passé un bon moment et qu’à peine sorties de la salle elles oublient ce qu’elles ont pu dire. La projection dans le futur de chaque participant en clôture est une bonne pratique pour permettre aux personnes présentes de partir au moins avec quelque chose qu’elle pourra réutiliser par la suite. La synthèse écrite est faite en général par l’animateur et doit être bien sûr envoyée à tous les participants et stockée dans l’outil de Knowledge Management de l’entreprise afin de permettre une réutilisation de l’expérience acquise.

Suggestion d'articles :

1. Animer des rétrospectives d’itération
2. Comment mieux prioriser en projet agile
3. Quels sont les types de tests que l’on utilise sur un projet agile ?

A l’occasion de l’édition 2011 de la conférence Agile France qui aura lieu les 26 et 27 mai à Paris, OCTO présentera les sessions suivantes :

• « La Pilule Rouge, des pistes pour la collaboration distante » par Guillaume Duquesnay
• « L’Agiliste et l’Iphoniste, une histoire de couple » par Jean-François Grang
• « Transition Agile – Culture du changement ou changement de culture ? » par Thomas Lissajoux
• « Comment réussir un projet Agile très court » par Jonathan Scher
• « Agilité et modèle de changement » par Mathieu Gandin

Parmi les autres sessions, on retrouve les sujets suivants :

• « Dans la peau du manager agile » Par Jean-Claude Grosjean
• « Comment prioriser quand on innove ? » par Raphael Pierquin
• « Au delà du développement Agile : Retour d’expérience Lean IT » par Régis Médina
• « Résoudre les conflits avec l’outil Conflict » par Pascal Van Cauwenberghe
• « Quarante ans de crise, dix ans d’Agilité, et maintenant ? » par Laurent Bossavit

La suite du programme de la conférence Agile France se trouve sur le site d’Agile France.

Si vous avez des questions sur l’agilité, rendez vous les 26 et 27 mai au Chalet de la porte jaune à Paris, vous aurez la chance de nous y retrouver.

Suggestion d'articles :

1. Interview des orateurs OCTO pour la conférence Agile France
2. Octo soutient : Agile Open France 2009
3. OCTO organise un petit déjeuner sur le thème des Maîtrises d’Ouvrage Agile

La rétrospective dans les méthodes agiles est un moment important dans un projet. La rétrospective est une pratique qui permet de répondre au 12ème principe agile du Manifeste Agile: « À intervalle régulier, l’équipe réfléchit aux moyens de devenir plus efficace, puis accorde et ajuste son comportement dans ce sens ». Ritualiser cet événement permet de mettre en place un processus d’amélioration continue. Même si parfois, l’équipe a l’impression qu’il ne s’est rien passé, il s’est passé quelque chose, le plus important étant de garder cet espace de prise de recul.

Couramment, deux types de rétrospectives sont faites dans les projets agiles: les rétrospectives d’itération et les rétrospectives de release/projet. Cet article parlera des rétrospectives d’itérations et présentera 2 outils simples, le Keep Drop Start et la note d’itération.

Pour une rétrospective d’une itération de deux semaines, il est recommandé de faire une rétrospective de 2 heures, pour une itération d’une semaine, 1h.

Keep Drop Start

L’outil le plus simple utilisé pour une rétrospective d’itération est le Keep Drop Start:

Couramment, chaque participant  est invité à noter en gros et majuscule sur des post-it les choses qui lui viennent sans se brider pour chaque partie:

• Ce qui fonctionne bien, ce qu’il faut garder (Keep)
• Ce qui fonctionne moins bien, ce qu’il faut supprimer (Drop)
• Ce qui reste mystérieux
• Ce qui fonctionnerait bien si…, ce qu’il faudrait faire (Start)

Conseil d’animation:

• Si vous sentez le groupe bloqué, vous avez toujours une personne qui a plus d’idées que les autres, demandez lui de dire à voix haute quelques-unes de ces idées et d’aller les afficher
• Si personne n’a d’idées, guider les participants sur des thématiques: « réfléchissez à l’estimation, les réunions, le code, à ce qui pourrait-être améliorer ? » et tant qu’à faire sur ce que vous avez observé vous-même pendant l’itération
• L’important dans l’animation de la rétrospective est que l’équipe prenne conscience par elle-même de ses points de blocages
• Je vous conseille de finir par un vote collectif (vote par bâton ou gommette) sur les 5 grandes idées / actions pour l’itération car cela permet de mobiliser l’équipe et il est irréaliste de croire qu’une équipe puisse faire plus de 5 actions d’amélioration en 2 semaines, au moins au début
• Au bout d’un moment (3/5 itérations), vous pouvez inviter un membre de l’équipe à l’animer à votre place pour favoriser la prise d’initiative et dans l’idéal l’animateur tourne

Pièges à éviter:

• En tant qu’animateur de la réunion, vous voulez que l’équipe sorte absolument avec un plan d’actions, vous voulez alors à la place de l’équipe et donc vous la déresponsabiliser. Parfois la prise de conscience suffit à ce que les choses ne se reproduisent pas

La note d’itération

La note d’itération peut aussi être utilisée si vous avez moins de temps et pour changer. Changer d’outil peut être stratégique car il peut permettre de sortir des habitudes prises par l’équipe.

Pour la note d’itération, vous pouvez utiliser ce processus inspiré de l’approche orientée vers les solutions:

• Demandez à chacun de positionner son niveau de satisfaction de l’itération sur une échelle de 1 à 7
• A partir du niveau estimé (Ex: 4), posez la question: « Qu’est ce qui fait que tu as mis 4 ? »
• Puis posez la question: « Qu’est ce qu’il faudrait pour avoir seulement 5 (4+1) ? »

Conseil d’animation:

• Commencez par les plus discrets et silencieux car ils ont souvent une bonne perception de la situation mais ils n’ont pas souvent la parole et ne la prennent pas
• Déléguez l’écriture sur le tableau blanc à un membre de l’équipe
• Comme vous êtes dans une approche circulaire, au bout de la 3ème ou 4 ème personne, les idées commencent à devenir identiques, vous pouvez alors inviter les prochains à annoncer ce qui est différent de ce qui a déjà été dit

Pièges à éviter:

• Discuter/Contredire ce que dit un participant, ceci aurait pour effet de brider ce que pourrait dire la personne

De rétrospectives en rétrospectives

Je constate souvent que les équipes agiles oublient ce qui s’est passé dans les rétrospectives précédentes, une sorte de perte de mémoire qui fait que rien ne se passe hormis le fait que tout reste pareil. La rétrospective est alors une sorte de bureau des plaintes où chacun exprime ses peurs, ses reproches, pour que tout fonctionne comme avant. Sommes-nous dans une approche d’amélioration continue ? pas si sûr.

En tant qu’animateur, que faire avec ça ?

• Attendre. Pas d’actions, pas de réactions dans une rétrospective, ce n’est pas si grave quand cela arrive 1 ou 2 fois. Laisser l’équipe dans son jus a du bon pour la responsabiliser
• Demander au groupe quelles sont les actions qui avaient été décidées la dernière fois
• Se focaliser sur une action et aller chercher chaque étape en détail
• Faire un atelier pour sortir l’équipe du rituel rétrospective et faire un travail de fond
• Questionner le groupe sur les avantages pour lui de faire une rétrospective ou mieux avec une approche paradoxale: quels seraient les bénéfices de ne plus faire de rétrospective ?
• Provoquer le groupe: « Je pense qu’il est temps d’arrêter de faire des rétrospectives » accompagné d’un silence en espérant une réaction et qu’un leader va émergé… c’est un peu du quitte ou double

Il est courant de croire que la rétrospective est le seul moment où l’on puisse faire de l’amélioration continue. Dans la réalité, il est possible d’introduire des feedbacks de 10 minutes en fin de chaque réunion pour habituer l’équipe à se responsabiliser sur son fonctionnement.

L’amélioration continue est une approche de petits pas qui visent à ancrer un niveau supérieur dans une roue dentée. Il est clair que parfois cela ne suffit pas, même pire cela renforce le non changement d’une équipe, il faut alors envisager d’autres façons de faire, en rupture, qui demandent beaucoup plus de doigté car déstabilisantes pour une équipe.

Suggestion d'articles :

1. Animer une rétrospective projet
2. L’artefact ne fait pas le moine
3. Espace détente

(Charles est un coach agile. Daniel est un développeur dans un projet agile. Un vendredi à 18h30, l’heure de la bière).

Charles: Alors comment va votre projet ?
Daniel: Hmm. Y a des hauts et des bas. Jusqu’ici on avait une courbe de vélocité en progrès, et puis là, soudain, le trou d’air. Le client nous refuse 4 scénarios sur les 7 prévus dans l’itération… C’est logique d’ailleurs, ses tests de recette ne passent pas.
Charles: Qu’est-ce qui a changé ?
Daniel: Difficile à dire. On n’a pas de problème majeur, plutôt des tas de petits soucis qui s’accumulent depuis des semaines. Du coup le manager nous revoit lundi pour mieux comprendre ce qui se passe. Il nous a dit “votre courbe de vélocité, je n’y crois pas”.
Charles: Il a raison.
Daniel: Bah voilà. Merci pour l’encouragement. A la tienne.

Charles: Tchin! Tu me dis que la courbe de vélocité progresse et aussi que vous avez des tas de petits soucis qui s’accumulent depuis des semaines. Qu’est-ce que vous mesurez sous le terme “vélocité” ?
Daniel: Simple: c’est la somme des points des scénarios utilisateurs terminés par l’équipe à la fin de chaque itération.
Charles: Et ces points, comment vous les attribuez ?
Daniel: Je ne t’apprends rien: on fait un planning poker en début d’itération.
Charles: Comment ça se passe en ce moment le planning poker ?
Daniel: Eh bien.. Gérald, tu sais, celui qui est arrivé le mois dernier, n’estime pas comme nous. Par exemple il vote 5 sur un scénario , en nous expliquant : “Il y a deux contrôles et une validation en base, c’est grosso modo la même complexité que l’écran xyz, qui était estimé aussi à 5”. Alors que pour réaliser ce scénario, on doit monter de version le framework LycwXml 2.3, et c’est coton, vu l’état du code existant, En plus, en l’absence de Jean-Mi, c’est Gérald, qui débute, qui va faire. C’est plutôt un scénario a 25 points en fait.
Charles: Je vois. Comment ca c’est terminé ?
Daniel: Le scrum master a fini par trancher: “Allez, disons 21. Comme ça, ça vous fera une bonne vélocité.”
Charles: Oups!

Daniel: Tu penses que le scrum master n’aurait pas dû intervenir ?
Charles: J’en sais rien. Ce qui me frappe, c’est qu’on dirait que vous essayez d’avoir une bonne vélocité.
Daniel: Bah c’est le but, non? Une bonne vélocité, ça signifie que l’équipe fait bien son boulot.
Charles: Tu veux dire que si elle augmente, c’est que l’équipe travaille mieux, c’est ça ?
Daniel: Exactement.
Charles: Et quand elle diminue, c’est que l’équipe fait moins bien son travail ?
Daniel: Euh. C’est que l’équipe à des problèmes pour faire bien son travail.
Charles: Et donc, dans ce scénario à 21 points, rappelle-moi ce qui entrait en ligne de compte dans l’estimation ?
Daniel: Comme je t’ai dit: la montée de version du framework, l’état du code existant, l’absence de Jean-Mi.
Charles: Des problèmes, en quelque sorte.
Daniel: En quelque sorte.
Charles: Voilà. Vous essayez d’avoir une bonne vélocité, tout en intégrant les problèmes dans l’estimation. Si on va par là, plus vous avez de problèmes, plus vos scénarios comptent de points…
Daniel: Tu aurais un conseil, là ?

Charles: Eh bien, estimer le scénario comme l’a fait ton collègue, sur la base des fonctionnalités, en le comparant éventuellement à des scénarios précédents du même acabit, me paraît une bonne idée.
Daniel: Mais ça ne nous dit pas forcément le temps qu’il faudra effectivement passer sur ce scénario.
Charles: Exact, c’est une estimation “idéale” ou en “vitesse de croisière”. C’est pourquoi on la fait en points et non en JxH. Ce qu’on estime c’est la complexité fonctionnelle du résultat, et non l’effort à fournir.
Daniel: Et comment on estime l’effort à fournir, dans ce cas ?
Charles: Inutile.
Daniel: Je ne comprends plus.
Charles: Vous êtes 3 développeurs, donc par déduction vous consommez 15 JxH par itération. Ce n’est pas une information. Les points que vous collectez en fin d’itération, c’est de la quantité de fonctionnalités produites, et non de l’effort fourni. Donc ce qui doit entrer dans l’estimation, ce sont des points de complexité fonctionnelle, et non des efforts à fournir. Tu comprends ?
Daniel: Ca marcherait mieux avec un exemple.

Charles: Imagine une équipe qui développe des écrans de saisie. Les écrans sont estimés à 5 points. A l’itération 1 l’équipe produit 2 écrans; sa vélocité est de 10. A l’itération 2, elle gagne en assurance et arrive à produire plus vite; sa vélocité est passée à 15.
Daniel: Ok.
Charles: A l’itération 3, elle est impactée par un changement portant sur du code qui a été copié/collé. Elle doit factoriser son code. Sa vélocité repasse à 10. A l’itération 4, elle trouve une librairie d’expressions régulières qui lui évite de coder à la main les contrôles de saisie. Elle produit alors 6 écrans, soit 30 points.
Daniel: En gros, dès qu’elle s’outille, sa vélocité s’améliore.
Charles: Pas forcément: à l’itération 5, elle découvre un nouveau framework d’écran de saisie qui lui permettrait d’économiser encore plus de temps et de lignes de code. Elle l’installe, le configure, se forme. Sa vélocité tombe à 0.
Daniel: Ouch!
Charles: A l’itération 6, elle a le framework en main et produit 10 écrans par itération! Sa vélocité passe à 50 points. Etc. Les chiffres sont schématiques, mais ce que cet exemple montre, c’est que lorsque l’équipe rencontre des problèmes, la vélocité baisse, lorsqu’elle les résoud, sa vélocité augmente. Ce qui change, c’est la vitesse de l’équipe, pas la richesse fonctionnelle des écrans.
Daniel: Je crois que je comprend ce qui se passe chez nous. On a arrêté d’estimer seulement la taille des scénarios, et on a introduit dans l’estimation nos difficultés à les réaliser.
Charles: D’où le fait que votre vélocité augmentait artificiellement…
Daniel: …jusqu’au plongeon.
Charles: Bon réveil!

Daniel: Il y a quand même un truc qui ne va pas dans cette façon d’estimer..
Charles: Sûrement. Tout ceux qui l’ont adopté ont d’abord rencontré des problèmes et des réticences.
Daniel: Comment prendre en compte les tâches purement techniques dans le planning game, comme par exemple, installer des outils ou faire un gros refactoring ?
Charles: A la fin des estimations, on se pose la question de l’engagement: “combien de scénarios pouvons-nous embarquer dans cette itération ?” Les développeurs peuvent dire : “dans l’itération précédente notre vélocité était de 25, on pourrait donc théoriquement réaliser tous les scénarios estimés, mais vu qu’on a des outils à installer et un gros refactoring à faire, on ne les produira pas tous.”
Daniel: Et si le client insiste pour les avoir tous ?
Charles: Il peut le vouloir mais ce n’est pas forcément ce qui arrivera. Il faut peut être négocier…
Daniel: …mais au moins on négocie le périmètre par rapport à ce que doit faire l’équipe, et non la complexité des scénarios.
Charles: Tu as tout compris. C’est la différence entre engagement et estimation.
Daniel: Laisse, la bière est pour moi.
Charles: Puisque tu insistes!

Suggestion d'articles :

1. Domain Driven Design : des armes pour affronter la complexité
2. 5 minutes pour : Monter en complexité, Approche TDD / Tests en PHP, PHP & Ajax

« Et après avoir enregistré la livraison, on voit que le stock du produit… n’est pas mis à jour… »

Une application pas assez stabilisée, des scénarios déroulés de manière trop hasardeuse, un démonstrateur peu familier de l’application… l’ »effet démo » devrait alors être rapidement invoqué pour justifier les comportements inattendus et autres « stacktraces » présentés à l’écran devant un auditoire au mieux interloqué, au pire moqueur.

Pourtant, cet effet et les moments de solitude qui en découlent peuvent être maîtrisés avec peu de préparation. Au travers d’un cas réel, nous vous proposons dans cet article de parcourir les principales astuces vous permettant de sécuriser une démonstration et de combattre l’effet démo qui, un peu à la manière du « Plouf« , s’instille sournoisement dans les habitudes d’une équipe. Le cas pris pour exemple de cet article est un projet mené sur un mode « Scrum ». Cependant, le principe de la démo reste valable hors de ce contexte.

Vous trouverez en pièce jointe une checklist synthétisant les vérifications à faire afin de mettre toutes les chances de votre côté.

Le besoin

Temps fort d’un projet informatique (Scrum en particulier), la démonstration rassemble, pour quelques heures, l’ensemble des acteurs du projet autour de la même table et permet de partager le travail effectué. Il s’agit d’un moment privilégié à ne pas rater et, ce, dans tous les sens du terme :

• Au sens de la participation tout d’abord : reconnaissance du travail de l’équipe et entretien du lien avec les équipes délocalisées
• …mais aussi et surtout au sens de la réalisation : en effet, à ce moment du projet, l’application était en pleine construction. Sécuriser les démonstrations devenait nécessaire car :
  • La succession de démonstrations chaotiques depuis plusieurs sprints…
  • …entraînait un manque de visibilité sur l’avancement…
  • …entraînant à son tour une perte de confiance du « Product Owner » et du management…
  • …ainsi qu’une lassitude des équipes de développement

Le besoin était donc de rassurer l’ensemble des acteurs sur le projet et montrer clairement ce qui fonctionnait.

Que montrer ?

Il est courant, au début d’un projet, d’avoir le sentiment de ne rien pouvoir montrer. Mise en place du « socle technique », montée en compétences sur le métier et les différents outils… les raisons sont souvent nombreuses pour justifier l’absence de matière concrète.

D’autre part, les cas d’utilisation des applications de gestion requièrent parfois peu d’interaction avec l’utilisateur, rendant l’exercice de démonstration d’histoires moins… démonstratif.

Dans ce cas, on pourra se tourner vers la présentation de pages de tests exécutables telles que FitNesse ou GreenPepper.  Au-delà de l’aspect tests, ces outils ont l’avantage de rendre visible le fonctionnement de code sans IHM. Dans un premier temps, des pages concernant des briques « techniques » telles que, classiquement, les couches DAO, pourront convenir.

Une fois le rythme de croisière atteint, la construction du contenu de la démo se fait à partir du Jira du projet (ou autre backlog). Sur notre projet exemple, nous nous basions sur les stories validées au cours du sprint voire, si elles étaient suffisamment stables, sur les stories non validées mais terminées. Nous nous assurions cependant que, dans le cadre des scénarios envisagés, elles étaient valides !

La préparation

Contenu des scénarios

Les stories/fonctionnalités sélectionnées sont ensuite instanciées afin de donner naissance à des scénarios proches d’une histoire réelle. Ces scénarios sont de préférence organisés de manière logique pour le sponsor du projet (par exemple, référencer un produit avant de le vendre !).

Une fois les scénarios décidés, ils doivent être écrits afin de laisser place le moins possible à l’improvisation le jour de la démo. Ils seront « relativement détaillés« , le niveau de détail dépendant de la confiance dans l’application. De très détaillés pour les fonctionnalités délicates et/ou nouvelles (ex : « Saisir 12 POINT 34 dans le prix de vente du produit »), ils pourront devenir assez sommaires pour des fonctionnalités de base d’un projet avancé et stable (ex : « Créer une commande de deux produits »). Ne pas hésiter non plus à identifier clairement les pièges connus (ex : « Ne PAS cliquer sur ‘OK’ »)…

Rôle du « Responsable de démo »

La multiplication des équipes fait que, naturellement, plusieurs personnes peuvent être amenées à présenter. Dans une situation « de crise » telle que celle subie par notre projet exemple, les premières démonstrations ont été prises en charge par une seule personne, le temps que les présentations se rationnalisent. Cela a permis de mettre en place le process avant réappropriation complète par le client. Ce « responsable de démo » se charge alors de dérouler les scénarios et prend en charge la préparation de la démo à l’aide de la checklist attachée à cet article

Impacts des déploiements automatiques

Nous avons parfois terminé le lundi soir en ayant déroulé et enchaîné avec succès les scénarios mais, le mardi matin, les comportements étaient tout différent… Cela était dû aux déploiements automatiques qui avaient mis à jour l’environnement sur lequel la démonstration allait être effectuée. Ils avaient été oubliés dans l’excitation de la préparation ! Tirez-donc parti de nos oublis et pensez aux tâches automatiques :)

Le déroulement

A ce stade, le contenu de la démo est figé et les acteurs connaissent leur texte ! Il n’est plus envisageable d’ajouter un dernier scénario qui aurait été terminé tard le soir précédent…

Impliquer les équipes délocalisées

Faire participer l’ensemble des équipes à la démonstration est important ; l’exercice est un peu plus complexe lorsqu’on travaille avec des équipes délocalisées. Nous avons utilisé deux outils pour maintenir le lien avec les équipes situées en Europe de l’Est et en Asie : Skype pour l’audio et Mikogo pour le partage d’écran. Cela permet de partager les manipulations du démonstrateur. Attention, cependant, à la réactivité de la connexion réseau qui peut conduire à une démonstration illisible pour vos correspondants !

Respecter les scénarios !

Dans l’euphorie de la présentation, l’improvisation peut prendre le dessus. La démarche peut sembler très scolaire, mais s’astreindre à suivre ligne à ligne chaque étape du scénario et à indiquer chacune comme étant réalisée évite de solliciter des fonctionnalités non prévues de l’application (et donc de faire émerger des bugs potentiels). Réaliser la démonstration à deux (l’un présente, l’autre contrôle) sécurise également le bon déroulement du scénario. On perd bien sûr en spontanéité, mais sur notre projet exemple, l’utilisation d’un déroulement aussi contraint n’a pas duré plus de deux ou trois démonstrations. La stabilité de l’application et la maturité des démonstrateurs augmentant avec le temps, nous avons progressivement allégé le process.

Un exercice de communication

La démonstration est un exercice de communication : ne pas hésiter à expliquer le fonctionnel en illustrant de use cases de la vraie vie, car toutes les personnes du projet ne connaissent pas forcément le domaine/vocabulaire de tous les composants de l’application. Ne pas hésiter non plus à masquer les détails techniques : ils pourront être abordés si des questions en offrent l’occasion.

A ce titre, on respectera également les règles relatives à toute présentation en public :

• limitation du nombre de démonstrateurs : 2 ou 3
• s’assurer que tout le monde voit les manipulations du démonstrateur et l’entend : mouvement de souris lents et connexion avec les équipes délocalisées notamment
• énoncer l’histoire avant de dérouler le scénario permet à l’auditoire de comprendre
• rythme et temps passé
• etc

Impacts et effets collatéraux

Dans des projets possédant plusieurs équipes dédiées à des composants distincts, c’est un très bon moyen d’améliorer la connaissance de tous les acteurs projets sur les aspects fonctionnels du produit. Même sans savoir comment en mesurer l’impact immédiat sur le projet, on peut sans trop de mal imaginer qu’on est plus à même de prendre des décisions adéquates lorsqu’on possède une meilleure connaissance de son environnement !

Même si cet article a pris pour exemple un projet Scrum, la réalisation d’une démo régulière et les lignes directrices de sa préparation présentées ci-dessus ne sont bien sûr pas spécifiques au mode Scrum ! Vos équipes, votre sponsor ne pourront vous être que reconnaissants de présenter leur produit !

Dissocier démo et fin de sprint ?

Nous avions choisi de suspendre les déploiements automatiques de l’environnement de développement pour éviter des éventuelles régressions. Mesure radicale, au grand dam des testeurs qui se retrouvaient ainsi presque 24h sans voir l’application évoluer.

On peut imaginer d’un autre côté dissocier démo et fin de sprint : en faisant une image de l’environnement de développement à la fin du sprint pour la transférer sur un environnement de démo, il serait inutile alors de geler l’environnement de dev le temps de la démo.

Avez-vous pu expérimenter cela dans vos équipes ? Quel(s) retour(s) en avez-vous retiré ?

En conclusion, une démonstration réussie n’aura que des bénéfices sur le projet. Dans le cas du projet pris comme exemple pour cet article :

• L’état du projet a été visible de tous : chacun a pu voir ce qui fonctionnait
• Le product owner était rassuré sur le contenu fonctionnel du projet
• L’émulation créée a été sensible immédiatement
• Chacun a pu faire reconnaître son travail publiquement par l’équipe

Enfin, même si cet article a pris pour exemple un projet Scrum, la réalisation d’une démo régulière et les lignes directrices de sa préparation  présentées ci-dessus ne sont bien sûr pas spécifiques au mode Scrum ! Vos équipes, vos sponsors ne pourront vous être que reconnaissant de présenter leur produit.

Suggestion d'articles :

1. Animer des rétrospectives d’itération

L’Agile est aujourd’hui un outil puissant d’amélioration de la qualité des produits et de la satisfaction des acteurs, utilisateurs comme artisans du système d’information.

Si la méthode commence à être connue, sa mise en œuvre peut néanmoins se heurter à des difficultés, notamment sur le volet contractuel.

Ainsi, dans les organisations où les pratiques d’achats reposent sur une définition exhaustive des besoins (i.e. cahier des charges) et une obligation de résultat portant sur un périmètre figé et qui ne peut évoluer qu’à l’aide d’avenants, il est souvent difficile voire impossible de concilier ces pratiques avec les principes fondamentaux de l’Agile à savoir : autoriser le changement, affiner et spécifier les fonctionnalités au fil de l’avancement du projet pour répondre mieux aux besoins des utilisateurs.

Alors que faire ? Comment concilier des principes d’achats bien rodés mais a priori antagonistes avec les principes de projet Agile ? Peut-on faire évoluer ces principes ? Chez OCTO, nous avons la conviction qu’il existe des moyens d’y parvenir en respectant les contraintes et les enjeux de votre entreprise.

Nous vous proposons d’échanger avec vous sur ce thème et pourquoi pas vous accompagner dans un travail en profondeur sur vos pratiques d’achats et de contractualisation.

Pour commencer nos échanges, nous offrons 2 séances de travail de 2h gratuites au 3 premières entreprises qui nous contacteront.

Contactez-moi pour cela sur ymartel@octo.com et travaillons ensemble à améliorer un peu plus votre ingénierie informatique!

Suggestion d'articles :

1. Contractualisation Agile
2. Comment mieux prioriser en projet agile
3. Quels sont les types de tests que l’on utilise sur un projet agile ?