Devops for Growth
90.3K views | +0 today
Follow
 
Scooped by Mickael Ruau
onto Devops for Growth
Scoop.it!

→ Comment j'ai récupéré 5000 euros avec le mot "Super" dans un compte rendu de projet ★ Any Ideas

→ Comment j'ai récupéré 5000 euros avec le mot "Super" dans un compte rendu de projet ★ Any Ideas | Devops for Growth | Scoop.it
Le compte rendu est un outil très puissant, souvent sous-estimé et qualifié "d'inutile", voici un exemple d'utilisation qui permet de sauver son budget :
No comment yet.
Devops for Growth
For Product Owners/Product Managers and Scrum Teams: Growth Hacking, Devops, Agile, Lean for IT, Lean Startup, customer centric, software quality...
Curated by Mickael Ruau
Your new post is loading...
Your new post is loading...
Scooped by Mickael Ruau
Scoop.it!

Construire l’aptitude à garantir la Qualité : les enseignements du modèle CMMI

Construire l’aptitude à garantir la Qualité : les enseignements du modèle CMMI | Devops for Growth | Scoop.it
Le CMMI permet d'adapter et améliorer ses pratiques pour créer plus de valeur en ligne avec ses objectifs stratégiques et garantir la Qualité
Mickael Ruau's insight:

e modèle CMMI dont les origines datent du milieu des années 1980 a été complètement refondé en 2017 pour mettre l’accent sur la performance des entreprises. Il impose en particulier d’analyser les activités mises en place -et les activités permettant de garantir la qualité comme les autres – à l’aune de la valeur qu’elles créent.

Cette création de valeur n’est pas immédiate et absolue. En se basant sur le concept de niveau de maturité, le modèle CMMI organise dans chaque domaine, les pratiques en groupes permettant d’améliorer progressivement la valeur créée. Nous avons illustré dans un précédent article comment s’organise cette création progressive de la valeur. Trois groupes de niveau sont fondamentaux

  • Le premier niveau, initial, s’assure que les concepts sont en place, que le travail est fait.
  • Le second niveau, discipliné, permet d’optimiser la création de valeur en organisant et focalisant les efforts sur les éléments essentiels pour chaque organisation
  • Le troisième niveau, standardisé, améliore encore cette création de valeur en capitalisant au niveau de l’organisation les pratiques et les outils qui ont démontré leur efficacité.
No comment yet.
Scooped by Mickael Ruau
Scoop.it!

Management 3.0 partie 2 : la décentralisation du contrôle

Management 3.0 partie 2 : la décentralisation du contrôle | Devops for Growth | Scoop.it
Pour en finir avec le "command and control", le Management 3.0 est un bon outil pour aider les équipes à s'auto-organiser.
Mickael Ruau's insight:

Un exemple d’application

Il y a quelque temps, j’ai accompagné des équipes opérationnelles dans l’adoption d’une approche agile et avec leur responsable. Elle est en charge de ces équipes depuis environ six mois, nous avons convenu de travailler de manière ciblée sur la délégation afin que les deux équipes deviennent plus autonomes et qu’elle puisse par conséquent diminuer ses interventions qui, dans certains cas, faisaient d’elle un véritable « goulot d’étranglement ».

 

Nous avons organisé un atelier par équipe, dans le but de créer pour chacune d’entre elles une première version du tableau de délégation à utiliser ultérieurement pour planifier et réaliser de manière structurée les actions visant à améliorer les niveaux de délégation. J’ai d’abord eu une séance individuelle avec la manager, au cours de laquelle je lui ai demandé de créer et d’alimenter des tableaux de délégation par elle-même, en dressant la carte de ce qu’elle pensait être la situation actuelle de sa délégation aux équipes. Ce tableau de délégation n’a pas été directement proposé aux équipes afin d’évaluer la différence entre sa perception et celle des collaborateurs.

 

Les deux ateliers ont débuté par une introduction de la manager sur les raisons pour lesquelles elle considérait ce travail important, suivie d’une explication des sept niveaux de délégation et du tableau de délégation. Ensuite, j’ai animé une discussion ouverte sur les niveaux de délégation dans les différents domaines de décision proposés par elle et éventuellement intégrés ou modifiés par les équipes. Dans ces cas, il est possible d’utiliser un jeu appelé « delegation poker », créé par l’équipe de Management 3.0, qui est engageant et amusant, mais dans ce contexte, j’ai considéré qu’une méthode moins structurée était plus efficace.

 

Pour chaque équipe, nous avons consacré environ deux heures de temps et le résultat a été que, dans les deux cas, le tableau de délégation précédemment compilé par la manager présentait des niveaux de délégation inférieurs à ce que les membres de l’équipe percevaient en réalité. Elle a elle-même admis que la comparaison avait rendu beaucoup plus claires certaines dynamiques de prise de décision dans des domaines opérationnels sur lesquels elle avait une connaissance moins approfondie.

 

L’activité a permis à chacun de partager sa vision sur la manière dont les responsabilités décisionnelles étaient réparties dans les équipes et de commencer à planifier certains changements en vue d’améliorer la satisfaction client, en éliminant certaines étapes jugées superflues et en prévoyant un soutien pour aider certains des collaborateurs à accroître leur confiance pour intervenir de manière indépendante dans certains domaines.

 

Conclusion

Les sept niveaux de délégation, le tableau de délégation et le « délégation poker » ne sont que quelques exemples de la façon dont, avec quelques outils de soutien et peut-être l’aide d’un coach agile, vous pouvez intervenir rapidement pour créer de l’implication sur ces sujets. Dans ce cas nous avons travaillé autour de la délégation. Mais la même méthode pourrait être utilisée sur la motivation, la façon de mener un meeting, le tout avec une forte orientation vers l’action concrète et immédiate.

 

No comment yet.
Scooped by Mickael Ruau
Scoop.it!

Comment réussir le mariage de l’Agilité à l’échelle et de la gestion de projet classique ?

Comment réussir le mariage de l’Agilité à l’échelle et de la gestion de projet classique ? | Devops for Growth | Scoop.it
Agilité à l'échelle - Retour d’expérience de la mise en œuvre dans le groupe Orange de mécanismes de type large solution SAFe.
No comment yet.
Rescooped by Mickael Ruau from LEAP EntrepreneurshiԀPassion - lasting enterprise action practices
Scoop.it!

The Operating System Canvas. A new and improved tool for reinventing… | by Aaron Dignan | The Ready

The Operating System Canvas. A new and improved tool for reinventing… | by Aaron Dignan | The Ready | Devops for Growth | Scoop.it
Need this in German? Lesen Sie diesen Artikel auf Deutsch! Need this in French? Lisez cet article en Français! Organization design is hard. Whether you’re the CEO of a global corporation, the founder…
Via Oliver Durrer swissleap.com
No comment yet.
Scooped by Mickael Ruau
Scoop.it!

"Je lance mon 1er train" : Quelques clés pour un démarrage rapide

"Je lance mon 1er train" : Quelques clés pour un démarrage rapide | Devops for Growth | Scoop.it
Vous êtes acteur(trice) du changement au sein de votre organisation, RTE ou coach interne et vous devez organiser votre premier PI planning
No comment yet.
Scooped by Mickael Ruau
Scoop.it!

Contrats informatiques - Méthodologie Agile et contrats de développement - Révolution ou adaptation ?

Contrats informatiques - Méthodologie Agile et contrats de développement - Révolution ou adaptation ? | Devops for Growth | Scoop.it
Dans un tel cas, les conditions techniques et financières associées à chaque nouvelle itération serait fixée par voie contractuelle dans le cadre d’accords opérationnels de type contrats d’application.
Mickael Ruau's insight:

 

La faculté de sortir du projet de manière anticipée est un des traits distinctifs de la démarche Agile. Le client doit, en effet, pouvoir arrêter le projet quand il le souhaite sans contrainte autre que de rémunérer le prestataire pour les prestations déjà effectuées. Les divers « sprint backlogs » étant envisagés comme des modules fonctionnels autonomes, le client doit en effet pouvoir en conserver l’usage sans qu’il soit nécessaire de repartir de zéro comme c’est souvent le cas dans un projet de type « cascade ».

A l’inverse d’un contrat au forfait classique, la faculté de sortie de projet ne sera normalement pas subordonnée au versement d’une indemnité compensatrice par le client. Le risque de non-poursuite du projet aura en effet été appréhendé par le prestataire Agile comme une composante de son offre et intégrée dans sa grille de risque. Ce risque est le corollaire nécessaire de l’absence d’engagement global, en termes de forfait et de délais notamment, sans lequel l’économie d’un contrat Agile pencherait trop fortement en faveur du prestataire [15].

Il importe toutefois de veiller à ce que cette faculté de sortie sans contrepartie ne soit pas requalifiée en condition purement potestative rendant nulle la clause de dénonciation ou de résiliation insérée dans le contrat (article 1174 du Code civil). Ainsi toute clause faisant dépendre de la simple manifestation de volonté du client la poursuite ou non des prestations prévues au projet pourrait encourir un tel grief particulièrement en l’absence de mécanisme de compensation financière au profit du prestataire.

Afin de conjurer ce risque, deux méthodes nous paraissent envisageables :

(i) faire dépendre la mise en œuvre chaque nouveau « sprint » d’un accord de volonté préalable entre les parties sur le périmètre, les délais ou le prix

Dans un tel cas, les conditions techniques et financières associées à chaque nouvelle itération serait fixée par voie contractuelle dans le cadre d’accords opérationnels de type contrats d’application. Le contrat conclu à l’origine se rapprocherait alors fortement d’un contrat cadre renfermant les conditions générales ayant vocation à régir l’ensemble des contrats d’application qui seraient signés dans le cadre du projet.

No comment yet.
Scooped by Mickael Ruau
Scoop.it!

Les méthodes agiles : de la souplesse dans les contrats informatiques - LE MONDE DU DROIT : le magazine des professions juridiques

Les méthodes agiles : de la souplesse dans les contrats informatiques - LE MONDE DU DROIT : le magazine des professions juridiques | Devops for Growth | Scoop.it
Le Monde du Droit est le magazine des professions juridiques, toute l\'actualité des professionnels du droit, legalnews, avocats d\'affaires, directeurs juridiques, responsables juridiques, juristes d\'entreprises
Mickael Ruau's insight:

 

Le projet Agile s’analyse moins en une course de fond épuisante qu’en une succession et la qualité du code de la solution qui deviennent l’étalon-mesure du projet, plutôt que la conformité à un cahier des charges initial vieux de plusieurs mois. Les Méthodes Agiles sont donc pragmatiques, mais elles impliquent une évolution des mentalités et de l’économie du contrat.

Cet aggiornamento ne doit donc pas s’arrêter aux seules équipes techniques : le juriste qui encadre le projet, tout comme la Direction Générale qui en décide, doivent être sensibilisés aux Méthodes Agiles, et comprendre que les objectifs (couverture fonctionnelle, sécurité juridique, efficacité économique) peuvent être atteints autrement, à condition de renoncer à certains réflexes. L’aspect protéiforme des Méthodes Agiles permet également aux prestataires informatiques de proposer leur propre « offre Agile » et d’y puiser des avantages concurrentiels. A l’instar des logiciels libres, les Méthodes Agiles sont issues de la pratique, et permettent manifestement de tels gains de valeur qu’elles impliquent désormais une révolution culturelle au sein de l’entreprise. La protection frileuse du code source ou la relation classique « client-prestataire » sont parfois des freins à l’efficacité des projets IT. On constate au contraire que l’innovation, loin d’être menacée par ces nouvelles propositions, est en fait décuplée.

Quant au juriste, il relève précisément de son office de s’approprier ces nouveaux concepts pour leur apporter une traduction juridique et contractuelle pertinente. Le contrat ne peut être un monolithe intangible, théâtre du rapport de forces entre le client et son prestataire et checklist des engagements réciproques : il doit aussi s’adapter aux évolutions opérationnelles et accompagner l’émergence de nouveaux concepts pour en assurer l’efficacité.

A leur arrivée en France, les licences Open Source avaient défrayé la chronique. On les disait intransposables en droit français, anti-économiques, voire utopistes… On constate aujourd’hui qu’elles se sont multipliées au point d’innerver la plupart des projets informatiques. Plus aucun juriste français ne songe à les combattre, et elles témoignent de ce qu’une autre conception du droit d’auteur est possible et souhaitable. Si le contrat IT leur permet de s’épanouir, peut-être en ira-t-il de même des Méthodes Agiles ?

No comment yet.
Scooped by Mickael Ruau
Scoop.it!

Contrat Agile : L’engagement à la carte

Ces cinq dernières années ont vu l’inéluctable progression des méthodes Agile au sein des SSII, au prix d’un nouveau chamboulement des modèles de production, pourtant eux-mêmes mis en place avec force et rigueur durant une décennie d’industrialisation de l’ingénierie logicielle. Cette période tendait en effet à apporter la fiabilité, la sureté et la maturité promise par l’industrie logicielle. Par Sébastien Lachèvre, Directeur de projet Banque & Assurance chez Gfi Informatique.
Mickael Ruau's insight:

 

Ces propriétés de la matière Agile permettent d’élaborer un certain nombre d’outils qui serviront à la construction d’offres de service adaptées aux contextes les plus variés. Nous pouvons présenter quelques-uns de ces outils en les scindant en deux catégories : les outils de forfaitisation et les outils d’engagement.

Les outils de forfaitisation

• Prix fixé. C’est la clause qui rassurera tous les acheteurs. L’engagement, au travers de l’évaluation de la backlog, est ferme en termes de nombre de points de complexité et donc, par transitivité, en terme de coût !

• Délai fixé. Dans la mesure où le dispositif mis en place est évalué pour permettre de produire un ensemble de points déterminés et que les sprints respectent les boîtes de temps, le délai peut être considéré comme fixe.

• Le bonus/malus. Il s’agit d’un système d’évaluation du niveau de la qualité. En évaluant un certain nombre d’indicateurs de qualité, on construit une part de variable sur le coût de développement initial. Les formules et indicateurs pris en compte peuvent varier en fonction des clients et de leur niveau de maturité à les mesurer.

Les outils d’engagement sur la valeur produite

• Engagement sur la production de 80 % du nombre de points de complexité initialement évalué lors de la constitution de la backlog. L’objectif de la règle est d’induire un certain niveau de variabilité sur le contenu fonctionnel en acceptant que le changement puisse provoquer un écart de plus ou moins 20% par rapport à l’évaluation de départ. En somme il s’agit de partager le risque inhérent à la gestion de spécifications émergentes.

• Clause de changement gratuit. C’est le pendant de la règle précédente, l’intégrateur accepte les demandes de changement, propres à la construction de spécifications émergentes. Evidemment ces changements sont conditionnés d’une équivalence de points de complexité entre les demandes sortantes et les demandes entrantes. Mais la variabilité de 20 % induite par la règle précédente permet de s’assurer du risque.

• Partage des gains et des pertes. Cette règle, couplée à la première, est attachée à la notion de facturation de la valeur et non de la dépense. Elle se propose de reporter, sur le coût global du projet, l’écart entre la valeur évaluée dans la backlog de départ et la valeur réellement produite. Cela peut être assimilé à la notion de bonus/malus appliqué au périmètre fonctionnel.

• Clause Gagnant-Gagnant. Cet outil permet au client d’arrêter le projet après la production d’un sprint, considérant que le logiciel lui suffit en l’état, ou que finalement il n’a plus d’intérêt au regard de l’enjeu de départ. Le fournisseur se trouve dédommagé en touchant 20 % du montant restant à produire. L’objectif est de limiter les risques pour le client, notamment dans le cadre d’une innovation, et de lui permettre de garder la main sur la continuité du dispositif mis en place.

Une stratégie portée sur la valeur

A partir de ces éléments il est possible de définir un mode de contractualisation prenant en compte le niveau de maturité des acteurs et les risques associés. On le voit, les possibilités sont nombreuses et n’ont pour seule limite que l’imagination des acheteurs et contractants.

No comment yet.
Scooped by Mickael Ruau
Scoop.it!

Méthode agile et responsabilité du prestataire informatique

Le Tribunal de commerce de Paris a commencé par noter que « les erreurs relevées, les réponses quelquefois tardives, la difficulté de s’accorder sur des prestations qui apparaissent entre les cocontractants ne dérogent pas à la norme de ce type de construction en l’absence de cahier des charges et ne présentent pas de caractère anormal ».

Prenant en compte notamment :

l’absence de cahier des charges et donc l’absence d’expression de ses besoins par le client,
la signature des procès-verbaux de recettes sans réserve,
le paiement du solde des factures « confirmant ainsi [l’accord de la cliente] sur la production des applications »,
que c’était à la cliente de « vérifier par test les concordances des fonctions des applications à ses attentes » et non au prestataire, à qui il n’incombait pas une telle obligation au titre du contrat signé, contrairement à ce que soutenait cette première.

Les juges saisis ont débouté la société cliente de l’intégralité de ses demandes.
No comment yet.
Scooped by Mickael Ruau
Scoop.it!

Contrat au forfait et démarche agile - Scrum, Agilité & rock'n roll

Une discussion récente avec un acheteur d’une grande administration m’a conforté dans l’idée que le contrat au forfait n’est pas un obstacle à l’introduction de l’agilité. Au contraire, l’agilité apparaît comme une voie à suivre pour éviter les difficultés rencontrées dans les contrats actuels.
Voici un petit résumé des quelques idées que je lui ai présentées, reprises de ma contribution au livre de Véronique Rota :
Mickael Ruau's insight:

Partant de ce principe qu’il est impossible de définir le périmètre fonctionnel à l’avance, le client fournit simplement sa vision du projet dans l’AOA. Le périmètre deviendra la variable d’ajustement.

Sélection sur les compétences

La sélection du fournisseur est faite sur la qualité de la réponse, la pertinence du processus (agile) proposé et sur les compétences de l’équipe pressentie. Le changement par rapport à la pratique d’évaluation actuelle des réponses à appel d’offres est que le prix n’est pas considéré, puisque c’est le client qui le fixe. Le contrat avec le fournisseur est toujours un contrat au forfait, avec prix et date fixés.

Mais c’est un contrat au forfait agile (CFA) qui se différencie du contrat classique parce qu’il impose une livraison à la fin de chaque itération et parce que le périmètre fonctionnel, défini initialement dans la vision, est ajustable.

Avec un CFA, l’objectif du client n’est plus de reporter les risques sur le fournisseur, il devient de collaborer avec lui pour obtenir le meilleur produit dans le délai défini.

Point de vue du client

Les clauses du contrat sont adaptées à l’agilité. Voici quelques exemples de ce qu’il est possible d’y introduire, pour le bénéfice du client :

  • le client doit recevoir un produit partiel, mais fonctionnel, à la fin de chaque itération : il peut ainsi fournir un feed-back rapide ;
  • le client peut arrêter le contrat à la fin de chaque itération (en contrepartie d’une indemnité fonction du temps passé pour le fournisseur ) : il peut ainsi stopper à temps un projet voué à l’échec ;
  • le client définit les priorités : le fait de développer les fonctionnalités à forte valeur ajoutée en premier permet de lever les risques tôt (risques techniques, bien sûr mais surtout risques de livrer un produit en inadéquation avec les attentes) ;
  • le client peut changer d’avis sur le contenu fonctionnel (sur les parties qui n’ont pas encore commencé), à condition que ce qu’il ajoute au backlog (terme Scrum pour désigner la liste des choses qui apportent de la valeur au client et qui sont à faire par le fournisseur) soit contrebalancé par ce qu’il y retire.

Point de vue du fournisseur

Du point de vue du prestataire titulaire d’un contrat avec un client qui a remporté l’appel d’offres :

  • si c’est dans un cadre agile (réponse à AOA puis CFA), c’est évidemment plus simple puisque le client est déjà convaincu de l’intérêt de l’agilité. Je suggère au fournisseur d’annexer le backlog dans le contrat. Ce backlog est élaboré soit par le client lors de l’AOA, s’il a déjà une idée précise de ce qu’il veut, soit conjointement par le prestataire et le client, lors d’une première phase de recueil des besoins (appelée Sprint 0 dans Scrum). En associant à chaque élément du backlog une estimation en points, le dialogue avec le client sur les évolutions du périmètre fonctionnel et les négociations éventuelles sera grandement facilité.
  • si c’est dans le cadre d’un forfait classique, l’agilité du fournisseur est limitée par le contrat. Le fournisseur peut néanmoins introduire des pratiques agiles (livraisons fréquentes avec des itérations courtes pour commencer), essayer de collaborer au maximum avec le client, le sensibiliser à l’idée des tests qui pilotent le développement (TDD) et le convaincre de passer au forfait Agile pour le prochain appel d’offres.

Le fait de montrer rapidement au client le résultat des itérations et de l’impliquer dans les réunions de planification favorise sa confiance et le met ainsi dans de meilleures dispositions, l’incitant à s’impliquer davantage.

No comment yet.
Scooped by Mickael Ruau
Scoop.it!

Table Ronde : Contrat et Agile – De sa rédaction aux contentieux | Agile Paris

Table Ronde : Contrat et Agile – De sa rédaction aux contentieux | Agile Paris | Devops for Growth | Scoop.it

Table Ronde : Contrat et Agile – De sa rédaction aux contentieux

Animée par Elisabeth Ducarre, Coach international en organisation Agile & Lean, cette table ronde fera le point sur les Contrats Agiles. Nous accueillerons à cette occasion différents acteurs importants de l’Agile dont 2 avocats spécialisés dans le droit des affaires et ayant rencontré des projets agiles face à la justice. L’idée sera d’en apprendre un peu plus sur les manières d’établir des contrats agiles. Une table ronde terminera la matinée.

 

“La contractualisation agile, à la Poste, c’est possible ! Saison II – Le contrat en action”, Michel LEJEUNE

Petit rappel de la saison I “le contrat type”, avec les mécanismes clefs du contrat open source : http://www.contrat-agile.org/
Le contrat en action, c’est d’abord l’avant contrat avec le cahier des charges du Client et la réponse du Prestataire. Du coté Client, on parlera du Document de Vision, du Plan produit, du Backlog Produit (macro estimé), et des User Story étalons. Coté Prestataire, on parlera évaluation du Backlog Produit en Story Points, dimensionnement de l’Equipe et Vélocité de référence. Ensuite, c’est un premier retour d’expérience sur un projet qui a terminé sa “Phase de lancement” en mai dernier et qui est maintenant en “Phase opérationnelle” avec suivi des Indicateurs du PQS, Comité de pilotage, Pénalités et tout le toutim…

Pitch :
La saison 1 : Elle a commencée au moment où les Agilistes, prêts à affronter toutes les incertitudes de l’IT avec des techniques de cheminement hautement adaptatives, décident d’affronter le désert du Sourcing agile pour atteindre l’Engagement de résultat. Ils s’allient à la vénérable guilde des Juristes, bien connus pour être capable d’élaborer des “Contrats” susceptibles de protéger leurs signataires de tout ce qui pourrait leur arriver et même de l’Imprévisible …
Elle se termine après presque 2 années d’errances riches en péripéties pendant lesquelles Agilistes et Juristes finissent par mettre au point « Un contrat agile type »

La saison 2 : Il s’agit maintenant d’apprendre à utiliser le « Contrat agile type », beaucoup de Seigneurs du SI sont intéressés, mais ont du mal à accepter leurs nouveaux engagements, ils somment les Agilistes et de leur faire un « modèle de Cahier des charge agile ». Du côté des Fournisseurs, c’est aussi la peur de l’inconnu qui domine et puis finalement…

Biographie :
Issu de l’industrie de l’aéronautique et de l’électronique de pointe, passé par l’informatique industrielle et l’imagerie médicale, c’est après 25 ans d’activités et à près de 45 ans que je suis frappé par l’agilité ! Ayant rejoint en 96, la DSI du Courrier où, je dirige un centre de compétence de “Génie logiciel”, c’est lors premiers XP Days des années 2000 que je découvre que la plupart des pratiques qui m’avaient attiré et réussi plus tôt dans mon parcours, portaient un nom et comptaient de nombreux supporters … Fin 2008, je suis naturellement appelé au chevet du premier projet Agile de la DSI du Courrier, un projet stratégique de 80 personnes sur 18 mois ! Ce fut ma première occasion, à l’aide de 3 coachs expérimentés de mettre Scrum en pratique, vu le contexte, ce fut sportif … Depuis, je suis chargé de la transition agile de la DSI du Courrier et je coache certains projets du, voire j’assure temporairement le rôle de Scrum Master si nécessaire.

 

 

 

 

 

Mickael Ruau's insight:

Contractualisation Agile, contentieux et médiation, Sylvia Israel et Thomas Beaugrand

Notre intervention vise à rendre compte de l’expérience d’avocats quant à la contractualisation Agile et aux relations avec les expertises et les contentieux autour de projets informatiques. Elle portera également sur l’intérêt d’intégrer la médiation à la démarche Agile en cas de dérive du projet ou préventivement, l’agilité étant peu adaptée aux règles du contentieux judiciaire classique.

Biographie :

Thomas Beaugrand est Avocat au Barreau de Paris, associé du Cabinet Staub & Associes. Son activité porte principalement sur le droit de l’informatique et de la communication électronique, le droit de la propriété intellectuelle, la protection des données à caractère personnel, et de manière générale sur le droit des contrats et le contentieux commercial. Il est l’auteur de plusieurs articles juridiques sur l’agilité.
Sylvia Israel est Avocat au Barreau de Paris, collaboratrice du Cabinet Staub & Associes. Son activité porte principalement sur le droit de la propriété intellectuelle, le droit de l’informatique et des nouvelles technologies, mais également sur le droit des contrats et le contentieux commercial. Elle est également médiateur et a choisi comme thème de mémoire les liens entre l’agilité et la médiation.

No comment yet.
Scooped by Mickael Ruau
Scoop.it!

L’externalisation agile s’est fourvoyée

L’externalisation agile s’est fourvoyée | Devops for Growth | Scoop.it

L’externalisation agile s’est fourvoyée dans un type de contrat qui privilégie la posture de contrôle du client lors de l’introduction des rituels Scrum de codage, jusqu’à en perdre l’esprit. Voyons quels sont les freins à desserrer et les idées anciennes auxquelles il convient de renoncer pour réunir les conditions d’une contractualisation agile, collaborative et donc partenariale. Regardons pour cela les liens entre les méthodes de développement et les principales modalités d'externalisation.

No comment yet.
Scooped by Mickael Ruau
Scoop.it!

Étude sur les salaires de 2021

Étude sur les salaires de 2021 | Devops for Growth | Scoop.it
Découvrez les résultats de notre étude 2021 sur les salaires du secteur agile. Êtes-vous payé à votre juste valeur ?
No comment yet.
Scooped by Mickael Ruau
Scoop.it!

Management visuel sur les projets : un levier pour le management d’entreprise

Management visuel sur les projets : un levier pour le management d’entreprise | Devops for Growth | Scoop.it
On connaît les vertus du management visuel pour les équipes projet. On doit également s'intéresser à son apport pour le top management.
No comment yet.
Scooped by Mickael Ruau
Scoop.it!

Que peut-on bien encore apprendre sur le Kanban ?

Que peut-on bien encore apprendre sur le Kanban ? | Devops for Growth | Scoop.it
La méthode Kanban est formidable car elle est simple à comprendre et à mettre en place. Elle s’adapte à votre contexte.
No comment yet.
Scooped by Mickael Ruau
Scoop.it!

Comprendre et utiliser le modèle CMMI #2 - Gouvernance & pratiques

Comprendre et utiliser le modèle CMMI #2 - Gouvernance & pratiques | Devops for Growth | Scoop.it
Gouvernance : comment ancrer les pratiques dans une organisation. Le cycle de mise en place de nouvelles pratiques au sein d’une organisation est bien connu
No comment yet.
Rescooped by Mickael Ruau from LEAP EntrepreneurshiԀPassion - lasting enterprise action practices
Scoop.it!

10 Progressive Organizational Structures Developed By Real Companies

10 Progressive Organizational Structures Developed By Real Companies | Devops for Growth | Scoop.it
So, I recently came across an old tweet of Jurgen Appelo, in which he asks: "Apart from Holacracy, the "Spotify model" and Liquid Organization, what other frameworks/models do you know for adaptable org structures?" It made me reflect on all the different "adaptable organizational structures" we've come across over the last years. Here is the (not so exhaustive) list I managed to come up with.... for now.
Via Oliver Durrer swissleap.com
No comment yet.
Scooped by Mickael Ruau
Scoop.it!

Contrat agile et pilotage par la valeur

Contrat agile et pilotage par la valeur | Devops for Growth | Scoop.it
Découvrez comment transformer vos contrats informatiques en contrat agile basé sur la valeur pour favoriser la collaboration avec vos fournisseurs.
Mickael Ruau's insight:

 

La contractualisation sur la valeur

Si agilité et contractualisation ne vont pas naturellement de pair, le contrat demeure l’instrument indispensable de la sécurité juridique des projets.
Simplement, le contrat ne doit pas constituer un frein à l’agilité mais  être flexible, s’adapter à ce type de projets. Le contrat a vocation à porter ce type de pilotage par la valeur et à définir les droits et obligations des parties
dans ce contexte. L’articulation entre un contrat-cadre fixant et des contrats d’application permet de piloter un projet par la valeur.
Le contrat-cadre définit les clauses contractuelles générales, la collaboration, la gouvernance et les mécanismes d’arbitrage et de gestion du changement, que ces changements soient à l’initiative du client (évolution de périmètre) ou du  prestataire (évolution de sa performance). Par exemple, le contrat-cadre détermine la capacité à produire du prestataire avec une marge de manœuvre suffisante pour absorber les changements sans nécessité de renégocier le contrat. Le contrat-cadre fixe également la durée du contrat, les cas de sortie et les conséquences de la résiliation du contrat. Il définit enfin le nombre d’itérations par contrat d’application et leur longueur pour inscrire le projet dans une temporalité faite de courtes itérations et faciliter la sortie du projet, en fonction de la valeur créée ou en cas d’échec en associant des mécanismes financiers adaptés au modèle économique du prestataire.
Le contrat d’application formalise une valeur cible, valorisée en cost of delay, ainsi qu’une valeur minimum à produire. Le contrat d’application décrit également le périmètre sous forme de fonctionnalités ou de user stories, valorisées en story point.
Ce périmètre permet de piloter les changements et leur impact sur la valeur produite et corrélativement, le coût du story point.
La contractualisation agile sur la valeur substitue ainsi des mécanismes de partage des bénéfices de la valeur produite, d’arbitrage et de gestion du changement aux mécanismes classiques dont la négociation peut s’avérer longue et difficile. C’est particulièrement le cas des clauses « dures » relatives à la responsabilité, aux pénalités et à la nature de l’obligation du prestataire, à la définition du périmètre et aux cas de résiliation du contrat. Côté client, les mécanismes d’arbitrage et de « change for free » couplés aux mécanismes de gestion du changement et de sortie facilitée du contrat fixent les bornes de manière souple. Côté prestataire, un engagement de valeur acquise minimum vient se substituer à l’obligation de résultat avec une variation du prix de l’unité d’effort en fonction de la valeur produite par itération et de sa qualité. Le prestataire est ainsi incité à augmenter sa productivité et sa capacité à faire pour livrer au plus tôt de la valeur. Attention toutefois à ne pas vouloir pousser à l’excès la vélocité au risque de mettre en péril la qualité !
C’est bien à l’équipe de décider des éléments sur lesquels elle s’engage en début de sprint sur la base d’une vélocité acceptable.

No comment yet.
Scooped by Mickael Ruau
Scoop.it!

Comment rester Agile quand vous devez signer un Contrat ?

Comment rester Agile quand vous devez signer un Contrat ? | Devops for Growth | Scoop.it
Le développement Agile avec un contrat validé par des avocats paraît impossible. La nature des processus d'achat et de contractualisation s'oppose aux principes Agiles. Voici un retour d'expérience d'un fournisseur coopérant avec un client pour développer un projet ambitieux de façon Agile, en le découpant en petits bouts tout en préparant un contrat basé sur la confiance mutuelle.
Mickael Ruau's insight:

 

D'après la description de ce projet, nous concluons qu'il est possible de développer un énorme projet en Agile en le découpant en petits morceaux. Cela prend du temps de le définir et de préparer le contrat, mais l'effort est récompensé. En passant beaucoup de temps ensemble au début du projet, nous avons compris nos désirs et besoins réciproques. Cette compréhension mutuelle forgea une confiance partagée avec le bon niveau de coopération, et ceci grâce au temps investi en amont.

 

No comment yet.
Scooped by Mickael Ruau
Scoop.it!

Méthodes agiles : comment donner de l'agilité à un contrat au forfait (2e partie)

Méthodes agiles : comment donner de l'agilité à un contrat au forfait (2e partie) | Devops for Growth | Scoop.it
Comment concilier un développement itératif avec le contrat au forfait ? C'est tout l'enjeu de la formulation contractuelle des méthodes agiles qui repose sur une séparation du cahier des charges et des modalités du contrat. Un tour de force nécessaire pour passer à l'agilité. Et s'accorder entre donneur d'ordre et prestataire sur la facture qui en découle.
No comment yet.
Scooped by Mickael Ruau
Scoop.it!

Contractualisation agile : Sujet brulant, comment faire ?

Contractualisation agile : Sujet brulant, comment faire ? | Devops for Growth | Scoop.it
Aujourd'hui, presque 20 ans après l’écriture du manifeste agile, 90% des sociétés disent avoir lancé des projets informatiques utilisant les techniques agiles. Les projets agiles sont bâtis sur un paradigme : gérer un périmètre non spécifié au début du projet dans un détail défini et permettre changement et priorisation en cours de projet. Si cette ouverture ravit le métier qui ne sait en général pas tout ce dont il aura finalement besoin, cela semble contraire à l'esprit d'une contractualisatio
Mickael Ruau's insight:

 La contractualisation agile doit créer une situation Win-Win

 

Une étude du Standish Group sur la fréquence d'utilisation des fonctions des logiciels met en évidence que seulement 21% des fonctionnalités développées sont vraiment utilisées. Ca vous parait aberrant? Et bien, posez-vous la question de combien de fonctionnalités vous utilisez usuellement dans Excel - Sachant que ce tableur a une profusion de possibilités et d'automatisations possibles...

 
 
 

Partant de ce constat, on intègre généralement dans le contrat agile une incitation à finir plus tôt.

 

C'est la notion du "Money for Nothing" qui conduit à l'arrêt des développements dès que le ROI (return on investment - logique de coût/bénéfice) n'est plus suffisant.

 

En bref, en application du principe MoSCoW (Must-Have/Should-Have/Could-Have/Would-Have), dès que les fonctionnalités Must & Shoud Have sont développées, Product-Owner et Stakeholders doivent se demander pragmatiquement ce qui mérite encore que l'on dépense de l'argent dessus.

 
 
 

Pour que ce soit incitatif, 20% (classiquement) du budget économisé revient alors au fournisseur en tant que prime de performance.

 
 
 

En conclusion

 

Vous le voyez, contractualiser l'agile est possible. Le meilleur conseil que l'on puisse vous donner, c'est de ne surtout pas partir sur un contrat "au forfait" et de faire de l'agile en interne.

No comment yet.
Scooped by Mickael Ruau
Scoop.it!

L’obligation de collaboration du client dans un contrat Agile- Articles Droit de l'informatique - lexgo.be

L’obligation de collaboration du client dans un contrat Agile- Articles Droit de l'informatique - lexgo.be | Devops for Growth | Scoop.it
Toute l'info Droit de l'informatique IP/IT/TELECOM avec LexGo en collaboration avec Mr. Alexandre Cruquenaire Avocat
Mickael Ruau's insight:

 

Comment formaliser la collaboration du client dans un contrat Agile ?

La nécessaire collaboration du client doit être effective dès le début du processus Agile. Pour cela, la méthode de pilotage doit être contraignante. Elle doit intégrer des modalités d’exécution du projet spécifiques dans le champ contractuel.

Cette formalisation des processus de gestion du projet va permettre de conscientiser le client sur son nécessaire apport à la réussite du projet.

Une implication accrue du client est donc requise dans la phase de développement, essentiellement lors des réunions avec l’équipe du prestataire où les décisions seront prises :

  • points à développer lors du sprint,
  • définition et évaluation des résultats,
  • etc.

Le client doit alors veiller à mettre à disposition du projet suffisamment de ressources. Les clauses fixant des obligations de disponibilités, délais de réaction, etc. sont donc courantes dans la pratique des contrats Agile.

Quelles sont les conséquences de l’obligation de collaboration ?

Dans cette même optique de responsabiliser les parties sur leur nécessaire implication dans le processus Agile, des clauses de limitation de la responsabilité du prestataire en cas d’absence de collaboration du client nous paraissent essentielles. Si elles sont parfois jugées sévères, elles se justifient totalement. En effet, la commune intention des parties est bien de conduire le projet sur la base d’une méthode collaborative. On ajoutera que la collaboration insuffisante du client peut sans doute être qualifiée de manquement fautif aux obligations contractuelles dans le cadre d’un projet Agile dont ladite collaboration est une pierre angulaire.

De son côté, le prestataire sera attentif au fait que l’intensification du devoir de collaboration du client a pour conséquence un alourdissement proportionnel de son devoir de conseil. En effet, plus le client doit s’impliquer et prendre des décisions, plus il doit pouvoir se reposer sur les connaissances et conseils du prestataire pour le faire. On insistera donc sur la nécessité de documenter d’une manière suffisante :

  • les conseils donnés et
  • les décisions prises

afin de couper court à toute discussion ou contestation sur ces éléments en cas de problème ultérieur.

Que faire en l’absence de collaboration du client lors d’un projet Agile ?

Pour éviter un blocage lié à un manque de réactivité du client, il peut être tentant de prévoir des mécanismes d’acceptation tacite. Toutefois, une telle solution ne fait que reporter le problème. Le client risque de contester plus tard une décision qu’il n’aurait pas prise. De plus, cela ne correspond pas à l’esprit d’un processus collaboratif.

Cependant, des clauses de gouvernance peuvent permettre de clarifier les rôles et les procédures de décision. Elles ménagent des mécanismes qui évitent les blocages tout en stimulant l’implication des parties dans la prise de décision.

No comment yet.
Scooped by Mickael Ruau
Scoop.it!

ACEONE | Pourquoi les entreprises peinent-elles à contractualiser en Agile

ACEONE | Pourquoi les entreprises peinent-elles à contractualiser en Agile | Devops for Growth | Scoop.it
La notion d’obligation de résultat est incompatible avec l’application des méthodes Agiles : c’est faux !

En méthode classique : l’obligation de résultat est matérialisée par la présence de livrables encadrés avec des SLA (Service Level Agreement).

En méthode agile : on ne connait pas les livrables à l’avance puisqu’ils seront définis après la contractualisation et systématiquement au début de chaque sprint. Néanmoins le prestataire s’engage au début de chaque itération à livrer un « Potentially Shippable Produt (produit fini qu’on peut plugger dans le système et le rendre fonctionnel) : cela constitue de fait sa première obligation de résultat. Un livrable qui ne serait pas potentiellement opérationnel n’est pas un livrable et le prestataire peut être soumis à des pénalités s’il ne respecte pas le jalon de l’itération.

Ainsi le prestataire est tenu de respecter certaines obligations qui peuvent faire l’objet d’un pilotage avec l’aide de plusieurs indicateurs comme par exemple : la productivité d’une itération, la qualité technique ou fonctionnelle du livrable intermédiaire, de la satisfaction du client (basée sur un sondage régulier par exemple) ou sur la capacité du prestataire à prédire des difficultés ou des opportunités. Il est utile de rappeler qu’on peut parfaitement déclencher des pénalités sur la base de ces indicateurs.

En dehors des ses obligations en termes de résultats objectivables techniques, le prestataire doit aussi s’engager à respecter des modes de collaboration bien définis comme par exemple : assister à tous les comités de co-direction, être présent sur site lorsque l’équipe est en difficulté ou lors des ateliers de priorisation avec le client, à toujours maintenir un climat de confiance avec devoir d’alerte systématique, etc…

En conclusion, la principale difficulté à la contractualisation en Agile repose non pas sur une technicité accrue dans la rédaction des contrats, mais plutôt sur l’acceptation d’un état d’esprit qui vise à maîtriser davantage le cadre & la manière que le contenu à l’instar des méthodes plus traditionnelles.
No comment yet.
Scooped by Mickael Ruau
Scoop.it!

Ten contracts for your next Agile project

Ten contracts for your next Agile project | Devops for Growth | Scoop.it
As a customer or supplier of software services at the beginning of an Agile software development project, you know that there is too much at stake […]
Mickael Ruau's insight:
 
 

Ten contracts for your next Agile project, by Peter Stevens
Table of contents

7.8. Fixed-Profit
 
You can download the e-book or pre-order the physical book at https://saat-network.ch/ten
No comment yet.
Scooped by Mickael Ruau
Scoop.it!

Mesurer la Prédictibilité en Kanban – Part II : Le Débit des Cartes

Mesurer la Prédictibilité en Kanban – Part II : Le Débit des Cartes | Devops for Growth | Scoop.it
La transformation des équipes ou organisation vers les méthodes agiles et particulièrement Kanban ou ScrumBan prend de plus en plus d’ampleur dans l’écosystème des organisations. Cette adhésion, ou la volonté d’expérimentation, des organisations aux méthodes Kanban est portée par la capacité d’un système Kanban à produire des métriques permettant une visibilité forte sur la capacité…
Mickael Ruau's insight:

 

La mesure de la prédictibilité par le débit nous offre également une indication assez fiable de la date prévisionnelle d’atterrissage de notre Release.

Le calcul de base est simple et tient compte des éléments suivants :

La formule appliquée est la suivante :

Nous divisons simplement le nombre de Stories restant à réaliser, ainsi que le nombre d’anomalies à corriger, avec une estimation du nombre d’anomalies prévisionnelles que nous serions amenés à avoir et tenant compte du ratio d’anomalies/story terminée.

Le débit est calculé sur une semaine (5 jours ouvrés) et nous fournit donc le nombre de semaines nécessaires afin de réaliser l’ensemble de notre Backlog de Produit.

Jusque là rien de compliqué, sauf que le débit est mesuré sur la capacité d’une équipe sur une période. Qu’en est-il de la fiabilité du débit lorsque cette capacité vient à baisser ou augmenter ?

Afin de pallier ce risque, la charge de l’équipe ayant permis de mesurer le débit, ainsi que la charge de l’équipe sur laquelle doit se baser la prédictibilité doit être prise en compte, ce qui nous donne la formule suivante :

Ou :

 

No comment yet.