Cette brochure présente l'expertise d'Octo Technology en matière d'agilité, soulignant la nécessité d'adopter des méthodes agiles pour assurer la réussite des départements informatiques face à la transformation digitale. Elle aborde divers sujets, tels que le DevOps, la transformation agile à grande échelle et fournit des conseils pratiques pour entamer cette transition. En encourageant la collaboration entre le métier et l'informatique, la brochure met en avant les principes de l'agilité comme un moyen d'améliorer les processus de développement et d'accroître l'efficacité des projets.

3. Au sommaire de notre brochure
Vous trouverez dans cette brochure des éléments clés sur l’agilité qui
témoignent de nos compétences sur le sujet.
page
> L’édito . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
> Mon projet est-il vraiment AGILE ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
> DevOps - le mouvement qui tend à «Agilifier» 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

4. édiTo
par Joseph Glorieux
Directeur Général
OCTO Technology
(Suisse)
Nous mettons notre expertise
Agile à votre disposition
pour vous accompagner
dans 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 entreprises
de la Silicon Valley, c’est une transition nécessaire à la survie sur le long terme
des départements informatiques.
Nous vous faisons parvenir aujourd’hui dans cette brochue une compilation
de quelques-uns de nos articles sur ce sujet pour vous présenter notre expérience
et vous confirmer notre volonté de vous acccompagner dans cette transition.
L’agilité en profondeur
Tout d’abord, être agile, c’est quoi ?
Le fait est qu’il ne suffit pas de travailler par itérations de quelques semaines
ou de discuter tous les matins en restant debout pour adresser les difficulté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éfinitive 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éfices, sans une adoption à large échelle
des principes XP.
Dans le détail, une usine logicielle, des tests automatisés, la qualité du code sans
compromis (refactoring, règle des 4 yeux, etc.) ainsi que l’intégration automatisée
et continue, idéalement jusqu’en pré-production, sont indispensables.
La nature des relations avec le commanditaire, le métier et ses représentants
ainsi 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é. Au
contraire, le métier et l’IT doivent travailler main dans la main. L’IT se met à nu
devant le métier, se montre honnête et transparente. Le métier quant à lui doit
ré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, de
reproduction de bug ou encore perdus à cause de l’indisponibilité du système
ou simplement de son mauvais fonctionnement.
Page 2 / 30

5. Un changement clé pour la transformation
digitale
La transformation agile est aujourd’hui un facteur essentiel de réussite à la
transformation digitale de l’entreprise.
En effet, si le modèle et la position de l’informatique dans l’entreprise et dans
la 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évolution
digitale.
Les entreprises pour lesquelles l’informatique ne vas pas devenir le premier
vecteur d’innovation et la pierre angulaire de leur modèle d’affaire au cours des
dix prochaines années existent, bien sûr, mais elles sont très peu nombreuses.
Or la transformation digitale des entreprises repose sur quelques prérequis
qu’il est impossible de court-circuiter. La transformation agile du département
informatique en fait bien évidemment partie, ainsi que l’adoption des principes
DevOps et Lean Startup.
Nos atouts pour vous accompagner
En 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 sur
ce sujet pour tout type d’entreprise, des startups aux multi-nationales. Nous nous
réjouissons de vous rencontrer au prochain événement que nous organisons sur
ce sujet.
Page 3 / 30

6. 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 de
s’améliorer quel que soit son niveau de maturité : comprendre comment un
bug a pu perdurer jusqu’à la démonstration client, réussir ses rétrospectives
d’itérations et en mesurer le bénéfice, etc. Les sujets peuvent être nombreux
et 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 outils
indispensables à nos projets Scrum. Nous en avons fait un document de me-
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élioration
continue.
Au-delà de savoir si nos projets étaient
agiles, 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 permis
de partager nos expériences, nos outils et de
les condenser sous une forme accessible et
utilisable par tous. Le résultat est un ensemble
de points qu’il est possible d’utiliser pour for-
mer de nouveaux intervenants sur un projet
agile, partager la connaissance et enfin s’amé-
liorer en continu !
Si beaucoup de rituels agiles issus
de Scrum nous semblaient indispensables,
d’autres outils venus notamment du Lean
nous sont apparus tout aussi pertinents. Nous
les avons donc incorporés et pensons qu’ils
peuvent ê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éduire
certaines 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 un
client 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

7. Rituels Agiles
Stand up
Point quotidien de l’équipe.
k Un standup quotidien est réalisé à heure
fixe
k Les interventions aux standup sont limi-
tées à 1 minute par personne (la réunion
reste courte)
k Chaque participant s’adresse aux autres
membres de l’équipe (et pas à un leader
unique)
Rétrospective d’itération
Retour sur l’itération, sur le process, les rela-
tions etc. dans une démarche d’amélioration
continue
k Avant le démarrage d’une itération, une
rétrospective est réalisée sur l’itération
précédente
k En début de rétrospective, les actions
décidées à la dernière rétrospective sont
revues
k Toute l’équipe de développement, le
delivery manager et le PO sont présents
à la rétrospective
k Chacun arrive à exprimer des points dif-
ficiles du projet
k Des solutions concrêtes sont trouvées
pour résoudre les points difficiles et des
acteurs sont identifiés pour les mettre en
oeuvre
k La rétrospective a un facilitateur désigné
qui l’anime. Le facilitateur ne contribue
pas au contenu
Démonstration de fin d’itération
k En fin d’itération, une démonstration du
produit est présentée au Product Owner
(PO)
k Les démonstrations sont préparées à
l’avance (vérification préalable de cha-
cune des stories)
Bilan de fin 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 (planification de l’itéra-
tion)
Planning game : choix, priorisation et esti-
mation en complexité des stories
k Le PO sélectionne les stories à estimer
pour 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 toute
l’équipe pour estimer les stories
k Le nombre de stories à développer par
itération est choisi en fonction de la vé-
locité de l’équipe (somme des points de
complexité validés dans l’itération pré-
cédente)
k A la fin du planning game, les stories
sont priorisées
Méthodologie
Tenue de backlog
Planification des itérations
k L’équipe de développement et le PO
partagent le même document listant les
fonctionnalité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 à la
StoryMap du projet s’il y en a une
k A partir du Backlog, on peut retrouver les
tests de recette associés à chaque story
Page 5 / 30

8. Management visuel partagé
La salle projet reflète l’état du projet
k L’équipe utilise un support visuel pour
organiser les stories (Kanban board)
k Les différentes colonnes du Kanban sont
clairement séparées et une « Defini-
tion Of Done » (DOD) est définie pour
chaque colonne
k Les DOD sont respectées par chaque
membre de l’équipe
k L’équipe utilise un bac rouge pour ré-
férencer et traiter les problèmes liés au
projet
k 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 de
release, contenu de ces releases, burn-
down chart, planning d’itération, tro-
phées, etc.) sont affichées
k Chaque itération a un objectif qui est af-
fiché (au dessus du Kanban)
Bonnes pratiques
Développement organisé
L’équipe organise son travail
k Les stories sont développées dans
l’ordre de priorité défini par le PO en
planning game
Industrialisation des développements
Les processus de développement/livraison
sont industrialisés
k Le projet utilise une Usine De Dévelop-
pement (UDD) pour l’intégration conti-
nue (build, lancement des tests, vérifica-
tion qualité)
k La livraison au client est réalisée grâce à
l’UDD
k La livraison est réalisée en suivant une
checklist
Méthodes de développement
L’équipe utilise des pratiques permettant de
s’améliorer
k L’équipe réalise les stories les plus diffi-
ciles en Pair Programming
k Tout code est validé par un autre
membre de l’équipe (correction, aligne-
ment des pratiques)
k Les fonctionnalités de l’application sont
testées unitairement et automatique-
ment
k L’équipe développe en Test Driven De-
velopment (TDD)
k Le projet possède un document avec ses
normes (page wiki, feuille au mur, fichier
readme, autre), de préférence de ma-
nière visuelle
Communication
Vie de l’équipe et relation client
Comment se sentent les membres de
l’équipe
k L’équipe s’améliore de façon continue
k L’équipe a la confiance du client
k La communication dans l’équipe et avec
le client est facile / bonne
k L’équipe favorise la colocalisation (tous
les acteurs du projet sont colocalisés)
Page 6 / 30

9. Et du coup, il est agile mon projet ?
Avoir un outil à sa disposition n’est que
le premier pas ! Il faut encore l’adapter à son
contexte, que son équipe l’accepte et enfin
savoir analyser ses résultats !
Adapter ses outils à son besoin
Certains des points présentés ne corres-
pondent certainement pas à tous les pro-
jets et d’autres peuvent manquer. Un conseil
que 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é dans
l’équipe.
N’hésitez pas à y ajouter vos stan-
dards (meilleures pratiques observables sur
vos missions). Une bonne communication et
une formulation pédagogique des questions
sont également nécessaires pour maximiser
l’adhésion de chaque participant.
Visualiser et analyser ses résul-
tats
Mesurer régulièrement sa pratique agile
permet d’en suivre l’évolution et d’analyser ra-
pidement les bienfaits d’une pratique.
Vérifier la checklist par exemple tous les
mois permet de mettre en évidence les résul-
tats des actions d’amélioration entrepris par
un groupe.
Un(e) responsable pourra être choisi(e)
pour analyser les réponses des participants du
projet.
De plus, il est intéressant que ce question-
naire soit rempli par chaque membre l’équipe
afin d’obtenir le point de vue de chacun.
Cela fera éventuellement apparaître des
divergences d’opinion qui pourront valoir la
peine d’être discutées pour améliorer la vision
commune dans le groupe.
Afin de mieux visualiser les résultats et de
les comparer dans le temps, nous avons créé
un excel qui convertit notre Google Form en
tableau récapitulatif et qui simplifie grande-
ment notre analyse (voir tableau en page 8)
Echanger avec son équipe
Enfin, une fois l’analyse effectuée, se
réunir régulièrement permet de présenter
les résultats. C’est l’occasion d’échanger, de
comprendre les difficultés de chacun et de
choisir 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 choisir
d’ajouter une nouvelle pratique observée ou
encore d’arrêter d’utiliser la checklist (« On est
trop forts ! »).
Un dernier conseil pour que cette check
list reste une pratique efficace : ne pas l’impo-
ser comme outil d’évaluation de performance
mais plutôt la proposer comme base de ré-
flexion à des équipes motivées par l’amélio-
ration de leur quotidien.
Page 7 / 30

10. Accéder à cet article en ligne ...
http://goo.gl/4v3uth

11. DevOps
le mouvement qui tend à
«Agilifier» votre DSI
publié sur
La communauté « DevOps » nous
invite à repenser la frontière classique
de 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 exploitent
ces applications (le «Run»).
Pourquoi DevOps ?
Deux groupes se retrouvent dans le mou-
vement DevOps et apportent un peu de frai-
cheur dans ces réflexions aussi anciennes que
les DSIs :
> Les agilistes qui ont levé la «contrainte»
côté développement et sont maintenant
capable de «livrer» beaucoup plus sou-
vent du logiciel valorisé par le client...
mais regrettent que «la prod ne suive pas»
> Des experts ou des managers de la «prod»
des géants du web (Amazon, Facebook,
LinkedIn, etc.) partageant leurs retours
d’expérience sur leur façon d’envisager
cette frontière
Au delà des fractures organisationnelles,
les préoccupations des études et de la pro-
duction sont bien distinctes et respectivement
louables.
Les études recherchent plus de réacti-
vité (sous la pression du métier et du mar-
ché notamment) : il faut aller vite, ajouter
de nouvelles fonctionnalités, réadapter les di-
rections, refactorer, upgrader les frameworks,
déployer rapidement pour tester. La nature
mê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 difficile d’anti-
ciper quels impacts auront telles modifi-
cations de l’infrastructure : un disque lo-
cal qui devient un disque réseau mais im-
pacte les temps de réponses, ou encore
un changement de code qui impacte for-
tement la consommation CPU et par la
même le «capacity planning».
Page 9 / 30

12. > Standardisation enfin car la production
veut s’assurer que certaines règles (sécu-
rité réseaux, configuration des fichiers de
logs, etc.) sont uniformément respectées.
Un objectif commun
Malgré ces contraintes divergentes, ces
deux groupes ont un objectif commun : faire
fonctionner le système. Finalement, le dé-
ploiement n’est pas le plus important dans
cette problématique même si c’est certaine-
ment une des activités les plus consomma-
trices en ressource : la moitié du temps de
la 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 levier
d’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 des
variables techniques (augmentation des
temps de réponse, etc.) en variables bu-
siness (baisse du CA généré, etc.). Et
qu’une des clés du succès d’interprétation
de ces métriques est la collaboration entre
les études (la compréhension du code) et
la production (la compréhension des ser-
veurs, du réseau, etc.)
> «qu’agilifier» le processus de développe-
ment c’est bien mais que le véritable en-
jeu c’est l’agilité « business » qui passe par
la réduction du délai global «from concept
to cash», de l’idée à la mise au produc-
tion. Cela passera entre autres par des dé-
ploiements plus «agiles», sur l’exemple de
Flickr, qui réalise 10 déploiements quoti-
diens
Page 10 / 30

13. Améliorer la collaboration
Atteindre cet objectif ne se fera pas sans
douleur et trouve des leviers d’amélioration
dans 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 un
des gènes du cloud : le self service. Les
offres de cloud public sont matures sur le
sujet mais certaines offres (VMWare par
exemple) visent à reproduire ces modes
de fonctionnement en interne. Mais sans
forcé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 de
décorréler les cycles de déploiements, de
déployer du code sans pour autant mettre
la fonctionnalité à disposition des utilisa-
teurs.
> de l’organisationnel qui vous amènera
peut-être, vous aussi, à implémenter les
patterns d’Amazon «two pizzas team» et
«you build it, you run it»
> du processus qui permettra de fluidi-
fier tous ces échanges. Comment dé-
ployer plus souvent ? Comment limiter ses
risques en déployant progressivement ?
Comment appliquer les leçons de « flux »
tirées de Kanban à la production ? Com-
ment repenser les mécanismes de com-
munication et de coordination à l’œuvre
sur la frontière études/production ?
En définitive ces 4 axes nous permettront
d’atteindre les objectifs supérieurs de De-
vOps : améliorer la collaboration, la confiance
et l’alignement d’objectifs entre les études et
la production.
Accéder à cet article en ligne ...
http://goo.gl/QwusM2
"DevOps, de l’intégration continue au
déploiement continu"
http://goo.gl/Ot1NtT

14. Lean Startup
(des Patterns des géants du
Web)
publié sur
La création d’un produit est très sou-
vent vouée à l’échec. Ainsi, les chiffres
montrent que 95% des produits ou startups
meurent par manque de clients.
Le Lean Startup est une approche de
création produit qui se propose de réduire
les risques d’échec en attaquant parallèle-
ment les aspects organisationnels, business
et techniques et cela avec des itérations
agressives. Formalisée par Eric Ries, elle est
fortement inspirée du Customer Develop-
ment de Steve Blank..
Les principes Lean Startup
Build – Mesure – Learn
Tout produit ou fonctionnalité part d’une
hypothèse. Cette hypothèse peut être issue
de données récoltées sur le terrain ou d’une
simple intuition.
Toujours est-il que l’approche que prône
le 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 vite
possible sur le terrain.
Ce dernier point est l’un des éléments
centraux du Lean Startup. Chaque hypothèse
− business, organisationnelle ou technique −
doit être validée qualitativement et vérifiée
quantitativement. Cette démarche permet de
mettre en place une boucle d’apprentissage
sur le produit et le client. Le Lean Startup com-
bat donc l’approche qui consiste à construire
un produit pendant un an et se rendre compte
tardivement que des choix (marketing, fonc-
tionnel, commercial) mettent l’organisation en
danger. Il faut tester tout de suite et au plus
vite.
Page 12 / 30

15. Expérimenter pour Valider
Une partie de
l’approche se base
sur le Minimum Viable
Product. Quel est
l’ensemble minimal
de fonctionnalités
que je dois construire
pour valider mes
hypothèses ?
On ne parle pas
ici nécessairement de
code et de produit
au sens technique
du terme, mais de
n’importe quel effort
qui va permettre
d’avancer sur ces
hypothèses.
Cela peut être un questionnaire Google
Docs, une mailing list ou une fausse fonction-
nalité pour tester l’appétence du marché.
L’expérimentation et les leçons associées
sont un actif inestimable pour le pilotage du
produit et justifient la mise en place de la
boucle d’apprentissage.
L’obsession de la mesure
On imagine donc bien que ces expé-
rimentations doivent systématiquement être
suivies par une mesure fiable et complète.
Une approche centrée client – Go
out of the building
Vérifier qualitativement et valider quanti-
tativement signifie bien souvent « sortir de
l’immeuble », comme dirait Bob Dorf, co-
auteur du fameux 4 Steps to the Epiphany.
«Go out of the building» (GOOB) est au
centre des préoccupations des Product Ma-
nagers pratiquant le Lean Startup. Tant que
les hypothèses ne sont pas confrontées à la
réalité, elles restent des suppositions. Et donc
des risques potentiels pour l’organisation.
«No plan resist first contact with custo-
mers» (Steve Blank) est ainsi l’une des devises
des é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 rester
constamment au contact du client, et donc
de valider les hypothèses business (les dol-
lars). Zappos, géant US de la chaussure sur le
Web, est un exemple de MVP mis entre les
mains des utilisateurs réels très tôt. Pour se
confronter à 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 de
toute pièce. Ce faisant, et sans construire une
cathédrale, il valida très tôt que la demande
existait et que la construction d’un tel produit
pouvait s’avérer gagnante.
Le pilotage par la donnée
Evidemment, pour apprendre du compor-
tement des utilisateurs lors de ces sessions de
GOOB, les Product Managers récoltent méti-
culeusement de la donnée qui leur permet de
prendre les décisions adéquates.
Page 13 / 30

16. Ils mettent évidemment au préalable en
place les outils et processus de récolte de
cette donnée.
Les plus utilisées sont bien connues de tous. Il
s’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 fait
comme hypothèse que les utilisateurs utilise-
raient LinkedIn ou Viadeo pour se connecter,
afin de leur éviter de se créer un compte et
pour nous éviter de développer un système
d’inscription.
Nous avons donc construit le minimum pour
invalider ou valider l’hypothèse : une page qui
comportait les trois options, à savoir l’inscrip-
tion via Linkedin, celle par Viadeo et celle par
un compte ChooseYourBoss.
Les deux premières fonctionnaient réelle-
ment, le compte ChooseYourBoss indiquait
que le compte ChooseYourBoss n’était pas
encore disponible en production.
Résultats : les utilisateurs ne voulant pas
utiliser 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 sommes
passé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égrer
les feedbacks utilisateurs au plus tôt dans la
création de produit. Dropbox a, par exemple,
changé complètement son fonctionnement
en simplifiant drastiquement la gestion des
dossiers synchronisés. Heroku est passé d’une
plateforme de développement sur le cloud à
une solution d’hébergement sur le cloud. Les
exemples sont nombreux et plus ingénieux les
uns que les autres !
Page 14 / 30

17. Et chez vous ?
Le Lean Startup n’est pas dogmatique.
C’est avant tout prendre conscience que le
marché et le client ne sont pas dans les
ré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 en
place une discipline de validation des hypo-
thèses en gardant pour principe de valider le
minimum de fonctionnalités à un instant "t".
Avant de faire la moindre ligne de code,
les principales questions à se poser tournent
autour du triplet Client / Problème / Solution :
> Ai-je réellement un problème qui vaut la
peine d’être résolu ?
> Ma solution est-elle la bonne pour mon
client ?
> Est-il susceptible de l’acheter ? A com-
bien ?
Tous les moyens sont bons pour lever ces
hypothèses : interviews, études de marché,
maquettes, etc.
La seconde étape consiste à savoir si le
modèle que j’ai pu tester à moindre échelle
est répétable et extensible. Comment mettre
entre les mains des clients un produit dont
ils n’ont jamais entendu parler ? Vont-ils com-
prendre, utiliser et tirer des bénéfices de mon
produit ?
Les troisième et quatrième étapes
tournent autour de la croissance : comment
faire venir des clients et comment construire
une société qui va pouvoir accueillir et faire
grandir mon produit.
Contrairement à ce que l’on pourrait pen-
ser à la lecture de ce billet, le Lean Startup
n’est pas une approche à réserver unique-
ment à des sites Web grand public. Innover
en validant le plus rapidement possible des
hypothèses et en limitant l’investissement fi-
nancier est évidemment une logique trans-
posable à tout type de projet informatique,
fût-il interne. Nous sommes convaincus que
cette 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 par
l’utilisateur
Pour plus d’information, vous pouvez
consulter la session sur le Lean Startup lors
de l’USI 2012 qui traite des deux premières
étapes.
Retrouver toutes les pratiques des
Gé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éants
du Web »
Accéder à cet article en
ligne ...
http://goo.gl/v4Jakj
"Youtube : USI 2012
Lean Startup"
http://goo.gl/BKebya
"Les géants du Web"
www.geantsduweb.com

18. Déployer l’agile à large
échelle
c’est jouer sur les
frontières de l’entreprise
publié en février 2014 dans l’ (suisse)
Passées les premières expérimentations des méthodes agiles au sein
de l’entreprise avec un succès que l’on va qualifier de variable, d’aucuns
se posent la question de comment aller plus loin, voire comment envisager
une entreprise agile.
Nous sommes convaincus que déployer l’Agile à large échelle, c’est
jouer sur les frontières de l’entreprise et nous allons justifier cette position
dans cet article.
Tous les architectes techniques vous le diront, il existe deux types de
scalabilité quand on parle de serveur : la scalabilité verticale (augmenter
les capacités du serveur) et horizontale (distribuer sur plusieurs serveurs). Il
peut être intéressant d’utiliser cette métaphore lorsque l’on parle de diffuser
l’Agile plus largement.
La scalabilité verticale ou comment dépasser les
frontières au sein d’un projet
Prenons le cas d’un projet où l’équipe de
la DSI est en charge d’un développement en
mode Agile. Cette équipe composée de 8
personnes fonctionne bien et se pose la ques-
tion de comment aller plus loin. Les pratiques
agiles supposent déjà d’améliorer l’environ-
nement sur lequel on a la maîtrise et c’est
une étape essentielle. Mais rapidement, on
est confronté à d’autres frontières qui vont
finalement limiter les avantages de l’Agile à
un périmètre restreint, ici, l’équipe projet. Il
est alors nécessaire de dépasser ces frontières
pour 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 ou
ses utilisateurs.
Page 16 / 30

19. . Frontière étude vs métier
Développer un logiciel avec une équipe
agile sans le métier revient à construire un pro-
duit de qualité en respectant un cycle en V en
livrant juste plus fréquemment. Pour profiter
réellement des promesses de l’Agile (qualité,
adaptabilité et gestion du risque), la partici-
pation du métier est indispensable. C’est en
introduisant des rôles (le product owner), des
pratiques agiles (les spécifications par les tests
comme TDD) et en définissant clairement les
droits et devoirs de chacun (« vous pou-
vez changer les priorités de développements,
mais nous sommes en budget contraint et
donc certaines fonctionnalités devront sortir
du 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 pas
la prendre à la légère.
En effet, nos organisations ont passé ces
20 dernières années à cloisonner ces deux
mondes. Beaucoup des solutions permettant
de redéfinir cette frontière se cachent der-
rière le terme « DevOps », qui regroupe des
pratiques touchant l’architecture, les outils, la
méthodologie et l’organisation, visant à amé-
liorer la collaboration entre les études et la
production.
DevOps repose sur 3 principes clés qui
sont les garants d’une agilité allant jusqu’à la
production :
> l’infrastructure « as » code,
> le « continuous delivery »,
> la culture de la collaboration.
. Frontière métier vs clients ou
utilisateurs
Enfin, 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. La
nuance se situe dans cette dernière frontière
où la compréhension des hypothèses spéci-
fiées par le métier peut être excellente tout en
ne correspondant finalement pas aux attentes
des utilisateurs.
C’est dans certaines pratiques issues du
milieu des startups («lean startup» notam-
ment) qu’une diminution de cette frontière est
possible. Ces approches s’échinent à décou-
vrir simultanément les utilisateurs et le produit
afin d’en assurer la convergence. Ainsi, sur la
base d’hypothèses ou d’idées, on commence
à construire le produit que l’on va confronter
aux utilisateurs afin 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é sur
tout son cycle projet. Essayons à présent de
transposer ces pratiques non pas à un projet
mais à tous les projets de l’entreprise.
Page 17 / 30

20. La scalabilité horizontale ou comment dépasser les
frontières d’un seul projet
Si réaliser les étapes précédentes sur un
projet représente déjà un challenge, l’opérer
jusqu’à la gestion du portefeuille de projet
est bien plus complexe mais c’est le chemin
à suivre vers une entreprise agile en capacité
à accepter le changement et à s’améliorer en
continu. Les frontières en question, cette fois-
ci, sont celles présentes entre chaque équipe
projet 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-
difications au travers des 5 piliers présentés
ci-dessous. Instruire une transition agile dans
une entreprise revient donc à travailler sur
ces 5 piliers en introduisant petit à petit les
concepts 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ées
lorsque nous avons parlé de « DevOps » ou
BDD. Il y en a bien d’autres pour la plupart
introduites via l’eXtreme Programming. Deux
choses sont à retenir lorsque l’on parle d’agi-
lité à large échelle. La première est que l’on a
tout intérêt à diffuser les meilleures pratiques
dans l’entreprise sans volonté de les imposer
à tout prix. La deuxième est que certaines de
ces 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 tests
augmente d’incrément en incrément sans
garantir 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’efficacité,
> l’investissement sur l’homme : mettre tout
en œuvre pour garantir l’expertise, la po-
lyvalence et la curiosité de ses collabora-
teurs.
Page 18 / 30

21. . Les processus
Quand on parle de processus autour de la
gestion 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 PMI
sur la gestion de projet en V, de fournir
une description de ces processus. Aujourd’hui
SaFE 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’hui
le plus couramment usité. On opère à la taille
de la « user story » et on parle d’itération
de 2 semaines. Cependant d’autres méthodes
existent avec notamment « Kanban » issue du
Lean qui est plus difficile à digérer au démar-
rage mais plus à même de gérer une problé-
matique de flux.
Coté gestion de programme, le processus
est opéré à partir de la «roadmap» qui se dé-
cline en «release», on parle de fonctionnalités
du 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.
Enfin coté gestion de portefeuille, il s’agit
finalement d’apporter des approches agiles
au niveau des décideurs. On opère sur un por-
tefeuille de projets a minima annuel où l’on
pilote les investissements.
Page 19 / 30

22. La mise en place d’une gestion de por-
tefeuille avec un processus en flux de type
« Kanban » peut permettre d’avoir une ap-
proche où l’on limite l’encours, et permet
aussi une re-priorisation bimestrielle tout en
restant dans un environnement contraint. Une
méthode de cadrage agressive (maximum 2
mois) est un prérequis afin de pouvoir statuer
rapidement sur l’instruction ou non des pro-
grammes.
Il ne semble finalement pas y avoir de
ré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. Enfin, les changements qui
peuvent paraître anodins sont amplifiés par
leurs interactions avec les autres piliers.
. L’organisation
Les transformations potentielles à opérer
côté organisation sont fortement liées au pos-
tulat suivant : une équipe projet comprend
de 5 à 12 collaborateurs. La sociologie a dé-
montré qu’en dessous de 5 un groupe est
trop dépendant des absences et qu’il manque
de créativité. Au-delà de 12 personnes, les
groupes ont tendance à se diviser et l’effica-
cité chute brutalement. Si on respecte ce pos-
tulat, la vraie question est d’identifier quelles
sont 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 à une
strate d’architecture. Cette organisation at-
teint ses limites lorsque les demandes métier
touchent toutes les équipes de façon inégale
tout en les noyant dans la synchronisation.
Une deuxième idée, appelée «feature
team», va au contraire regrouper toutes les
compétences nécessaires pour adresser une
fonctionnalité même si cela nécessite de tra-
verser toutes les strates d’architecture. Les
risques d’incohérences inhérentes à cette or-
ganisation sont en partie adressés par des
réunions de partage par spécialité appelées
communauté de pratiques.
C’est un mélange de ces deux modes
d’organisation qui est observé dans les entre-
prises agiles avec un ratio de 80/20 entre fea-
ture et component team.
Page 20 / 30

23. . Le product management
Les changements à opérer sur la dimen-
sion du produit ont déjà été explicités lorsque
nous avons évoqué la première et la troisième
frontiè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 notion
de projet vers la notion de produit (un pro-
jet a une fin, un produit pas nécessairement).
Cette transformation a bien sûr un impact di-
rect sur l’organisation et sur nos 3 niveaux de
processus.
. La culture
Si les 4 piliers précédents semblent com-
plexes à faire évoluer, la culture reste le pilier
le plus difficile à adresser. Une culture d’en-
treprise est quelque chose qui s’est construite
au fil du temps souvent à l’initiative des fon-
dateurs de l’entreprise. Le changement de
culture peut être à ce point traumatisant qu’il
va potentiellement challenger les fondations
même de l’entreprise. Illustrons cela au tra-
vers de quelques traits culturels forts qui sont
partagés par des entreprises que l’on va quali-
fier d’avancées en terme d’agilité. Un premier
trait se cache derrière le duo autonomie et
responsabilité. C’est l’opposé des pratiques
de 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 la
responsabilité sont les qualités clés d’un sys-
tème agile qui va au contraire péricliter dans
un environnement de sur-contrôle, facteur de
désengagement. Un autre trait de ces entre-
prises est la notion de coopération, au sens
où la coopération est quelque chose qui fait
mal, que la coopération signifie dégrader sa
performance individuelle au profit de la per-
formance globale. Une conséquence pratique
observée dans ces entreprises est la suppres-
sion des objectifs ayant une portée locale et
individuelle.
Voilà un aperçu rapide du chemin à par-
courir pour tendre vers une entreprise agile
ayant intégré la dimension changement à
son ADN. L’entreprise agile, en vérité, est un
concept à redéfinir pour chaque organisation
selon son secteur d’activité, sa stratégie et son
ADN. Chaque entreprise se lançant dans cette
quête aura donc tout loisir de positionner les
piliers les uns par rapports aux autres à la re-
cherche d’une agilité et d’un équilibre qui lui
sera propre.
Accéder à cet article en ligne ...
http://goo.gl/L70s62
"Youtube : USI 2013
Agilité à grande échelle"
http://goo.gl/7wWiL5

24. J’y vais demain : 7 conseils
pour entamer une
transformation 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’un
projet. Ils nécessitent une première mise en
œuvre de l’agilité sur des projets pilotes et
la compréhension des enjeux de ce chan-
gement d’échelle.
Il reste alors à savoir comment débuter
votre transformation agile : nous vous pro-
posons dans cet article sept conseils pour
y 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 diagnostic
formalisant à la fois les douleurs et les fiertés
de l’entreprise. Le périmètre de cet état des
lieux est centré sur l’IT mais il concerne aussi
tous 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, les
processus 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 acteurs
de 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

25. ) Créer une équipe dédiée au changement appuyée par le
top management
La transformation doit être portée par une
équipe impliquant les différentes directions
de 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écessite
un 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 de
la mise en place de changements fondamen-
taux.
) Adopter le changement par le bas et le porter par le
haut
L’évolution vers une entreprise agile re-
quiert un changement au sein des équipes
projets mais elle doit aussi concerner le ma-
nagement et la gouvernance de l’entreprise.
Ce changement, coordonné, doit être
mené à ces deux niveaux conjointement afin
que chacun comprenne les bénéfices, enjeux
et 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 équipes
projets.
> Au niveau des équipes projets, l’adapta-
tion permanente des pratiques et rituels
agiles 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 des
premiers projets pilotes : ils ne doivent pas
être oubliés ni galvaudés lors de l’extension
de l’agilité au reste de l’entreprise (lorsque
l’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 cette
transformation. Les équipes doivent être com-
posées de profils mutli-compétences dont la
formation et le coût ne doivent pas être né-
gligés. L’implication des RH est alors primor-
diale.
Page 23 / 30

26. ) Procéder étape par étape et mesurer !
Les géants du web sont obsédés par la
mesure 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 mesure
pour améliorer un produit, cette démarche
peut être mise en œuvre dans le cadre des
changements 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 final, il est possible d’opérer étape par
étape, en vérifiant pour chacune d’entre elles
que 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 (constat
partagé, alignement sur l’urgence et sponso-
ring), il reste à choisir les premiers change-
ments à opérer.
Un bon moyen de les mettre en évidence
est 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 de
frictions à adresser de façon prioritaire pour
insuffler les premiers changements vers plus
d’agilité.
Accéder à cet article en ligne ...
http://goo.gl/v4Jakj

27. Les événements
OCTO technology à Genève
UN VOYAGE VERS L’ENTREPRISE AGILE
Petit-déjeuner du mercredi  décembre 
à Genève
Une fois passées vos premières expéri-
mentations sur les méthodes agiles, une ques-
tion doit forcément s’imposer à vous de façon
récurrente : comment changer d’échelle ?
Bien sûr, il ne s’agit pas de savoir comment
lancer un énième projet agile mais plutôt de
répondre aux questions suivantes :
> Qu’est ce qu’une entreprise agile ?
> L’entreprise agile chez moi, est-ce que
cela 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

28. En répondant à ces questions, OCTO vous
propose un voyage vers l’entreprise agile. Il
n’est pas question ici de XP, Scrum, Software
craftsmanship, lean startup, TDD ou DevOps,
mais bien de la manière de créer une alchi-
mie réunissant ces ingrédients au travers de
la gouvernance, l’organisation et la culture
qu’elle soit managériale ou d’entreprise à tra-
vers de quelques frameworks d’entreprise qui
peuvent être utiles (par exemple SAFe).
Découvrez un cadre de réflexion et les
premiers éléments pour mener votre organi-
sation vers ce que nous appelons l’entreprise
apprenante (à défaut d’entreprise agile).
"Slideshare - Vers l’entreprise agile"
http://goo.gl/1VRqMI
"OCTO-TV : Petit-déjeuner - Vers l’entreprise
agile"
http://goo.gl/jssyQZ
LES BUSINESS ANALYSTS FACE A l’AGILITE : DE
NOUVEAUX CHALLENGES A RELEVER
Petit-déjeuner du mercredi  avril  à
Genève
Le business analyst
(BA) joue un rôle
crucial dans nos
organisations. Lien
essentiel entre les
opérationnels et
l’informatique, il
identifie, analyse,
valide et docu-
mente les besoins
métiers et participe
à la mise en place
de solutions.
Page 26 / 30

29. Dans un projet traditionnel (en cascade),
son activité gravite naturellement autour de
la rédaction des spécifications fonctionnelles,
réalisées typiquement en amont des dévelop-
pements.
Dans un contexte plus agile par contre,
dans lequel les besoins peuvent être raffinés,
repriorisés, réévalués, redéfinis continuelle-
ment et dans lequel la notion même de spé-
cification telle qu’on la connaît est remise en
cause, comment continuer à valoriser les com-
pétences du BA ?
En abordant ces questions, c’est égale-
ment le rôle des spécifications, de leur place
au sein d’un projet agile et de leur lien étroit
avec les tests que l’on clarifiera dans ce petit-
déjeuner.
Avec l’avènement de l’Agilité, le Busi-
ness Analyst doit se renouveler. Découvrez les
pistes 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 THERAPIE
POUR 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 pensent
devoir adresser en 2014.
Passée la surprise de ne pas trouver en
tê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 du
capital humain.
Page 27 / 30

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 capital
humain semble revenir au centre des enjeux.
Nous vous
proposons une
présentation
des concepts
et des pra-
tiques les plus
essentiels, qui,
à notre avis,
constituent
le terreau de
connaissances
nécessaires de
tout exécutif s’il
souhaite se lan-
cer sur la route
de l’entreprise
agile, ce qui,
comme vous
vous en doutez,
nous paraît
indispensable.
"Slideshare - Vers Agilité et Top
Management"
http://goo.gl/VbKQag
"Youtube : Challenges, Agile et top
management"
http://goo.gl/hEcfPJ