Agile SAFe peut-il s’interfacer avec « Waterfall » ?

Le manque de transparence cause des malentendus et des conflits. Générer de la transparence demandes des efforts spécifiques.

Can Agile (SAFe) Be Interfaced With Waterfall? – Transparency

https://tcagley.wordpress.com/2019/01/24/interfacing-agile-safe-be-interfaced-with-waterfall-transparency/ par Thomas Cagley

Dans notre papier blanc Can Agile (SAFe) Be Interfaced With Waterfall? , nous avons identifié trois domaines majeurs qui ont dû être adressés pour qu’un scénario de programmes corrélés avec des approches de management différentes ne cause pas de dramatique accident de train (SAFe).

Le manque de visibilité cause de nombreux accidents sur la route comme dans les projets

Le manque de transparence cause des malentendus et des conflits.

Cependant, générer de la transparence a un coût.

Trouver le bon équilibre qui adapte le coût et les contraintes contractuelles est un objectif de chaque programme compliqué. Produire de la transparence exige un jeu spécifique de comportements.

Plusieurs des techniques les plus communes pour générer de la transparence

#1 – Le Contrat

Spécifiez ce qui peut et doit être partagé dans le contrat.  Énoncer spécifiquement ce qui peut être partagé réduira le niveau de friction quand un programme demande de l’information d’un autre.  Les types d’information qui devraient être mises en commun incluent : risques, problèmes, plans, architecture, échéanciers et le code qui marche (important pour les tests et le développement continu).  Les sujets exclus de partage dans le contrat resteront opaques et seront basés sur des opinions.

#2 – Un Plan construit conjointement

Les leaders du programme et techniques de chaque programme doivent suivre les sessions de planification des autres.  La participation augmentera la conscience du flux de travail, fera remonter des risques et leur permettra de travailler conjointement sur  des risques et communiquer les dépendances en temps réel.

Matchware est partenaire de DantotsuPM

#3 – Des Cérémonies communes

Toute technique agile contient des réunions périodiques (de souvent appelées cérémonies).  Les cérémonies incluent typiquement la planification, les réunions de synchro, les démonstrations et les rétrospectives.  Ces réunions fournissent une plate-forme pour partager l’information ce qui réduit les risques de malentendus et de suppositions.

#4 – Des Ateliers de mûrissement des exigences et de design

travail d'équipeCollecter les exigences et décider des approches de conception fourniront une plate-forme pour apprendre la culture et les personnalités des personnes dans les deux programmes tout en développant aussi une compréhension commune du problème qu’elles adressent.

#5 – Des Modèles de design

L’adoption de modèles de design et autres standards fournit une langue commune et une approche pour que les deux programmes puissent partager l’information et la compréhension.

Facile ET difficile à la fois

une plus grande transparence comme base de relations et de travail

Les étapes deux à quatre sont des actions relativement simples que les deux programmes peuvent prendre pour établir une plate-forme pour la transparence et commencer ensuite à agir sur cette plate-forme. Dans presque chaque scénario, la première étape : le contrat, est l’éléphant dans la pièce. Si le contrat n’est pas écrit pour faciliter la transparence, il n’y a aucune chance que cela arrive.

Montez ou restez dans le train SAFe© avec la 5.0 !

Téléchargez la présentation “What’s New in SAFe® 5.0 ?”

SAFe permet de monter à l’échelle dans l’implémentation de méthodes Agile et de mettre en place gouvernance projet et programme robuste.

Hexagon est partenaire de DantotsuPM

Ce jeu de transparents présente une vue assez détaillée de tous les changements introduits dans le SAFe Framework©.

Téléchargez le document: https://v5preview.scaledagileframework.com/?ddownload=41425
© Scaled Agile, Inc.

CertYou est partenaire de DantotsuPM

SAFe 5.0, une brève avant-première par Henny Portman

Elle arrive bientôt, la nouvelle version de SAFe !

SAFe 5.0 brief preview

https://hennyportman.wordpress.com/2019/10/08/safe-5-0-brief-preview/ par Henny Portman

Au début 2020, une nouvelle version de SAFe sera disponible. Elle est, comme d’habitude, entièrement compatible avec la version précédente SAFe 4.6, permettant une migration en douceur.

Il y a maintenant 7 compétences fondamentales qui permettent l’agilité dans le business. Certaines sont repositionnées et restructurées et 2 nouvelles compétences étendent SAFe afin qu’il englobe l’entreprise toute entière et permettent l’agilité d’affaires. Voir la nouvelle grande image de SAFe.

Les deux nouvelles compétences sont : Culture d’Apprentissage Continu (Continuous Learning Culture / CLC) et Agilité Organisationnelle (OA).

La Culture d’Apprentissage Continu est basée sur trois dimensions : L’Organisation Apprenante (vision partagée, systems thinking, modèles mentaux, apprentissage dans l’équipe, maîtrise personnelle), l’Amélioration Inexorable (un sentiment constant de danger, optimisation de l’ensemble, culture de résolution de problème, Prise de recul aux événements marquants principaux, l’amélioration basée sur les faits) et la Culture d’Innovation (les gens innovateurs, le temps et l’espace, aller voir, expérimentation et réactions, pivoter sans pitié ni culpabilité, innovations à contre-courant).

Les trois dimensions d’Agilité Organisationnelle sont : des gens pensant LEAN et des équipes agiles (house of lean, principes SAFe, Manifeste Agile), des Opérations LEAN (temps de traitement –temps d’attente – temps de traitement) et Agilité de Stratégie.

L’ancienne compétence DevOps et release on demand est maintenant appelée Livraison de Produit Agile (Agile Product Delivery). Ici nous voyons des développements sur la Cadence, la livraison sur demande, DevOps et le Pipeline de Livraison en Continu. Une nouveauté est  la Position Centrée sur le Client Customer Centricity qui comprend : étude de marché, design avec l’utilisateur) et Design Thinking dans la Livraison Agile de Produit.

Livre sur mazon

Les équipes business de l’entreprise montent maintenant ‘sur le train’ et participent à la livraison et au support de solutions business innovantes. Ces équipes adoptent les valeurs, principes et pratiques Lean et Agiles.

Un dixième principe SAFe est ajouté : S’organiser autour de la valeur. Ce principe est basé sur Kotter ‘dual operating system’ comme décrit dans son livre XLR8 – Accelerate. Building strategic agilty for a faster moving world.

Si je prends une vue d’ensemble de la forêt agile, je replace SAFe pour souligner que SAFe couvre maintenant, au niveau produit, cible produit ainsi que le choix de culture.

Voir Bird’s eye view on the agile forest blog pour l’article complet.

Voir le Scaled Agile website pour plus d’information sur SAFe 5.0

Voici pourquoi le #PMI® a acquis Disciplined Agile

ACQUISITION DE DISCIPLINED AGILE PAR LE PMI  (press release)

Livre sur Amazon

C’est pendant l’été, le 12 août, que le Project Management Institute a acquis les

droits sur Disciplined Agile (DA).

 

La boite à outils DA est un ensemble complet de connaissances agiles (un Body of Knowledge – BOK) qui fournit des conseils simples et pratiques pour aider les personnes, équipes et entreprises à décider de leur « façon de travailler » en fonction du contexte.

Parmi les principes clés

  • Être centré sur le client
  • Être pragmatique plutôt que puriste
  • Proposer une large gamme d’options agiles et LEAN
  • Adapter ses pratiques en fonction du contexte
  • Optimiser les flux dans l’ensemble de l’entreprise

CertYou est partenaire de DantotsuPM

Il s’agit pour les organisations d’adapter « leur façon de travailler » à leur contexte.

Disciplined Agile a compris la nécessité de personnaliser toute méthode ou toute approche, traditionnelle et prédictive, Scrum ou SAFe, afin d’obtenir des résultats qui les différencient de leurs concurrents.

La combinaison de PMI et DA offre donc une proposition de valeur nouvelle et attractive. Voici, je pense, pourquoi le PMI a fait cette acquisition. Elle lui permet de rester à la pointe dans le management de projet en utilisant de manière pragmatique des approches Agiles quand cela fait sens pour le projet.

PMI is a registered mark of Project Management Institute, Inc.

Si vous connaissez ou utilisez déjà Disciplined Agile, n’hésitez pas à me contacter pour partager votre expérience sur ce blog.

le rapport annuel de Version One sur l’état de Agile est disponible

The state of Agile Survey de Version One.

  1. Pas de surprise côté méthodes, SCRUM reste fortement majoritaire à plus de 50%, même si l’on commence à voir une percée des approches hybrides.
  2. En ce qui concerne l’agilité à l’échelle, rien de très nouveau. SAFe continue de dominer. Même s’il n’est utilisé que dans moins du tiers des cas, SAFe distance cette année plus largement ses compétiteurs comme Scrum of Scrums.
  3. Le point le plus positif selon moi du rapport est que les bénéfices attendus des projets Agiles sont au rendez-vous et dépassent même souvent les attentes des organisations.

Téléchargez gratuitement le rapport annuel de 16 pages

Merci à Florence Duverneuil pour le pointeur

CertYou est partenaire de DantotsuPM

20 Septembre – Paris – #Agile en Seine

Détails et inscriptions

Agile en Seine se veut une conférence multi-pratiques, ouverte à tous, dont l’objectif est de mettre en avant toute la diversité de ce que l’on nomme communément « Agilité », du Scrum à l’agilité à l’échelle, en passant par le Design thinking, le lean startup, le Lean, L’entreprise libérée, …

CertYou est partenaire de DantotsuPM

Enregistrer

Enregistrer

Comment crever le double plafond de l’Agilité ?

Agilité d’entreprise : Voici comment nous travaillerons demain

Marc-Noël Fauvel

Billet original sur LinkedIn (republié avec l’autorisation de Marc-Noël Fauvel que je remercie)

L’agilité au niveau des équipes de développement a fait ses preuves depuis des années maintenant principalement grâce à SCRUM et XP .

Aujourd’hui, alors qu’elles montent en maturité, les entreprises qui développent leur SI de façon agile sont confrontées à un double plafond qui limite leur capacité à démultiplier leur performance:

1. les projets de développement deviennent de plus en plus importants ; La synchronisation de nombreuses équipes de développement devient de plus en plus complexe et les coûts de transaction rattrapent les coûts de développement. SCRUM n’a qu’une réponse partielle à cette problématique à travers son SCRUM-of-SCRUMS, mais qui reste très conceptuel.

Résultat : plus l’entreprise grossit, plus elle ralentit ;

2. les équipes agiles qui ont acquis une vélocité soutenable, sont contraintes par les prises de décision et les mécanismes de financement qui eux, ne sont pas du tout agiles. L’environnement de l’équipe agile devient alors un frein à la vitesse acquise.

Résultat : plus on cherche à aller vite, plus on est freiné.

Les entreprises ont donc aujourd’hui de réelles difficultés à percer ce plafond de performance. Il faudrait un référentiel qui démultiplie l’organisation agile existant aujourd’hui dans les équipes à travers toute l’entreprise. On parle de référentiel « scalable », car il doit permettre d’être extrapolé quel que soit la taille des projets de développement : 10, 50, 200, 1000 personnes développant les applications en mode Agile.

Ce référentiel, c’est SAFe® (www.scaledagileframework.com)

Scaled Agile Framework web site

SAFe® est une réponse d’une grande élégance à la problématique de la scalabilité agile en entreprise. Ce référentiel s’articule en 3 (ou 4) couches :

1. la couche « Team »

Dans XP/SCRUM, on retrouve l’équipe de développement avec ses deux rôles pivot : le Scrum Master et le Product Owner. La « Team » implémente des incréments de fonctionnalités sur la base de User Stories.

2. la couche « Program »

Avec le SCRUM of SCRUMS, on trouve de nouveaux rôles qui ont pour objectif de coordonner n Teams contribuant à un même programme. On parle d’Agile Release Train (ART®) qui délivre des incréments de systèmes (agrégation de n incréments de fonctionnalités). Les rôles décrits ici sont le Product Manager (leader des Product Owners), le System Architect/engineer, et le responsable du Train de Release, le RTE® (Release Train Engineer) leader des Scrum Masters. La taille d’un ART® est supposée comprise entre 50 et 125 développeurs.

3. la couche « Value Stream » (optionnelle)

Elle est adossée aux principes du Lean management et a pour objectif de synchroniser les différents trains ART®, de façon à livrer des incréments de Solutions à un client final. Une Value Stream peut synchroniser de 2 à 10 ARTs® (ce qui signifie des équipes de 100 à 1250 personnes).

4. la couche « Portfolio »

Elle rend agile la prise de décisions liées aux investissements, permet la priorisation des epics (histoires de haut niveau décrivant les attendus macro) et abonde aux budgets, eux-mêmes associés aux Value Streams. Grâce à ce niveau, les décisions sont fluidifiées et associées aux flux de valeur à destination directe des clients.

Cet édifice est construit autour de principes très structurants, liés à une approche Lean-Agile permanente.

Des implémentations de SAFe® sont opérationnelles depuis plusieurs années maintenant, mais les entreprises qui utilisent SAFe® ne communiquent pas toujours sur leurs retours d’expérience : certaines considèrent en effet l’adoption de SAFe® comme étant un avantage concurrentiel tant les effets positifs sont rapides et puissants.

Il ne fait aucun doute que les entreprises vont basculer progressivement vers ce référentiel. De nombreuses très grandes entreprises l’ont déjà fait : Microsoft, Air France-KLM, Philips, Astra-Zeneca, SwissCom, HP, Cisco, Pôle emploi, Intel, Sony Interactive, etc….

à quand votre tour ?

CertYou est partenaire de DantotsuPM

Enregistrer

Enregistrer

Enregistrer

Enregistrer

14-15 Octobre – Rennes – Agile Tour

La billetterie vient d’ouvrir, profitez des tarifs early-birds jusqu’au 15 août !

Inscriptions et détails
Inscriptions et détails

Agile tour Rennes est un événement « #notheme as a theme » afin de vous laisser l’opportunité de développer votre créativité au travers des conférences ou des ateliers que vous proposez.

Du coup nous avons déjà une belle richesse de thèmes abordés

Transformation Kanban ManagementPensée positiveSAFe SoftWareCraftsmanship Lean StartupLeadership Collaboration Communication Non ViolenteAgilité côté persoFacilitation graphique

Nous sommes toujours en recherche de diversité, voici une liste des sujets sur lesquels nous aimerions avoir des propositions

Open InnovationCulture collaborativePédagogie et AgilitéAméliorer les interactionsEthnologieHistoire de l'agilitéPartage de connaissanceÉtude de psycho-sociologieEntreprise libéréeRetours aux basiquesAteliers pratiques (backlog, user story et tests)Retours aux pratiques de développement

Partenaire de DantotsuPM
Partenaire de DantotsuPM

Et encore une fois, ne nous limitons pas…

Merci par avance pour vos propositions de conférences inspirantes et pour vos retours d’expériences qui viendront alimenter les réflexions de tous les acteurs Rennais.

Enregistrer

Enregistrer

Enregistrer

16-17 Juin – Paris – Agile France 2016

Découvrir, échanger et s’améliorer entre praticiens

Réservez votre place au plus vite !

Au programme cette année, voici quelques-unes des session prévues :

La grande conférence agile francophone, de la communauté pour la communauté

Agile France est une conférence qui offre un espace de respiration et d’oxygénation de nos pratiques, dans l’ambition de faire progresser la communauté sans être élitiste.

  • On y parle de méthodes agiles…
  • On y parle d’intelligence collective et de facilitation…
  • On y parle de motivation, d’émotions et de bien-être au travail…
  • On y parle de développement de logiciels, de technique, d’artisanat…
  • On y parle de produit, d’expérience utilisateur et d’innovation…
  • On y parle d’organisations, de gouvernance et de management…

…mais pas seulement. On y parle de soi, de ses expériences, de ses échecs, de ses idées. Et on ne parle pas de business.

Scrum of Scrums : l’essentiel pour appliquer Agile à de plus larges efforts

Scaling Agile, Scrum of Scrums – The Basics

https://tcagley.wordpress.com/2015/06/23/scaling-agile-scrum-of-scrums-the-basics/ par Thomas M. Cagley

Scrum Stand upLa technique Scrum of Scrums (SoS) sert à augmenter la portée de Scrum et autres techniques Agiles et les appliquer à de plus grands efforts. Sur le papier, le SoS est une simple extrapolation des réunions quotidiennes de Scrum ou stand-up meeting qui sont devenues le label de la pratique Agile. Une typique réunion debout se produit chaque jour pour que tous les membres de l’équipe puissent coordonner et planifier les activités du jour. Classiquement, l’équipe utilise la technique des trois questions pour organiser la réunion. De la même manière, une session Scrum of Scrums typique agit comme un focus pour aider à synchroniser une équipe d’équipes ou même plusieurs équipes d’équipes.

Il y a quatre basiques pour SoS qui doivent être compris avant toute adaptation.

1. Qui participe

Scrum Stand up egalitarianIl y a deux écoles de pensée dans le choix des participants au SoS. La première (et plus commune) école suggère que le Scrum Master soit présent lors du SoS. Le Scaled Agile Framework Enterprise (SAFe) est un exemple d’une méthodologie qui met à profit le Scrum Master tant pendant l’événement de planification que pendant l’incrément de programme. Alors que le deuxième groupe adopte une approche plus égalitaire (probablement plus pragmatique) permettant à chaque équipe de choisir un participant qui peut le plus facilement transmettre ou comprendre que les problèmes actuels de l’équipe et du plus grand groupe à cet instant. Par exemple, si les décisions de conception sont primordiales, peut-être des membres de l’équipe avec la grande compréhension UX. Dans ce scénario, les participants varieraient au fil du temps.

2. Qui facilite

Pour de petits SoS, par exemple une poignée d’équipes co-localisées, une facilitation peut ne pas être exigée. Le SoS peut s’auto-organiser et exécuter la réunion avec peu de facilitation additionnelle. Cependant, comme le nombre de participants augmente (je limite les réunions SoS en utilisant la même règle 5 à 9 membres utilisée dans les équipes Scrum) ou comme la distribution géographique des membres s’accroit, la facilitation devient plus importante. Les facilitateurs aident l’équipe à utiliser la pratique du SoS, s’assurent que la logistique est en place et gèrent le temps. Dans de plus grands efforts, un Directeur de Programmes fournit souvent la facilitation, ou si vous pratiquez SAFe, le Release Train Engineer joue ce rôle de facilitateur.

3. Fréquence

Image courtesy of pakorn / FreeDigitalPhotos.net
Image courtesy of pakorn / FreeDigitalPhotos.net

Le Scrum of Scrums suit souvent le même modèle que la réunion quotidienne de Scrum/Stand-Up. Un deuxième modèle de fréquence est basée sur le niveau de risque; la fréquence des réunions SoS varient en fonction du besoin. Tôt dans un projet le SoS se tient quotidiennement comme les équipes se forment, se trouvent et que les premières décisions sont construites. La réunion SoS passe à deux fois par semaine au milieu du projet et revient ensuite à quotidienne comme une fin de release approche.

4. Format

Les réunions quotidiennes debout déroulent généralement la classique approche avec trois questions (Qu’ai-je fait ? Que vais-je faire ? Et quels sont mes points de blocage ?).

La réunion Scrum of Scrums suit généralement un format TRÈS SEMBLABLE avec chaque participant qui répond aux quatre questions suivantes :

  1. Qu’est-ce que mon équipe a fait depuis la dernière réunion ?
  2. Que fera-t-elle avant que nous ne nous rencontrions de nouveau ?
  3. Mon équipe rencontre-t-elle des points de blocage ?
  4. Mon équipe va-t-elle délivrer quelque chose qui est sur le chemin d’une autre équipe ?

La réunion suit la même approche : chaque participant interagit à tour de rôle avec les autres. Le facilitateur (si utilisé) ne devrait jamais être au centre de la réunion, et le SoS ne devrait pas dériver en une réunion de statut d’avancement.

Le stand-up quotidien et le SoS Sont des réunions très semblables. Les deux réunions sont tenues pour partager des informations, coordonner des activités et identifier des problèmes. Le périmètre de la réunion SoS est plus large qu’une seule équipe et cette réunion fournit la coordination et les activités de planification dans et transverses aux équipes.