Au sommaire de notre brochureVous trouverez dans cette brochure des éléments clés sur l’agilité quitémoignent de nos compétences sur le sujet.

page> L’édito . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2> Mon projet est-il vraiment AGILE ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4> DevOps - le mouvement qui tend à «Agili�er» votre DSI . . . . . . . 9> Lean Startup (des Patterns des géants du Web) . . . . . . . . . . . . . . .12> Déployer l’agile à large échelle, c’est jouer sur les frontières

de l’entreprise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16> 7 conseils pour entamer une transformation agile . . . . . . . . . . . . .22> Les événements OCTO Technology à Genève . . . . . . . . . . . . . . . . 25

édiTopar Joseph GlorieuxDirecteur GénéralOCTO Technology(Suisse)

Nous mettons notre expertise

Agile à votre disposition

pour vous accompagnerdans votre transition

Fervents partisans des méthodes agiles depuis 2006, nous croyons ferme-ment, chez OCTO Technology, à la nécessité d’adapter nos méthodes de déve-loppement informatique à cette méthodologie.

L’agilité n’est plus aujourd’hui l’appanage de quelques startups ou entreprisesde la Silicon Valley, c’est une transition nécessaire à la survie sur le long termedes départements informatiques.

Nous vous faisons parvenir aujourd’hui dans cette brochue une compilationde quelques-uns de nos articles sur ce sujet pour vous présenter notre expérienceet vous con�rmer notre volonté de vous acccompagner dans cette transition.

L’agilité en profondeurTout d’abord, être agile, c’est quoi ?

Le fait est qu’il ne suf�t pas de travailler par itérations de quelques semainesou de discuter tous les matins en restant debout pour adresser les dif�cultés fon-damentales des développements informatiques. Au contraire, adopter l’Agilitéc’est embrasser le changement à la racine de son savoir faire technique. Les chan-gements sont nombreux mais les plus essentiels sont en dé�nitive assez simplesà appréhender :

Tout d’abord, il n’est pas possible de pleinement déployer l’Agilité sur un pro-jet, moins encore d’en ressentir les béné�ces, sans une adoption à large échelledes principes XP.Dans le détail, une usine logicielle, des tests automatisés, la qualité du code sanscompromis (refactoring, règle des 4 yeux, etc.) ainsi que l’intégration automatiséeet continue, idéalement jusqu’en pré-production, sont indispensables.

La nature des relations avec le commanditaire, le métier et ses représentantsainsi que leur implication dans le cycle de développement du logiciel doit évo-luer.

Il n’y a plus de place pour une relation formelle mandataire - mandaté. Aucontraire, le métier et l’IT doivent travailler main dans la main. L’IT se met à nudevant le métier, se montre honnête et transparente. Le métier quant à lui doitréaliser qu’il doit s’impliquer profondément dans le développement du logiciel.Chaque heure investie à l’échelle du quotidien avec l’équipe projet par un repré-sentant du métier permettra d’économiser des jours de tests d’acceptance, dereproduction de bug ou encore perdus à cause de l’indisponibilité du systèmeou simplement de son mauvais fonctionnement.

Page 2 / 30

Un changement clé pour la transformationdigitale

La transformation agile est aujourd’hui un facteur essentiel de réussite à latransformation digitale de l’entreprise.

En effet, si le modèle et la position de l’informatique dans l’entreprise et dansla société en général n’a pas beaucoup évolué pendant ces vingt dernières an-nées, nous sommes aujourd’hui à l’aube d’une véritable révolution : la révolutiondigitale.

Les entreprises pour lesquelles l’informatique ne vas pas devenir le premiervecteur d’innovation et la pierre angulaire de leur modèle d’affaire au cours desdix prochaines années existent, bien sûr, mais elles sont très peu nombreuses.

Or la transformation digitale des entreprises repose sur quelques prérequisqu’il est impossible de court-circuiter. La transformation agile du départementinformatique en fait bien évidemment partie, ainsi que l’adoption des principesDevOps et Lean Startup.

Nos atouts pour vous accompagnerEn Suisse, l’accompagnement des entreprises sur le thème de la transforma-

tion agile représente près de 30% de notre chiffre d’affaire. Nous travaillons surce sujet pour tout type d’entreprise, des startups aux multi-nationales. Nous nousréjouissons de vous rencontrer au prochain événement que nous organisons surce sujet.

Page 3 / 30

Mon projet est-il

vraiment AGILE?

publié sur

Que la réponse soit «Bien-sûr !» ou «Honnêtement, je n’en sais rien.»,se poser cette question est un excellent exercice !

Une équipe qui a choisi l’Agile a toujours la possibilité d’apprendre et des’améliorer quel que soit son niveau de maturité : comprendre comment unbug a pu perdurer jusqu’à la démonstration client, réussir ses rétrospectivesd’itérations et enmesurer le béné�ce, etc. Les sujets peuvent être nombreuxet leur résolution d’autant plus satisfaisante !

En cherchant à améliorer certains rituels agiles sur des projets de deli-very mobile, nous sommes parvenus à compiler toutes les pratiques et outilsindispensables à nos projets Scrum. Nous en avons fait un document deme-sure et de suivi sur nos missions et nous souhaitons les partager ci-dessous :notre checklist d’un projet agile.

Pourquoi mesurer l’agilité sur mon projet ?

Il s’agit d’une démarche d’améliorationcontinue.

Au-delà de savoir si nos projets étaientagiles, notre volonté était d’améliorer nos pra-tiques. Et pour améliorer, il faut mesurer. D’oùl’idée de lister les points de méthodes appli-quables concrètement dans nos missions.

La réalisation de ce travail nous a permisde partager nos expériences, nos outils et deles condenser sous une forme accessible etutilisable par tous. Le résultat est un ensemble

de points qu’il est possible d’utiliser pour for-mer de nouveaux intervenants sur un projetagile, partager la connaissance et en�n s’amé-liorer en continu !

Si beaucoup de rituels agiles issusde Scrum nous semblaient indispensables,d’autres outils venus notamment du Leannous sont apparus tout aussi pertinents. Nousles avons donc incorporés et pensons qu’ilspeuvent être complétés par d’autres.

Une checklist pour mon projet !

Et ça marche ?Après 4 mois d’utilisation de notre ques-

tionnaire, nous sommes parvenus à réduirecertaines douleurs que nous observions de

manière systématique dans nos missions.Notre vision de la façon d’utiliser l’Agile a étérenforcée et chacun est plus à même d’ac-compagner une équipe, mais également unclient pour que son projet réussisse au mieux !

Copiez les deux pages suivantes et servez-vous en comme checklist pour vos prochaines rétrospectives→

Page 4 / 30

Rituels Agiles

Stand up

Point quotidien de l’équipe.

k Un standup quotidien est réalisé à heure�xe

k Les interventions aux standup sont limi-tées à 1 minute par personne (la réunionreste courte)

k Chaque participant s’adresse aux autresmembres de l’équipe (et pas à un leaderunique)

Rétrospective d’itération

Retour sur l’itération, sur le process, les rela-tions etc. dans une démarche d’améliorationcontinue

k Avant le démarrage d’une itération, unerétrospective est réalisée sur l’itérationprécédente

k En début de rétrospective, les actionsdécidées à la dernière rétrospective sontrevues

k Toute l’équipe de développement, ledelivery manager et le PO sont présentsà la rétrospective

k Chacun arrive à exprimer des points dif-�ciles du projet

k Des solutions concrêtes sont trouvéespour résoudre les points dif�ciles et desacteurs sont identi�és pour les mettre enoeuvre

k La rétrospective a un facilitateur désignéqui l’anime. Le facilitateur ne contribuepas au contenu

Démonstration de �n d’itération

k En �n d’itération, une démonstration duproduit est présentée au Product Owner(PO)

k Les démonstrations sont préparées àl’avance (véri�cation préalable de cha-cune des stories)

Bilan de �n d’itération

Retour du client sur chaque story dévelop-pée

k Lors du bilan, le PO valide/invalide cha-cune des stories développées

k Lors du bilan, les métriques du projet(vélocité, avancement, etc.) sont présen-tées

Planning game (plani�cation de l’itéra-tion)

Planning game : choix, priorisation et esti-mation en complexité des stories

k Le PO sélectionne les stories à estimerpour l’itération et les présente à l’équipe

k Le PO associe des tests de validation àchacune des stories

k Un planning poker est réalisé avec toutel’équipe pour estimer les stories

k Le nombre de stories à développer paritération est choisi en fonction de la vé-locité de l’équipe (somme des points decomplexité validés dans l’itération pré-cédente)

k A la �n du planning game, les storiessont priorisées

MéthodologieTenue de backlog

Plani�cation des itérations

k L’équipe de développement et le POpartagent le même document listant lesfonctionnalités de l’application (Backlog)

k Les fonctionnalités à développer sont ré-

digées sous la forme de User stories (ex :« en tant que ..., je peux ...»)

k Les fonctionnalités sont rattachées à laStoryMap du projet s’il y en a une

k Apartir du Backlog, on peut retrouver lestests de recette associés à chaque story

Page 5 / 30

Management visuel partagé

La salle projet re�ète l’état du projet

k L’équipe utilise un support visuel pourorganiser les stories (Kanban board)

k Les différentes colonnes du Kanban sontclairement séparées et une « De�ni-tion Of Done » (DOD) est dé�nie pourchaque colonne

k Les DOD sont respectées par chaquemembre de l’équipe

k L’équipe utilise un bac rouge pour ré-férencer et traiter les problèmes liés au

projetk Le bac rouge est traité régulièrement

(application par exemple de la méthode« 5 pourquoi »)

k Les informations complémentaires im-portantes du projet (prochaines dates derelease, contenu de ces releases, burn-down chart, planning d’itération, tro-phées, etc.) sont af�chées

k Chaque itération a un objectif qui est af-�ché (au dessus du Kanban)

Bonnes pratiquesDéveloppement organisé

L’équipe organise son travail

k Les stories sont développées dansl’ordre de priorité dé�ni par le PO enplanning game

Industrialisation des développements

Les processus de développement/livraisonsont industrialisés

k Le projet utilise une Usine De Dévelop-pement (UDD) pour l’intégration conti-nue (build, lancement des tests, véri�ca-tion qualité)

k La livraison au client est réalisée grâce àl’UDD

k La livraison est réalisée en suivant unechecklist

Méthodes de développement

L’équipe utilise des pratiques permettant des’améliorer

k L’équipe réalise les stories les plus dif�-ciles en Pair Programming

k Tout code est validé par un autremembre de l’équipe (correction, aligne-ment des pratiques)

k Les fonctionnalités de l’application sonttestées unitairement et automatique-ment

k L’équipe développe en Test Driven De-velopment (TDD)

k Le projet possède un document avec sesnormes (page wiki, feuille au mur, �chierreadme, autre), de préférence de ma-nière visuelle

CommunicationVie de l’équipe et relation client

Comment se sentent les membres del’équipe

k L’équipe s’améliore de façon continuek L’équipe a la con�ance du client

k La communication dans l’équipe et avecle client est facile / bonne

k L’équipe favorise la colocalisation (tousles acteurs du projet sont colocalisés)

Page 6 / 30

Et du coup, il est agile mon projet ?

Avoir un outil à sa disposition n’est quele premier pas ! Il faut encore l’adapter à soncontexte, que son équipe l’accepte et en�nsavoir analyser ses résultats !

Adapter ses outils à son besoinCertains des points présentés ne corres-

pondent certainement pas à tous les pro-jets et d’autres peuvent manquer. Un conseilque nous pourrions donner avant d’ajouter(ou retirer) un élément de la liste est de s’as-surer que cet élément fait l’unanimité dansl’équipe.

N’hésitez pas à y ajouter vos stan-dards (meilleures pratiques observables survos missions). Une bonne communication etune formulation pédagogique des questionssont également nécessaires pour maximiserl’adhésion de chaque participant.

Visualiser et analyser ses résul-tats

Mesurer régulièrement sa pratique agilepermet d’en suivre l’évolution et d’analyser ra-pidement les bienfaits d’une pratique.

Véri�er la checklist par exemple tous lesmois permet de mettre en évidence les résul-tats des actions d’amélioration entrepris parun groupe.

Un(e) responsable pourra être choisi(e)pour analyser les réponses des participants duprojet.

De plus, il est intéressant que ce question-naire soit rempli par chaque membre l’équipe

a�n d’obtenir le point de vue de chacun.Cela fera éventuellement apparaître des

divergences d’opinion qui pourront valoir lapeine d’être discutées pour améliorer la visioncommune dans le groupe.

A�n de mieux visualiser les résultats et deles comparer dans le temps, nous avons crééun excel qui convertit notre Google Form entableau récapitulatif et qui simpli�e grande-ment notre analyse (voir tableau en page 8)

Echanger avec son équipeEn�n, une fois l’analyse effectuée, se

réunir régulièrement permet de présenterles résultats. C’est l’occasion d’échanger, decomprendre les dif�cultés de chacun et dechoisir des points que l’on souhaite amélio-rer ou suivre avec une attention particulière.C’est aussi à ce moment que l’on peut choisird’ajouter une nouvelle pratique observée ouencore d’arrêter d’utiliser la checklist (« On esttrop forts ! »).

Un dernier conseil pour que cette checklist reste une pratique ef�cace : ne pas l’impo-ser comme outil d’évaluation de performancemais plutôt la proposer comme base de ré-�exion à des équipes motivées par l’amélio-ration de leur quotidien.

Page 7 / 30

Accéder à cet article en ligne ...

http://goo.gl/4v3uth

DevOps

le mouvement qui tend à«Agili�er» votre DSI

publié sur

La communauté « DevOps » nousinvite à repenser la frontière classiquede nos organisation, séparant :> d’un côté les études, i.e. ceux qui

écrivent le code (le «Build») et> de l’autre côté la production, i.e.

ceux qui déploient et exploitentces applications (le «Run»).

Pourquoi DevOps ?

Deux groupes se retrouvent dans le mou-vement DevOps et apportent un peu de frai-cheur dans ces ré�exions aussi anciennes queles DSIs :> Les agilistes qui ont levé la «contrainte»

côté développement et sont maintenantcapable de «livrer» beaucoup plus sou-vent du logiciel valorisé par le client. . .mais regrettent que «la prod ne suive pas»

> Des experts ou desmanagers de la «prod»des géants du web (Amazon, Facebook,LinkedIn, etc.) partageant leurs retoursd’expérience sur leur façon d’envisagercette frontièreAu delà des fractures organisationnelles,

les préoccupations des études et de la pro-duction sont bien distinctes et respectivementlouables.

Les études recherchent plus de réacti-vité (sous la pression du métier et du mar-ché notamment) : il faut aller vite, ajouterde nouvelles fonctionnalités, réadapter les di-rections, refactorer, upgrader les frameworks,déployer rapidement pour tester. La naturemême du code («Soft») est celle-ci : maléable,adaptable.

A l’inverse, la production a besoin de sta-bilité et de standardisation.

> Stabilité car il est souvent dif�cile d’anti-ciper quels impacts auront telles modi�-cations de l’infrastructure : un disque lo-cal qui devient un disque réseau mais im-pacte les temps de réponses, ou encoreun changement de code qui impacte for-tement la consommation CPU et par lamême le «capacity planning».

Page 9 / 30

> Standardisation en�n car la productionveut s’assurer que certaines règles (sécu-

rité réseaux, con�guration des �chiers delogs, etc.) sont uniformément respectées.

Un objectif commun

Malgré ces contraintes divergentes, cesdeux groupes ont un objectif commun : fairefonctionner le système. Finalement, le dé-ploiement n’est pas le plus important danscette problématique même si c’est certaine-ment une des activités les plus consomma-trices en ressource : la moitié du temps dela production est ainsi consommée par le dé-ploiement ou des problèmes liés au déploie-ment.

C’est donc certainement le premier levierd’amélioration mais non l’unique. Damon Ed-wards et John Allspaw nous rappellent :> qu’il s’agit de partager des métriques

et d’être capable de transformer desvariables techniques (augmentation destemps de réponse, etc.) en variables bu-siness (baisse du CA généré, etc.). Etqu’une des clés du succès d’interprétationde cesmétriques est la collaboration entreles études (la compréhension du code) etla production (la compréhension des ser-veurs, du réseau, etc.)

> «qu’agili�er» le processus de développe-ment c’est bien mais que le véritable en-jeu c’est l’agilité « business » qui passe parla réduction du délai global «from conceptto cash», de l’idée à la mise au produc-tion. Cela passera entre autres par des dé-ploiements plus «agiles», sur l’exemple deFlickr, qui réalise 10 déploiements quoti-diens

Page 10 / 30

Améliorer la collaboration

Atteindre cet objectif ne se fera pas sansdouleur et trouve des leviers d’améliorationdans 4 axes :

> de l’outillage qui permettra d’industriali-ser l’infrastructure et de rassurer la pro-duction sur la façon dont cette infrastruc-ture est utilisée par les études. C’est undes gènes du cloud : le self service. Lesoffres de cloud public sont matures sur lesujet mais certaines offres (VMWare parexemple) visent à reproduire ces modesde fonctionnement en interne. Mais sansforcément aller à ces niveaux de maturité,nous pouvons considérer l’utilisation d’ou-tils type Puppet, Chef ou CFEngine.

> de l’architecture qui peut permettre dedécorréler les cycles de déploiements, dedéployer du code sans pour autant mettrela fonctionnalité à disposition des utilisa-

teurs.> de l’organisationnel qui vous amènera

peut-être, vous aussi, à implémenter lespatterns d’Amazon «two pizzas team» et«you build it, you run it»

> du processus qui permettra de �uidi-�er tous ces échanges. Comment dé-ployer plus souvent ? Comment limiter sesrisques en déployant progressivement ?Comment appliquer les leçons de « �ux »tirées de Kanban à la production ? Com-ment repenser les mécanismes de com-munication et de coordination à l’œuvresur la frontière études/production ?En dé�nitive ces 4 axes nous permettront

d’atteindre les objectifs supérieurs de De-vOps : améliorer la collaboration, la con�anceet l’alignement d’objectifs entre les études etla production.

Accéder à cet article en ligne ...

http://goo.gl/QwusM2

"DevOps, de l’intégration continue audéploiement continu"

http://goo.gl/Ot1NtT

Lean Startup

(des Patterns des géants duWeb)

publié sur

La création d’un produit est très sou-vent vouée à l’échec. Ainsi, les chiffresmontrent que 95% des produits ou startupsmeurent par manque de clients.

Le Lean Startup est une approche decréation produit qui se propose de réduireles risques d’échec en attaquant parallèle-ment les aspects organisationnels, businesset techniques et cela avec des itérationsagressives. Formalisée par Eric Ries, elle estfortement inspirée du Customer Develop-ment de Steve Blank..

Les principes Lean Startup

Build – Mesure – LearnTout produit ou fonctionnalité part d’une

hypothèse. Cette hypothèse peut être issuede données récoltées sur le terrain ou d’unesimple intuition.

Toujours est-il que l’approche que prônele Lean Startup est :

1. De considérer toute idée comme hypo-thèse, qu’elle soit marketing ou fonc-tionnelle,

2. De valider toute hypothèse le plus vitepossible sur le terrain.

Ce dernier point est l’un des élémentscentraux du Lean Startup. Chaque hypothèse− business, organisationnelle ou technique −doit être validée qualitativement et véri�éequantitativement. Cette démarche permet demettre en place une boucle d’apprentissagesur le produit et le client. Le Lean Startup com-bat donc l’approche qui consiste à construireun produit pendant un an et se rendre comptetardivement que des choix (marketing, fonc-tionnel, commercial) mettent l’organisation endanger. Il faut tester tout de suite et au plusvite.

Page 12 / 30

Expérimenter pour ValiderUne partie de

l’approche se basesur leMinimumViableProduct. Quel estl’ensemble minimalde fonctionnalitésque je dois construirepour valider meshypothèses ?

On ne parle pasici nécessairement decode et de produitau sens techniquedu terme, mais den’importe quel effortqui va permettred’avancer sur ceshypothèses.

Cela peut être un questionnaire GoogleDocs, une mailing list ou une fausse fonction-nalité pour tester l’appétence du marché.

L’expérimentation et les leçons associéessont un actif inestimable pour le pilotage duproduit et justi�ent la mise en place de laboucle d’apprentissage.

L’obsession de la mesureOn imagine donc bien que ces expé-

rimentations doivent systématiquement êtresuivies par une mesure �able et complète.

Une approche centrée client – Goout of the building

Véri�er qualitativement et valider quanti-tativement signi�e bien souvent « sortir del’immeuble », comme dirait Bob Dorf, co-auteur du fameux 4 Steps to the Epiphany.

«Go out of the building» (GOOB) est aucentre des préoccupations des Product Ma-nagers pratiquant le Lean Startup. Tant queles hypothèses ne sont pas confrontées à laréalité, elles restent des suppositions. Et doncdes risques potentiels pour l’organisation.

«No plan resist �rst contact with custo-mers» (Steve Blank) est ainsi l’une des devisesdes équipes produit :> Construire le minimum nécessaire à vali-

der une hypothèse ;> GOOB (de l’interview en face à face au dé-

ploiement continu) ;> Apprendre ;> Construire et ainsi de suite.

Cette approche permet ainsi de resterconstamment au contact du client, et doncde valider les hypothèses business (les dol-lars). Zappos, géant US de la chaussure sur leWeb, est un exemple de MVP mis entre lesmains des utilisateurs réels très tôt. Pour seconfronter à la réalité et valider que les uti-lisateurs seraient prêts à acheter des chaus-sures en ligne, le futur CEO de Zappos photo-graphia les chaussures des magasins locaux,créant l’inventaire d’un site e-commerce detoute pièce. Ce faisant, et sans construire unecathédrale, il valida très tôt que la demandeexistait et que la construction d’un tel produitpouvait s’avérer gagnante.

Le pilotage par la donnéeEvidemment, pour apprendre du compor-

tement des utilisateurs lors de ces sessions deGOOB, les Product Managers récoltent méti-culeusement de la donnée qui leur permet deprendre les décisions adéquates.

Page 13 / 30

Ils mettent évidemment au préalable enplace les outils et processus de récolte decette donnée.Les plus utilisées sont bien connues de tous. Ils’agit d’interviews et des solutions d’analytics.

Ce que le Lean Startup prône est une uti-lisation féroce de ces indicateurs pour réelle-ment piloter la stratégie produit.

Sur ChooseYourBoss.com, nous avons faitcomme hypothèse que les utilisateurs utilise-raient LinkedIn ou Viadeo pour se connecter,a�n de leur éviter de se créer un compte etpour nous éviter de développer un systèmed’inscription.Nous avons donc construit le minimum pourinvalider ou valider l’hypothèse : une page quicomportait les trois options, à savoir l’inscrip-tion via Linkedin, celle par Viadeo et celle parun compte ChooseYourBoss.Les deux premières fonctionnaient réelle-ment, le compte ChooseYourBoss indiquaitque le compte ChooseYourBoss n’était pasencore disponible en production.

Résultats : les utilisateurs ne voulant pasutiliser ces réseaux pour se connecter repré-sentent 11% de nos visiteurs. Nous n’implé-menterons donc pas dans l’immédiat la créa-tion de compte sans réseau. Nous sommespassés du « informés par la donnée » au « pi-lotés par la donnée ».

Chez qui ça fonctionne ?

Strator, Viadeo, Spotify, Couldwatt, Zap-pos et bien d’autres sont autant de socié-tés ou produits Web qui ont réussi à intégrerles feedbacks utilisateurs au plus tôt dans lacréation de produit. Dropbox a, par exemple,changé complètement son fonctionnement

en simpli�ant drastiquement la gestion desdossiers synchronisés. Heroku est passé d’uneplateforme de développement sur le cloud àune solution d’hébergement sur le cloud. Lesexemples sont nombreux et plus ingénieux lesuns que les autres !

Page 14 / 30

Et chez vous ?Le Lean Startup n’est pas dogmatique.

C’est avant tout prendre conscience que lemarché et le client ne sont pas dans lesréunions d’architecture, les plans marketing,les projections de ventes ou les fonctionnali-tés clés.

Une fois ce constat fait, vous verrez des hy-pothèses partout. Tout consiste à mettre enplace une discipline de validation des hypo-thèses en gardant pour principe de valider leminimum de fonctionnalités à un instant "t".

Avant de faire la moindre ligne de code,les principales questions à se poser tournentautour du triplet Client / Problème / Solution :

> Ai-je réellement un problème qui vaut lapeine d’être résolu ?

> Ma solution est-elle la bonne pour monclient ?

> Est-il susceptible de l’acheter ? A com-bien ?

Tous les moyens sont bons pour lever ceshypothèses : interviews, études de marché,maquettes, etc.

La seconde étape consiste à savoir si lemodèle que j’ai pu tester à moindre échelleest répétable et extensible. Comment mettreentre les mains des clients un produit dontils n’ont jamais entendu parler ? Vont-ils com-prendre, utiliser et tirer des béné�ces de mon

produit ?Les troisième et quatrième étapes

tournent autour de la croissance : commentfaire venir des clients et comment construireune société qui va pouvoir accueillir et fairegrandir mon produit.

Contrairement à ce que l’on pourrait pen-ser à la lecture de ce billet, le Lean Startupn’est pas une approche à réserver unique-ment à des sites Web grand public. Innoveren validant le plus rapidement possible deshypothèses et en limitant l’investissement �-nancier est évidemment une logique trans-posable à tout type de projet informatique,fût-il interne. Nous sommes convaincus quecette démarche mériterait d’être plus large-ment utilisée pour éviter les projets « Titanic »qui peuvent engouffrer des sommes considé-rables avec une très faible valeur perçue parl’utilisateur

Pour plus d’information, vous pouvezconsulter la session sur le Lean Startup lorsde l’USI 2012 qui traite des deux premièresétapes.

Retrouver toutes les pratiques desGéants du Web sur le site dédié(www.geantsduweb.com) : pdf de l’ouvrage àtélécharger, vidéo et compte-rendu de la pré-sentation « Décrypter les secrets des Géantsdu Web »

Accéder à cet article enligne ...

http://goo.gl/v4Jakj

"Youtube : USI 2012Lean Startup"

http://goo.gl/BKebya

"Les géants du Web"

www.geantsduweb.com

Déployer l’agile à largeéchelle

c’est jouer sur lesfrontières de l’entreprise

publié en février 2014 dans l’ (suisse)

Passées les premières expérimentations des méthodes agiles au seinde l’entreprise avec un succès que l’on va quali�er de variable, d’aucunsse posent la question de comment aller plus loin, voire comment envisagerune entreprise agile.

Nous sommes convaincus que déployer l’Agile à large échelle, c’estjouer sur les frontières de l’entreprise et nous allons justi�er cette positiondans cet article.

Tous les architectes techniques vous le diront, il existe deux types descalabilité quand on parle de serveur : la scalabilité verticale (augmenterles capacités du serveur) et horizontale (distribuer sur plusieurs serveurs). Ilpeut être intéressant d’utiliser cettemétaphore lorsque l’on parle de diffuserl’Agile plus largement.

La scalabilité verticale ou comment dépasser lesfrontières au sein d’un projet

Prenons le cas d’un projet où l’équipe dela DSI est en charge d’un développement enmode Agile. Cette équipe composée de 8personnes fonctionne bien et se pose la ques-tion de comment aller plus loin. Les pratiquesagiles supposent déjà d’améliorer l’environ-nement sur lequel on a la maîtrise et c’estune étape essentielle. Mais rapidement, onest confronté à d’autres frontières qui vont�nalement limiter les avantages de l’Agile àun périmètre restreint, ici, l’équipe projet. Ilest alors nécessaire de dépasser ces frontièrespour aller plus loin.> la frontière entre les études informatiques

et les gens du métier,> la frontière entre les études et la produc-

tion informatique,

> la frontière entre le métier et ses clients ouses utilisateurs.

Page 16 / 30

. Frontière étude vs métier

Développer un logiciel avec une équipeagile sans lemétier revient à construire un pro-duit de qualité en respectant un cycle en V enlivrant juste plus fréquemment. Pour pro�terréellement des promesses de l’Agile (qualité,adaptabilité et gestion du risque), la partici-pation du métier est indispensable. C’est enintroduisant des rôles (le product owner), despratiques agiles (les spéci�cations par les testscomme TDD) et en dé�nissant clairement lesdroits et devoirs de chacun (« vous pou-vez changer les priorités de développements,mais nous sommes en budget contraint etdonc certaines fonctionnalités devront sortirdu périmètre») que la frontière peut être gom-mée.

. Frontière étude vs production

Ensuite, développer un logiciel avec uneéquipe agile intégrant le métier sans la pro-duction revient à livrer fréquemment en envi-ronnement d’acceptance.

Le chemin est encore long vers un logi-ciel en production confronté à ses utilisateurs.C’est pourquoi l’envie de gommer cette fron-tière vient naturellement même s’il ne faut pasla prendre à la légère.

En effet, nos organisations ont passé ces20 dernières années à cloisonner ces deuxmondes. Beaucoup des solutions permettantde redé�nir cette frontière se cachent der-rière le terme « DevOps », qui regroupe despratiques touchant l’architecture, les outils, laméthodologie et l’organisation, visant à amé-liorer la collaboration entre les études et laproduction.

DevOps repose sur 3 principes clés quisont les garants d’une agilité allant jusqu’à laproduction :

> l’infrastructure « as » code,> le « continuous delivery »,> la culture de la collaboration.

. Frontière métier vs clients ouutilisateurs

En�n, développer un logiciel avec uneéquipe agile intégrant le métier et la pro-duction revient à livrer un produit bien exé-cuté mais pas forcément le bon produit. Lanuance se situe dans cette dernière frontièreoù la compréhension des hypothèses spéci-�ées par le métier peut être excellente tout enne correspondant �nalement pas aux attentesdes utilisateurs.

C’est dans certaines pratiques issues dumilieu des startups («lean startup» notam-ment) qu’une diminution de cette frontière estpossible. Ces approches s’échinent à décou-vrir simultanément les utilisateurs et le produita�n d’en assurer la convergence. Ainsi, sur labase d’hypothèses ou d’idées, on commenceà construire le produit que l’on va confronteraux utilisateurs a�n de se rassurer qualitati-vement et valider quantitativement les hypo-thèses dans des itérations courtes propices àl’apprentissage.

Ceci posé, notre équipe projet peut dé-passer ses frontières en projetant l’agilité surtout son cycle projet. Essayons à présent detransposer ces pratiques non pas à un projetmais à tous les projets de l’entreprise.

Page 17 / 30

La scalabilité horizontale ou comment dépasser lesfrontières d’un seul projet

Si réaliser les étapes précédentes sur unprojet représente déjà un challenge, l’opérerjusqu’à la gestion du portefeuille de projetest bien plus complexe mais c’est le cheminà suivre vers une entreprise agile en capacitéà accepter le changement et à s’améliorer encontinu. Les frontières en question, cette fois-ci, sont celles présentes entre chaque équipeprojet et entre les différentes strates de gou-vernance au-dessus de ces équipes. Gommer

ces frontières va revenir à opérer simultané-ment sur toutes les constituantes de l’entre-prise.

Nous proposons une lecture de ces mo-di�cations au travers des 5 piliers présentésci-dessous. Instruire une transition agile dansune entreprise revient donc à travailler surces 5 piliers en introduisant petit à petit lesconcepts jugés les plus pertinents.

Ces 5 piliers sont :

> les pratiques d’ingénie-rie logicielle,

> les processus,> l’organisation,> le « product manage-

ment »,> la culture d’entreprise.

. Les pratiques d’ingénierie logi-cielle

Ces pratiques ont déjà été évoquéeslorsque nous avons parlé de « DevOps » ouBDD. Il y en a bien d’autres pour la plupartintroduites via l’eXtreme Programming. Deuxchoses sont à retenir lorsque l’on parle d’agi-lité à large échelle. La première est que l’on atout intérêt à diffuser les meilleures pratiquesdans l’entreprise sans volonté de les imposerà tout prix. La deuxième est que certaines deces pratiques sont obligatoires à moins de su-bir une montée en pression issue des chan-

gements opérés dans les autres piliers (no-tamment l’accélération des cycles). Trois pra-tiques paraissent obligatoires :

> les tests automatisés : sans les tests au-tomatisés, le temps pour réaliser les testsaugmente d’incrément en incrément sansgarantir la non-régression,

> l’intégration continue : les probléma-tiques de « merge » notamment et d’in-tégration de toute sorte auront aussi ten-dance à nuire fortement à l’ef�cacité,

> l’investissement sur l’homme : mettre touten œuvre pour garantir l’expertise, la po-lyvalence et la curiosité de ses collabora-teurs.

Page 18 / 30

. Les processus

Quand on parle de processus autour de lagestion et du pilotage des projets, on les pré-sente généralement sur 3 niveaux, à savoir :

> la gestion de projet,> la gestion de programme,> la gestion de portefeuille.

Trois frameworks dits agiles (DAD, LeSS,SaFE) tentent aujourd’hui, à l’instar d’un PMIsur la gestion de projet en V, de fournirune description de ces processus. Aujourd’huiSaFE porte plus de promesses dès que l’on re-monte au niveau de la gestion de portefeuille.Qu’en est-il donc des processus dans ces 3 ni-veaux ?

Coté gestion de projet, rien de très neuf,le processus décrit par SCRUM est aujourd’huile plus couramment usité. On opère à la taillede la « user story » et on parle d’itérationde 2 semaines. Cependant d’autresméthodesexistent avec notamment « Kanban » issue du

Lean qui est plus dif�cile à digérer au démar-rage mais plus à même de gérer une problé-matique de �ux.

Coté gestion de programme, le processusest opéré à partir de la «roadmap» qui se dé-cline en «release», on parle de fonctionnalitésdu programme et une «release» regroupe plu-sieurs itérations de multiples équipes.

Les besoins de synchronisation sont évi-dents et sont adressés par la réunion des« product owner » de chaque équipe (assi-milable à du SCRUM de SCRUM) accompa-gnés d’un directeur de programme ou plutôt«product manager» et d’un super coordina-teur responsable du «release management».D’autres éléments de cohérence sont assurésà ce niveau via des rôles transversaux d’archi-tecte ou d’ergonome par exemple.

En�n coté gestion de portefeuille, il s’agit�nalement d’apporter des approches agilesau niveau des décideurs. On opère sur un por-tefeuille de projets a minima annuel où l’onpilote les investissements.

Page 19 / 30

La mise en place d’une gestion de por-tefeuille avec un processus en �ux de type« Kanban » peut permettre d’avoir une ap-proche où l’on limite l’encours, et permetaussi une re-priorisation bimestrielle tout enrestant dans un environnement contraint. Uneméthode de cadrage agressive (maximum 2mois) est un prérequis a�n de pouvoir statuerrapidement sur l’instruction ou non des pro-grammes.

Il ne semble �nalement pas y avoir derévolution par rapport aux processus ac-tuels. Cependant 3 éléments sont notables.D’abord cela démontre la capacité à opérerà large échelle avec une approche agile. En-suite la réduction des temps de cycle est pré-sente à chaque étage ce qui est en véritélourd d’impacts. En�n, les changements quipeuvent paraître anodins sont ampli�és parleurs interactions avec les autres piliers.

. L’organisationLes transformations potentielles à opérer

côté organisation sont fortement liées au pos-tulat suivant : une équipe projet comprendde 5 à 12 collaborateurs. La sociologie a dé-

montré qu’en dessous de 5 un groupe esttrop dépendant des absences et qu’il manquede créativité. Au-delà de 12 personnes, lesgroupes ont tendance à se diviser et l’ef�ca-cité chute brutalement. Si on respecte ce pos-tulat, la vraie question est d’identi�er quellessont les clés de découpage.

La première idée est de regrouper les per-sonnes sous la forme de «component team»correspondant soit à un savoir-faire, soit à unestrate d’architecture. Cette organisation at-teint ses limites lorsque les demandes métiertouchent toutes les équipes de façon inégaletout en les noyant dans la synchronisation.

Une deuxième idée, appelée «featureteam», va au contraire regrouper toutes lescompétences nécessaires pour adresser unefonctionnalité même si cela nécessite de tra-verser toutes les strates d’architecture. Lesrisques d’incohérences inhérentes à cette or-ganisation sont en partie adressés par desréunions de partage par spécialité appeléescommunauté de pratiques.

C’est un mélange de ces deux modesd’organisation qui est observé dans les entre-prises agiles avec un ratio de 80/20 entre fea-ture et component team.

Page 20 / 30

. Le product managementLes changements à opérer sur la dimen-

sion du produit ont déjà été explicités lorsquenous avons évoqué la première et la troisièmefrontière au début de cet article. Le vrai chan-gement de paradigme résultant de l’instruc-tion de ce pilier est le passage de la notionde projet vers la notion de produit (un pro-jet a une �n, un produit pas nécessairement).Cette transformation a bien sûr un impact di-rect sur l’organisation et sur nos 3 niveaux deprocessus.

. La cultureSi les 4 piliers précédents semblent com-

plexes à faire évoluer, la culture reste le pilierle plus dif�cile à adresser. Une culture d’en-treprise est quelque chose qui s’est construiteau �l du temps souvent à l’initiative des fon-dateurs de l’entreprise. Le changement deculture peut être à ce point traumatisant qu’ilva potentiellement challenger les fondationsmême de l’entreprise. Illustrons cela au tra-vers de quelques traits culturels forts qui sontpartagés par des entreprises que l’on va quali-�er d’avancées en terme d’agilité. Un premier

trait se cache derrière le duo autonomie etresponsabilité. C’est l’opposé des pratiquesde type « command and control ». Ces en-treprises ont abandonné les rôles de supervi-seur pour donner plus d’autonomie et de res-ponsabilité aux opérateurs. L’autonomie et laresponsabilité sont les qualités clés d’un sys-tème agile qui va au contraire péricliter dansun environnement de sur-contrôle, facteur dedésengagement. Un autre trait de ces entre-prises est la notion de coopération, au sensoù la coopération est quelque chose qui faitmal, que la coopération signi�e dégrader saperformance individuelle au pro�t de la per-formance globale. Une conséquence pratiqueobservée dans ces entreprises est la suppres-sion des objectifs ayant une portée locale etindividuelle.

Voilà un aperçu rapide du chemin à par-courir pour tendre vers une entreprise agileayant intégré la dimension changement àson ADN. L’entreprise agile, en vérité, est unconcept à redé�nir pour chaque organisationselon son secteur d’activité, sa stratégie et sonADN. Chaque entreprise se lançant dans cettequête aura donc tout loisir de positionner lespiliers les uns par rapports aux autres à la re-cherche d’une agilité et d’un équilibre qui luisera propre.

Accéder à cet article en ligne ...

http://goo.gl/L70s62

"Youtube : USI 2013Agilité à grande échelle"

http://goo.gl/7wWiL5

J’y vais demain : 7 conseils

pour entamer unetransformation agile

publié en février 2014 dans l’ (suisse)

Les chantiers à mener pour être agile àl’échelle de l’entreprise sont conséquents,sans commune mesure avec la relative sim-plicité à adpoter l’agilité à l’échelle d’unprojet. Ils nécessitent une première mise enœuvre de l’agilité sur des projets pilotes etla compréhension des enjeux de ce chan-gement d’échelle.

Il reste alors à savoir comment débutervotre transformation agile : nous vous pro-posons dans cet article sept conseils poury parvenir.

) Établir un diagnostic

Avant de se lancer dans cette transforma-tion, il est important d’être aligné sur la situa-tion de départ. C’est l’objectif d’un diagnosticformalisant à la fois les douleurs et les �ertésde l’entreprise. Le périmètre de cet état des

lieux est centré sur l’IT mais il concerne aussitous les acteurs en relation avec elle.

Ce constat doit être établi de façon trans-verse et partagé avec l’ensemble des acteurs,dont le top management.

) Partager la motivation et l’urgence du changement

Le changement fait peur et la transforma-tion va avoir un impact sur l’organisation, lesprocessus mais également sur les postes, lesévolutions de carrières et de compétences.

Le diagnostic doit permettre de faireémerger la motivation première du change-ment (par exemple une incapacité de l’entre-

prise à s’adapter aux évolutions de son mar-ché).

L’alignement de l’ensemble des acteursde l’entreprise sur l’urgence de la transforma-tion est fondamental pour se préparer et ré-sister aux fortes turbulences qui seront inévi-tablement engendrées.

Page 22 / 30

) Créer une équipe dédiée au changement appuyée par letop management

La transformation doit être portée par uneéquipe impliquant les différentes directionsde l’entreprise : informatique bien sûr, maiségalement les RH et les directions métiers.

Il s’agit d’un projet pour toute l’entreprise,qui changera jusqu’à sa culture et nécessiteun mandat venant de la direction qui en est le

sponsor.Cet appui est primordial pour résister à

la tentation du retour en arrière lorsque leséquipes sont confrontées aux pertes de pro-ductivité transitoires qui surviennent lors dela mise en place de changements fondamen-taux.

) Adopter le changement par le bas et le porter par lehaut

L’évolution vers une entreprise agile re-quiert un changement au sein des équipesprojets mais elle doit aussi concerner le ma-nagement et la gouvernance de l’entreprise.

Ce changement, coordonné, doit êtremené à ces deux niveaux conjointement a�nque chacun comprenne les béné�ces, enjeuxet contraintes de l’autre :> Au niveau décisionnaire, l’introduction de

nouvelles méthodes et de nouveaux outils

de pilotage du portefeuille projet (prio-risation, KPI, etc.) impactera les équipesprojets.

> Au niveau des équipes projets, l’adapta-tion permanente des pratiques et rituelsagiles mis en place impactera la capacitéà gouverner l’entreprise.Opérer le changement en le tirant unique-

ment par le bas ou par le haut se fera au dé-triment de l’autre partie.

) Ne pas oublier les fondamentaux agiles

Les pratiques et les outils issus de XP(tests automatisés, intégration continue, etc.)ont permis la mise en place avec succès despremiers projets pilotes : ils ne doivent pasêtre oubliés ni galvaudés lors de l’extensionde l’agilité au reste de l’entreprise (lorsquel’attention sera portée sur d’autres priorités,que la pression augmentera ou que les turbu-lences liées au changement apparaîtront).

L’humain doit être au centre de cettetransformation. Les équipes doivent être com-posées de pro�ls mutli-compétences dont laformation et le coût ne doivent pas être né-gligés. L’implication des RH est alors primor-

diale.

Page 23 / 30

) Procéder étape par étape et mesurer !

Les géants du web sont obsédés par lamesure au point que l’introduction de chan-gement est conditionnée par la capacité àmesurer les résultats de ce changement. Au-delà de l’utilisation naturelle de la mesurepour améliorer un produit, cette démarchepeut être mise en œuvre dans le cadre deschangements méthodologiques et organisa-tionnels.

Elle permet ainsi de :> s’aligner sur les résultats attendus d’un

changement> mesurer l’impact (et la réussite) du chan-

gement opéréAu �nal, il est possible d’opérer étape par

étape, en véri�ant pour chacune d’entre ellesque les résultats sont conformes aux attentes(une fois la phase transitoire passée).

) Commencer par accélérer !

Une fois les pré-requis en place (constatpartagé, alignement sur l’urgence et sponso-ring), il reste à choisir les premiers change-ments à opérer.

Un bon moyen de les mettre en évidenceest d’augmenter le rythme des livraisons (pas-ser par exemple d’une livraison mensuelle à

une livraison tous les quinze jours).Le stress imposé au processus en place

laisse naturellement apparaître les points defrictions à adresser de façon prioritaire pourinsuf�er les premiers changements vers plusd’agilité.

Accéder à cet article en ligne ...

http://goo.gl/v4Jakj

Les événements

OCTO technology à Genève

UN VOYAGE VERS L’ENTREPRISE AGILEPetit-déjeuner du mercredi décembre

à Genève

Une fois passées vos premières expéri-mentations sur lesméthodes agiles, une ques-tion doit forcément s’imposer à vous de façonrécurrente : comment changer d’échelle ?

Bien sûr, il ne s’agit pas de savoir commentlancer un énième projet agile mais plutôt derépondre aux questions suivantes :> Qu’est ce qu’une entreprise agile ?

> L’entreprise agile chez moi, est-ce quecela fait sens ? Jusqu’où dois-je ou jus-qu’où puis-je aller sur le sujet ?

> Comment opérer la gestion de porte-feuille de mes projets et réussir mes exer-cices budgétaires dans ce contexte ?

> Comment entamer cette transformation ?Quels sont les écueils à éviter ?

Page 25 / 30

En répondant à ces questions, OCTO vouspropose un voyage vers l’entreprise agile. Iln’est pas question ici de XP, Scrum, Softwarecraftsmanship, lean startup, TDD ou DevOps,mais bien de la manière de créer une alchi-mie réunissant ces ingrédients au travers dela gouvernance, l’organisation et la culture

qu’elle soit managériale ou d’entreprise à tra-vers de quelques frameworks d’entreprise quipeuvent être utiles (par exemple SAFe).

Découvrez un cadre de ré�exion et lespremiers éléments pour mener votre organi-sation vers ce que nous appelons l’entrepriseapprenante (à défaut d’entreprise agile).

"Slideshare - Vers l’entreprise agile"

http://goo.gl/1VRqMI

"OCTO-TV : Petit-déjeuner - Vers l’entrepriseagile"

http://goo.gl/jssyQZ

LES BUSINESS ANALYSTS FACE A l’AGILITE : DENOUVEAUX CHALLENGES A RELEVER

Petit-déjeuner du mercredi avril àGenève

Le business analyst(BA) joue un rôlecrucial dans nosorganisations. Lienessentiel entre lesopérationnels etl’informatique, ilidenti�e, analyse,valide et docu-mente les besoinsmétiers et participeà la mise en placede solutions.

Page 26 / 30

Dans un projet traditionnel (en cascade),son activité gravite naturellement autour dela rédaction des spéci�cations fonctionnelles,réalisées typiquement en amont des dévelop-pements.

Dans un contexte plus agile par contre,dans lequel les besoins peuvent être raf�nés,repriorisés, réévalués, redé�nis continuelle-ment et dans lequel la notion même de spé-ci�cation telle qu’on la connaît est remise encause, comment continuer à valoriser les com-

pétences du BA?

En abordant ces questions, c’est égale-ment le rôle des spéci�cations, de leur placeau sein d’un projet agile et de leur lien étroitavec les tests que l’on clari�era dans ce petit-déjeuner.

Avec l’avènement de l’Agilité, le Busi-ness Analyst doit se renouveler. Découvrez lespistes qui lui permettront de travailler de ma-nière plus agile.

"Slideshare - les Business Analysts face à l’Agilité : de nouveaux challenges à relever"

http://goo.gl/ZnByT4

AGILE & TOP MANAGEMENT, UNE THERAPIEPOUR LEUR PRINCIPAUX CHALLENGES ?Afterwork du Mercredi juillet à

Genève

Le CEO conference board a publié,comme chaque année, le podium des chal-lenges que les exécutifs européens pensentdevoir adresser en 2014.

Passée la surprise de ne pas trouver entête les grands classiques tels que l’optimi-sation de la relation client ou la gestion des

risques économiques et politiques, on se sur-prend à découvrir un podium ressemblant às’y méprendre au portrait chinois d’une entre-prise agile : la qualité d’exécution, le manage-ment de l’innovation et le développement ducapital humain.

Page 27 / 30

Dans un contexte de faible croissance oùla qualité n’est pas un sujet négociable et oùseules les entreprises capables d’innover avec

frugalité et rapidité sortent du lot, le capitalhumain semble revenir au centre des enjeux.

Nous vousproposons uneprésentationdes conceptset des pra-tiques les plusessentiels, qui,à notre avis,constituentle terreau deconnaissancesnécessaires detout exécutif s’ilsouhaite se lan-cer sur la routede l’entrepriseagile, ce qui,comme vousvous en doutez,nous paraîtindispensable.

"Slideshare - Vers Agilité et TopManagement"

http://goo.gl/VbKQag

"Youtube : Challenges, Agile et topmanagement"

http://goo.gl/hEcfPJ