Fondateur et Consultant Expérimenté
Développeur pendant une quinzaine d'années, développeur agile puis coach agile dès 2006, j'ai à présent l'agilité dans la peau: l'agilité comme façon de penser, comme mode de vie, comme façon de s'organiser, de travailler, de réussir, de donner réalité à ses idées, ses visions, comme moyen de réussir et de répondre à des enjeux en accélération constante.
Le coaching que je propose est basé sur:
Il suffit parfois de quelques réglages pour arriver à des livraisons fluides et continues: c'est beau de voir des équipes agiles en état de marche !
Mes sources d'influence: sport collectif (football), le jeu (ancien animateur diplômé) et théâtre.
Mon attrait pour la programmation et l'algorithmique est toujours entretenue, ce qui me permet d'avoir une approche pertinente.
Dan Borodaty
Le coaching que je propose est basé sur:
- L'écoute
- La prise en compte de l'existant et l'historique, l'acceptation que chaque situation est unique
- Apprendre à connaitre les personnes, à les apprécier pour pouvoir obtenir le meilleur d'eux-même
- Aucune reussite numérique n'est possible sans placer l'humain au centre d'un collectif
Il suffit parfois de quelques réglages pour arriver à des livraisons fluides et continues: c'est beau de voir des équipes agiles en état de marche !
Mes sources d'influence: sport collectif (football), le jeu (ancien animateur diplômé) et théâtre.
Mon attrait pour la programmation et l'algorithmique est toujours entretenue, ce qui me permet d'avoir une approche pertinente.
Dan Borodaty
Expertise Scrum
"Le framework scrum est facile à comprendre mais difficile à maîtriser".
Cette phrase du scrum guide introduit à merveille ce cadre méthologique qui a tant contribué à la transition numérique, et qui demeure fondamental au mouvement devOps ainsi que pour l'ensemble de l'agilité dont l'extension à l'échelle de l'entreprise.
L'impression grisante qu'en lisant un tuto, on est prêt à en appliquer le sujet est trompeuse: il faut d'abord avoir intégré les valeurs de l'agilité puisées dans le Manifeste agile.
Quelques valeurs de base:
Cette phrase du scrum guide introduit à merveille ce cadre méthologique qui a tant contribué à la transition numérique, et qui demeure fondamental au mouvement devOps ainsi que pour l'ensemble de l'agilité dont l'extension à l'échelle de l'entreprise.
L'impression grisante qu'en lisant un tuto, on est prêt à en appliquer le sujet est trompeuse: il faut d'abord avoir intégré les valeurs de l'agilité puisées dans le Manifeste agile.
Quelques valeurs de base:
La réussite est toujours collective et à un rythme continu
On aura toujours plus d'idées que de capacité à faire: prioriser
Ce sont ceux qui feront qui confirmeront la faisabilité et qui donneront une estimation
On ne peut pas maitriser le long terme: le court terme doit être maitrisé
Les choses ne se passeront jamais comme prévu
Admettre qu'on ne peut pas figer en même temps le coût, le périmètre et le délai
Peu importe comment on démarre: l'important c'est de démarrer, d'expérimenter, d'apprendre et de s'améliorer tous ensemble en continu
Quelques principes de base:
Avoir d'un côté une expression de besoin ordonnée par priorité et exprimée selon un formalise accepté par toute la scrum team et de l'autre une ou plusieurs équipes autonomes et responsables qui planifient sur du cours terme et tiennent leurs engagements le tout dans la collaboration et l'alignement sur le besoin client. Le livrable est maintenu en état de marche et enrichi de manière continue et incrémentale.
Pour le reste ?
La documentation disponible foisonne. Il reste à acquérir l'art de le mettre en place ...
Juste un petit conseil ?
Ne jamais oublier que l'objectif est de cultiver en équipe la réactivité pour répondre en continu à un besoin client qui évolue.. en continu !
Avoir d'un côté une expression de besoin ordonnée par priorité et exprimée selon un formalise accepté par toute la scrum team et de l'autre une ou plusieurs équipes autonomes et responsables qui planifient sur du cours terme et tiennent leurs engagements le tout dans la collaboration et l'alignement sur le besoin client. Le livrable est maintenu en état de marche et enrichi de manière continue et incrémentale.
Pour le reste ?
La documentation disponible foisonne. Il reste à acquérir l'art de le mettre en place ...
Juste un petit conseil ?
Ne jamais oublier que l'objectif est de cultiver en équipe la réactivité pour répondre en continu à un besoin client qui évolue.. en continu !
Expertise DevOps
Contrairement aux idées reçues, devOps n'est pas seulement l'intervention d'ingénieurs en automatisation et virtualisation, ni seulement le fait de faire collaborer developpeurs de logiciel et ingénieurs d'opérations. Il s'agit d'un mouvement culturel d'entreprise qui vise à faire collaborer les devs et les ops dans un objectif de livraison continue. Cette livraison rend logique et rentable le fait d'automatiser, rendant les livraisons plus rapides, plus fiables et de meilleures qualité. Bref: un cercle vertueux basé sur l'humain et sur la définition de processus de manière autonome (automatiser de mauvais processus ne ferait qu'amplifier ses défauts).
C'est donc toute l'entreprise qui doit se mettre à cultiver des solutions qui lui sont propres à travers l'autonomie, la confiance et la transparence, le plus souvent en étant accompagnée par du coaching de transition.
C'est donc toute l'entreprise qui doit se mettre à cultiver des solutions qui lui sont propres à travers l'autonomie, la confiance et la transparence, le plus souvent en étant accompagnée par du coaching de transition.
Tout en cultivant une façon de travailler propre à chaque équipe, à chaque entreprise, devOps s'appuie sur des frameworks existants, notamment agiles de type scrum. Les référence aux valeurs du Lean (culture de production industrielle définie mise en place chez Toyota) ainsi qu'à ITIL ou Agile Service Management pour veiller à la continuité de service sont récurrentes.
De part sa continuité de production logicielle et sa culture de la sécurité et de la qualité de service, DevOps apporte donc des réponses aux enjeux de la transition numérique (réactivité notamment), de la migration vers une informatique en ligne et de la science des données.
On peut définir devOps en 5 lettres (non valable pour le scrabble) : Culture Lean Automation (automatisation) , Sharing (partge) ==> CALMS
On définit également 3 voies (voir schéma standard) que l'on explore en parallèle:
1. Le flux que l'on cherche à maximiser en levant les contraintes
2. Une collecte optimale, maximale: et diverses de données métiers, techniques et de processus("Si vous le pouvez pas le mesurer, vous ne pouvez pas l'améliorer" Peter Drucker)
3. Expérimentation et apprentissage en continu: Cette obligation d'expérimenter, d'apprendre et de partager implique aussi un droit à l'erreur. Il y a même l'idée d'un devoir d'erreur pour renforcer la résilience: révolutionnaire non ?
L'un des indicateurs les plus significatifs à suivre (même s'il ne se quantifie pas vraiment) dans la mise en place de devOps, c'est le niveau de dette culturelle, c'est à dire l'ensemble de comportement individuels et des dysfonctionnements de l'entreprise qui entravent la création de valeur. Cette "dette" vient alourdir les coûts de fonctionnements (à l'image d'intérêts bancaires) et les changements nécessaires sont difficiles à mettre en place (surtout les changements de comportement), comme un capital dû difficile à rembourser. DevOps contribue à la réduction de la dette culturelle pour rendre les entreprises plus performantes.
Avant d'automatiser la chaine d'intégration continue(CI) / livraison continue(CD), il convient de bien en rationaliser le processus afin de ne pas en amplifier les défauts. C'est pourquoi il est d'usage de bien dissocier le processus (dit pipeline) de la chaine d'outils orchestrés dite toolchain. Mettre en place cette toolchain requiert souvent un ingénieur d'automatisation et de virtualisation dit "ops".
Face à la diversité des activités ainsi regroupées en un modèle collaboratif, le terme coach devOps devient compliqué à percevoir, d'autant qu'il est impossible d'être expert sur tous les sujets allant de l'expression de besoin métier à la continuité de service en passant par le développement et la livraison continue. En fait, on trouve généralement deux profils de coach devOps:
Une grande transversalité de l'expert métier à la continuité de service en passant par le développement et la livraison continue: chacun reste spécialiste de son domaine tout en cultivant une façon de travailler bien alignée sur l'objectif commun de création de valeur client.
Il n'y a pas d'équipe devOps typique. Toutefois, La Voie Agile recommande dans la plupart des cas de s'appuyer sur le modèle d'équipe agile scrum pour l'intégration continue, en y intégrant un Ops pour la livraison continue. La collaboration entre des ops avec les devs permet d'anticiper les besoins en termes de traces, de métriques et de sécurité dès la conception. La prise en compte des réalités héritées et la mise en place de telles équipes (ainsi que leur articulation avec le reste de l'entreprise) méritent une analyse et des conseils spécifiques
De part sa continuité de production logicielle et sa culture de la sécurité et de la qualité de service, DevOps apporte donc des réponses aux enjeux de la transition numérique (réactivité notamment), de la migration vers une informatique en ligne et de la science des données.
On peut définir devOps en 5 lettres (non valable pour le scrabble) : Culture Lean Automation (automatisation) , Sharing (partge) ==> CALMS
On définit également 3 voies (voir schéma standard) que l'on explore en parallèle:
1. Le flux que l'on cherche à maximiser en levant les contraintes
2. Une collecte optimale, maximale: et diverses de données métiers, techniques et de processus("Si vous le pouvez pas le mesurer, vous ne pouvez pas l'améliorer" Peter Drucker)
3. Expérimentation et apprentissage en continu: Cette obligation d'expérimenter, d'apprendre et de partager implique aussi un droit à l'erreur. Il y a même l'idée d'un devoir d'erreur pour renforcer la résilience: révolutionnaire non ?
L'un des indicateurs les plus significatifs à suivre (même s'il ne se quantifie pas vraiment) dans la mise en place de devOps, c'est le niveau de dette culturelle, c'est à dire l'ensemble de comportement individuels et des dysfonctionnements de l'entreprise qui entravent la création de valeur. Cette "dette" vient alourdir les coûts de fonctionnements (à l'image d'intérêts bancaires) et les changements nécessaires sont difficiles à mettre en place (surtout les changements de comportement), comme un capital dû difficile à rembourser. DevOps contribue à la réduction de la dette culturelle pour rendre les entreprises plus performantes.
Avant d'automatiser la chaine d'intégration continue(CI) / livraison continue(CD), il convient de bien en rationaliser le processus afin de ne pas en amplifier les défauts. C'est pourquoi il est d'usage de bien dissocier le processus (dit pipeline) de la chaine d'outils orchestrés dite toolchain. Mettre en place cette toolchain requiert souvent un ingénieur d'automatisation et de virtualisation dit "ops".
Face à la diversité des activités ainsi regroupées en un modèle collaboratif, le terme coach devOps devient compliqué à percevoir, d'autant qu'il est impossible d'être expert sur tous les sujets allant de l'expression de besoin métier à la continuité de service en passant par le développement et la livraison continue. En fait, on trouve généralement deux profils de coach devOps:
- Ceux que l'on appelle coach devOps et qui sont en fait des coachs agiles qui savent implémenter devOps dans ses aspects culturels et organisationnels
- Des coachs techniques qui forment aux outils pour la livraison continue et la virtualisation et qui ont essentiellement un profil d'ingénieur
Une grande transversalité de l'expert métier à la continuité de service en passant par le développement et la livraison continue: chacun reste spécialiste de son domaine tout en cultivant une façon de travailler bien alignée sur l'objectif commun de création de valeur client.
Il n'y a pas d'équipe devOps typique. Toutefois, La Voie Agile recommande dans la plupart des cas de s'appuyer sur le modèle d'équipe agile scrum pour l'intégration continue, en y intégrant un Ops pour la livraison continue. La collaboration entre des ops avec les devs permet d'anticiper les besoins en termes de traces, de métriques et de sécurité dès la conception. La prise en compte des réalités héritées et la mise en place de telles équipes (ainsi que leur articulation avec le reste de l'entreprise) méritent une analyse et des conseils spécifiques
L'agilité à l'échelle
• Répondre à un besoin: l'agilité historique (dite unitaire) a été principalement pensée pour une seule équipe dans une entreprise. Face à son succès, le fonctionnement initial ne suffit plus. Il faut désormais pouvoir coordonner un certain nombre d'équipes (parfois important) autour des mêmes objectifs client tout en maintenant l'autonomie et l'ensemble des valeurs de l'agilité.
Quelques règles fondamentales pour plusieurs équipes travaillant sur un même produit :
Il existe des cadres normalisés dits "frameworks". Vous pouvez aussi composer avec votre existant tout en ayant bien en vous les valeurs agiles pour composer votre propre modèle !
Les principaux frameworks
SAFe:
A la fois riche et complet (parfois trop), mais aussi pyramidal ("nobody is perfect"), le framework SAFe (pour Scaled Agile Framework) tend à s'imposer, notamment auprès des grandes sociétés historiques. S'il a le mérite de ne pas avoir de lacune a priori et d'apporter des solutions viables, il lance un défi à l'agilité: si l'on ne peut pas maîtriser le long terme, le court terme doit être maîtrisé; qu'en est-il du moyen terme ?
Ce "système d'exploitation d'affaires" est un modèle en couches:
Le niveau portefeuille: L'une des grandes forces de ce modèle est cette capacité à agilifier toute l'entreprise, jusqu'au plus haut niveau, ce qui lui permet de mieux coller à l'actualité du marché tant dans sa gestion de budget que dans ses orientations stratégiques. Ainsi, c'est au niveau portefeuille que les orientations stratégiques sont divisées en objets (dits "epics") triés par ordre de priorité et financés. Cette priorisation/financement se fait de façon continue 2 fois par an environ.
Niveau "Large": Pour faire très court, c'est pareil que le niveau programme mis en plus grand. Un niveau large regroupe plusieurs programmes.
Echelon programme: On peut voir le niveau programme comme le coeur du dispositif SAFe. Il s'agit d'une planification collective pour plusieurs équipes alignées sur le même objectif partagé, à échéance de 12 à 12 itérations ("sprints" comme on dit en scrum), soit environ 3 mois. Cette planification passe par une démonstration de la valeur réalisée au cours du programme précédent, une amélioration continue coordonnée, et un ensemble bien cadencé. Ce faisceau d'équipes coordonnées est appelé "train"
Echelon équipes: Pas de changement majeur à ce niveau: chaque équipe du train livre de la valeur de façon continue selon les principes de l'agilité unitaire.
Les 7 compétences fondamentales de l'agilité d'affaire
10 principes
Tout ceci n'est qui bien modeste résumé d'un sujet foisonnant ! Pour plus de formation et de conseil, n'hésitez pas à contacter La Voie Agile !
Quelques règles fondamentales pour plusieurs équipes travaillant sur un même produit :
- Un seul product owner
- Une seule product backlog
- Une même cadence de sprint
- Une seule "Definition of Done"
- Un même livrable intégré en fin de sprint
Il existe des cadres normalisés dits "frameworks". Vous pouvez aussi composer avec votre existant tout en ayant bien en vous les valeurs agiles pour composer votre propre modèle !
Les principaux frameworks
SAFe:
A la fois riche et complet (parfois trop), mais aussi pyramidal ("nobody is perfect"), le framework SAFe (pour Scaled Agile Framework) tend à s'imposer, notamment auprès des grandes sociétés historiques. S'il a le mérite de ne pas avoir de lacune a priori et d'apporter des solutions viables, il lance un défi à l'agilité: si l'on ne peut pas maîtriser le long terme, le court terme doit être maîtrisé; qu'en est-il du moyen terme ?
Ce "système d'exploitation d'affaires" est un modèle en couches:
Le niveau portefeuille: L'une des grandes forces de ce modèle est cette capacité à agilifier toute l'entreprise, jusqu'au plus haut niveau, ce qui lui permet de mieux coller à l'actualité du marché tant dans sa gestion de budget que dans ses orientations stratégiques. Ainsi, c'est au niveau portefeuille que les orientations stratégiques sont divisées en objets (dits "epics") triés par ordre de priorité et financés. Cette priorisation/financement se fait de façon continue 2 fois par an environ.
Niveau "Large": Pour faire très court, c'est pareil que le niveau programme mis en plus grand. Un niveau large regroupe plusieurs programmes.
Echelon programme: On peut voir le niveau programme comme le coeur du dispositif SAFe. Il s'agit d'une planification collective pour plusieurs équipes alignées sur le même objectif partagé, à échéance de 12 à 12 itérations ("sprints" comme on dit en scrum), soit environ 3 mois. Cette planification passe par une démonstration de la valeur réalisée au cours du programme précédent, une amélioration continue coordonnée, et un ensemble bien cadencé. Ce faisceau d'équipes coordonnées est appelé "train"
Echelon équipes: Pas de changement majeur à ce niveau: chaque équipe du train livre de la valeur de façon continue selon les principes de l'agilité unitaire.
Les 7 compétences fondamentales de l'agilité d'affaire
- Lean Agile Leadership
- Agilité d'équipe, agilité technique
- Livraison agile de produits
- Livraison de solution d'entreprise
- Gestion optimisée (lean) de portefeuille
- Agilité organisationnelle
- Culture de l'apprentissage continu
10 principes
- Partir d'un point de vue économique
- Appliquer la pensée système
- Assumer la variabilité et préserver les options
- Construire incrémentalement avec des cycles rapides et apprenants
- Poser des jalons (continus) pour la vérification du bon fonctionnement du système
- Visualiser et limiter le travail en cours, réduire la atille des lots, et gérer la longueur des files d'attente
- Fonctionner en cadence, se synchroniser avec une planification pluridisciplinaire
- Libérer la motivation intrinsèque des personnes compétentes
- Décentraliser les prises de décision
- S'organiser autour de la valeur
Tout ceci n'est qui bien modeste résumé d'un sujet foisonnant ! Pour plus de formation et de conseil, n'hésitez pas à contacter La Voie Agile !
