Archive | agile RSS feed for this section

quelles sont les contraintes dans l’utilisation du Nombre de Dunbar ?

30 juil

Constraints on the use of Dunbar’s Number

https://tcagley.wordpress.com/2015/05/21/constraints-on-dunbars-number/ Par T Cagley

Robin Dunbar

Robin Dunbar

Le nombre de Dunbar représente une limite théorique au nombre de personnes dans un groupe qui peuvent entretenir des relations sociales stables. Des relations sociales stables sont nécessaires pour supporter l’application des valeurs, principes et techniques Agile. Le nombre de Dunbar est souvent cité comme étant de 150 personnes. Cependant, la limite pour n’importe quel groupe est non seulement le reflet d’une limite comme le nombre de Dunbar, mais aussi dépendante du contexte. Si nous acceptons qu’il y a une certaine limite théorique que nous ne pouvons pas dépasser comme le nombre de Dunbar, nous devons nous demander comment d’autres projets ou facteurs exogènes contraignent encore davantage le nombre maximum de personnes travaillant sur un problème. Pourquoi se donner tant de mal pour augmenter le nombre de personnes travaillant sur un problème ? Beaucoup d’Agilistes suggéreraient qu’une unique petite équipe est optimale. Cependant, beaucoup de problèmes exigeront une plus grande collation d’équipes pour délivrer la valeur et la fonctionnalité.

Dunbar NumberLes éléments contextuels supplémentaires qui modifient le nombre maximum théorique de personnes dans un groupe ou une équipe d’équipes incluent au moins quatre facteurs:

1. Cohésion

Ou dans quelle mesure les gens restent ensemble. Il y a beaucoup d’attributs qui peuvent produire la cohésion.

cohesionLes exemples incluent : grandes idées, objectifs, nationalités, religions et même identité d’entreprise.

La cohésion favorise une relation commune qui entraine les groupes à investir volontairement davantage d’efforts pour atteindre un but. Par exemple, il est souvent difficile de réaliser un groupe cohésif quand les membres viennent de multiples et externes entités de conseil. Chaque organisation impliquée dans le groupe a un jeu différent de buts organisationnels qui réduisent la cohésion à moins qu’ils ne soient subjugués par l’objectif du projet. La réduction du nombre de personnes en-dessous du nombre de Dunbar rend plus facile l’utilisation de techniques comme la pression entre pairs pour institutionnaliser une vision de projet qui augmente la cohésion.

2. Complexité

Est une mesure du nombre de propriétés d’un projet qui sortent de la norme.

sketchingLa complexité d’un problème réduit le nombre maximum optimal de personnes qui peuvent être impliquées parce que la complexité exige généralement plus de contrôle et de coordination ou des équipes plus petites pour assurer la collaboration.

3. Incertitude

Survient quand les équipes cherchent une réponse à un problème business ou technique.

small teamQuand une équipe doit aborder un problème métier inconnu ou une nouvelle technologie, de la recherche est souvent nécessaire. La recherche est généralement contrainte à de petites équipes avec des compétences spécialisées ce qui réduit la taille de groupe maximale optimale pour ce type d’effort bien en dessous du nombre de Dunbar.

Comme on découvre des concepts et des idées, certains peuvent être déployés plus largement pour être étoffés, prototypés et implémentés en augmentant le groupe travaillant sur le projet en direction du nombre de Dunbar.

4. Dépendances

Quand elles existent entre des composants, cela signifie souvent que le travail doit être concentré (ou du moins s’étendre moins largement).

effet domino dans les dérivesLes dépendances réduisent le nombre de personnes et d’équipes qui peuvent être efficacement utilisées.

L’idée d’augmenter le nombre de personnes et d’équipes travaillant sur un projet semble souvent être un mécanisme pour délivrer de la valeur plus rapidement. En ajoutant des personnes, il est suggéré de se souvenir que le nombre de personnes travaillant sur un problème est une contrainte qui ne peut pas être traitée en augmentant linéairement le nombre de personnes impliquées sur un problème jusqu’à atteindre une limite comme le nombre de Dunbar.

Le contexte a un impact direct sur la taille que tout groupe peut atteindre avant que l’administration et autres contraintes en réduisent l’efficacité. Il est souvent dit que neuf femmes ne peuvent pas faire un bébé en un mois. En plus du nombre de Dunbar, le contexte joue un rôle important dans la définition de la taille totale de l’équipe.

Précédent billet sur ce sujet: montée en volume d’Agile : le nombre de Dunbar

July 29 – Webinar – PRINCE2 Agile – What’s in it… and what’s in it for me?

21 juil

PRINCE2 Agile™, the new training course and qualification from AXELOS, has just been launched. But what’s in the new product? What does it look like?

Language: English Time: 13:00-14:00 BST (London, UK)

QRP International France

Partenaire de DantotsuPM

This webinar will be presented by Keith Richards, Lead Author and Chief Examiner for PRINCE2 Agile. It’s an opportunity to learn about what is in the course and how you can benefit from PRINCE2 Agile.

This session will look at:

  • Why combine PRINCE2® with agile?
  • What are their respective strengths?
  • Where are the two approaches complimentary?
  • What are the challenges when combining the two?
  • How do you address the common misconceptions of agile and PRINCE2?
  • Why PRINCE2 is NOT a ‘traditional’ approach to project management?
  • How do you create a culture where they can operate together?
  • How do you incorporate Scrum and Kanban?
  • Where does the Scrum Master and Product Owner fit in?
  • What are the benefits? How will it help your organisation?
  • What does the new training course and examination look like?

PRINCE2 Agile combines the flexibility and responsiveness of agile delivery with the established and proven best practice framework of the world’s most recognized project management method. The new guidance explicitly shows how this compatibility can be exploited by organisations harnessing both PRINCE2 and agile, equipping them with the required skills and processes to successfully deliver projects to meet customer requirements in today’s fast moving and rapidly changing environments.

Why not attend and see if PRINCE2 Agile addresses your needs when working in agile environments? You may be surprised by the outcome!

Click Here To Register

Partenaire de DantotsuPM

Partenaire de DantotsuPM

montée en volume d’Agile : le nombre de Dunbar

16 juil

Scaling Agile: Dunbar’s Number

https://tcagley.wordpress.com/2015/05/19/scaling-agile-dunbars-number/ par T Cagley

Robin Dunbar

Robin Dunbar

En déterminant de quelle taille un programme Agile pourrait être, un des « faits » souvent cité est que le nombre de personnes impliqué dans un programme Agile est soumis au nombre de Dunbar. Le nombre de Dunbar est la limite du nombre de personnes dans un groupe qui peuvent entretenir des relations sociales stables. Le terme, relation sociale est le reflet d’interactions régulières, la capacité de reconnaître un autre membre dans le cadre du groupe ou d’être engagés sur un but commun. Ces attributs sont importants pour tout projet et sont peut-être plus importants dans les projets Agile parce que ceux-ci comptent sur la cohésion d’équipe pour minimiser les mécanismes de contrôle et la bureaucratie.

Le concept du nombre de Dunbar est basé sur de la recherche à l’origine exécutée par les observations de primates et étendue ensuite aux humains au début des années 1990. En juin 1992, Robin Dunbar publié « La taille du néocortex comme contrainte de la taille de groupe chez les primates » dans le Journal of Human Evolution (Volume 22, Edition 6, juin 1992, pages 469-493). Dans ce papier, Dunbar a mis en évidence une corrélation entre la taille du cerveau d’un primate et la taille moyenne de groupe social.

En résumé, Dunbar a écrit :

La taille de groupe se révèle être une fonction de volume néocortical relatif, mais les variables écologiques ne le sont pas. Ceci est interprété comme l’évidence en faveur de la théorie d’intellect social et à l’encontre des théories écologiques. Il est suggéré que le nombre de neurones du néocortex limite la capacité de traitement de l’information de l’organisme et que ceci limite alors le nombre de relations qu’un individu peut contrôler simultanément. Quand la taille d’un groupe excède cette limite, le groupe devient instable et commence à se fragmenter. Ceci situe alors une limite supérieure pour la taille des groupes que n’importe quelle espèce donnée peut entretenir comme des unités sociales cohésives dans la durée.

Dunbar Number

Bien que la taille de groupe de 150 soit souvent citée comme le nombre de Dunbar, 150 est une approximation.

Comme indiqué dans le « Les limites d’Amitié » (Limits of Friendship) par Maria Konnikova (7 octobre 2014) le nombre de Dunbar peut aller de 100 à 200 personnes selon des facteurs comme le fait d’être sociable. D’autres limites de taille de groupe ont aussi été publiées par d’autres docteurs comme Peter Killworth et Russell Bernard qui indiquent plus de 200 personnes.

Selon le nombre de Dunbar, le Scaled Agile Framework Enterprise (SAFe) suggère que les plus grandes Releases Agile (ART) pourraient inclure environ 150 personnes. L’ART est supporté par un cadre (le framework SAFe), une hiérarchie ( des ingénieurs de Release et des ScrumMasters) et une bureaucratie (un management de produit et des propriétaires de produits). Quand Agile est pratiqué par une équipe de 5 à 9 personnes cette « surcharge administrative » ne serait pas nécessaire pour assurer la coordination.

croire en soi et ses capacitésLa mise à l’échelle d’Agile est un numéro d’équilibriste entre efficacité des techniques Agiles au niveau de l’équipe et les concessions faites pour contrôler quand Agile est utilisé sur de plus grands efforts.

Historiquement, les très grands projets ont tendance à être moins efficaces. Capers Jones dans Applied Software Measurement, Third Edition (P295) indique que la productivité chute pour tous les types de projets lorsqu’ils excèdent 1000 points de fonction. Les points de fonction sont une méthode du standard ISO pour mesurer la taille du logiciel basée sur un ensemble de règles standard. Tout simplement, plus un projet est grand en points de fonction et plus grande sera l’équipe (ou l’équipe d’équipes) qui devra livrer le projet. D’où le besoin de plus de contrôle toutes choses égales par ailleurs. Il met en exergue (p 307) le fait que comme la taille de projet augmente, la probabilité d’annulation croit pareillement.

Le livre référence

Le livre référence

La montée en volume d’Agile nécessite beaucoup de techniques utilisées au niveau d’une équipe Agile, comme la petite taille d’équipe, le travail par petits lots de fonctionnalités et Scrum. Ces techniques sont très « Lean », mais limitées par la quantité de valeur qui peut être délivrée dans une période spécifique de temps. Comme les projets Agiles grandissent en taille, des techniques supplémentaires sont nécessaires pour maintenir le contrôle. Le nombre de Dunbar (ou des idées similaires) fournit une limite pour essayer d’éviter de laisser un travail devenir trop important pour être gérable. Le nombre agit comme une limite au nombre de personnes impliquées dans un travail. L’application de contraintes supplémentaires, comme des releases ou des incréments de programme SAFe, ajoutent la dimension de temporalité comme contrainte. La combinaison des contraintes sur le nombre de personnes et combien de temps ces personnes travailleront fournit une contrainte explicite de combien de travail peut être livré.

Partenaire de DantotsuPM

Partenaire de DantotsuPM

Why use Agile when PRINCE2 is what you know? FREE download

28 juin
QRP International France

Partenaire de DantotsuPM

Agile expalined for Prince2 Practitioners

Get the ebook

This FREE download follows on from Melanie Franklin’s last one on how to explain Agile to your organisation.

Here Melanie talks about how Big Design Up Front can be replaced, the value of Feedback Loops, how agile delegation works and the importance of networking.

AGILE AND THE EFFICIENT ORGANISATION Part 2

Partenaire de DantotsuPM

Partenaire de DantotsuPM

à propos de Scrum par QRP International

23 juin
scrum methodologie agile

Voici le diagramme du Modèle Scrum

Scrum est une méthode Agile pour la réalisation de projets complexes. A l’origine, la méthodologie Scrum a été élaborée pour le développement de projets IT, mais la méthode s’avère aussi très efficace pour régir tout environnement de travail complexe et innovant. Les possibilités sont donc sans fin. La structure simple de Scrum peut être appliquée à tout type de projet ou développement produit. Scrum peut ainsi fournir une base et une méthode collaborative, saine et agréable pour atteindre les objectifs de l’entreprise.

Scrum est la première méthodologie de développement Agile, utilisée par les Fortune 500 entreprises mondiales. C’est une structure de travail solide et agile qui a déjà prouvé son application à une grande variété de projet et d’équipe. Ainsi la raison d’être de la Scrum Alliance est d’apporter de nouvelles solutions en matière de gestion de projets complexes, et d’ouvrir la méthodologie Scrum et les principes agile au-delà du secteur IT, vers tous les secteurs d’activités.

LES AVANTAGES DE SCRUM

  • Scrum est une approche basée sur l’équipe, comme un moyen pour créer de la valeur pour l’entreprise. Les membres de l’équipe travaillent ensemble pour atteindre un but commun. La méthodologie Scrum vise à encourager les échanges entre les membres de l’équipe pour qu’elle puisse apporter de la valeur à l’entreprise.
  • Scrum exige une avancée du travail de conception du produit fini au début de chaque « Sprint ». Peu importe les activités engagées pendant le « sprint », l’attention est portée la réalisation du produit.
  • Scrum est une méthodologie élaborée de manière à promouvoir et faciliter la collaboration. Les membres de l’équipe collaborent entre eux pour trouver la meilleure solution pour construire et livrer le logiciel, ou autres sortes de livrable, à l’entreprise.
  • Les équipes Scrum font des plans fréquents. Ces plans aident les équipes et l’entreprise à prendre des décisions. Cependant, le but n’est pas que l’équipe suive le plan aveuglément mais de permettre la création de valeur et l’adoption des changements dans l’organisation.

LES FAITS MARQUANTS SCRUM

  • scrum user group francePlus de 368 000 certifiés Scrum Alliance
  • Utilisé dans plus de 175 pays à travers le monde
  • La Scrum Alliance possède approximativement 275 groupes d’utilisateurs à travers le monde. 
  • Utiliser dans de nombreuses industries à travers le monde : développement de logiciel, enseignement, marketing, opération, militaire, automobile et plus encore.

LE ROLE DE SCRUM

cliquez sur l'image pour télécharger ce guide gratuit en français

cliquez sur l’image pour télécharger ce guide gratuit en français

Une équipe Scrum à trois rôles :

  • Le Scrum Master – Soutient l’équipe pour utiliser au mieux Scrum dans l’élaboration du produit.
  • Le Propriétaire du produit (Product Owner) – Maintient la vision du produit.
  • Le Développeur (Development Team) – Construit/élabore le produit.

PARCOURS DE QUALIFICATION SCRUM

La formation et la certification Scrum remplissent la vision du manifeste Agile en favorisant de meilleures collaborations, productivité et succès parmi les membres de l’équipe.

  • La formation Certified Scrum Master® est sur les fondamentaux et s’adresse aux membres de l’équipe Scrum ou les professionnels Scrum Master.
  • La formation Certified Scrum Product owner® expose aux participants les fondamentaux de la méthodologie mais cette fois du point de vue du Product Owner.
  • La formation Certified product Developer® forme les membres de l’équipe Scrum avec des techniques avancées d’ingénierie Agile et d’autres techniques Agile, qu’il est nécessaire de posséder pour la création de logiciels, en complément des fondamentaux Scrum developer.
  • La reconnaissance ultime pour tous les praticiens Scrum, est l’obtention de l’accréditation Certified Scrum Professional® qui permet de prouver sa véritable connaissance et son expérience Scrum.

Pourquoi adopter Scrum avec QRP International

Institut International de Conseil et de Formation Accrédité aux Bonnes Pratiques PRINCE2® (Gestion de Projet), ITIL® (Gouvernance du SI), P3O® (Management d'un PMO) et MSP® (Management de Programme).

Partenaire de DantotsuPM

5-8 Octobre – Québec – Raid AGILE au Québec

10 juin

Du 5 au 8 octobre 2015, le premier RAID AGILE AU QUEBEC, durant la belle saison des couleurs avec nos amis Charlotte Goudreault et Claude Emond !

raid agile quebec 2015

Visitez le site !

Le «Raid Agile au Québec» c’est l’aventure du raid agile qui s’étend dans la francophonie. Le Raid Agile au Québec, c’est 3 jours à explorer, apprivoiser et vivre l’agilité organisationnelle et personnelle dans Lanaudière/Mauricie, à mi-chemin entre Québec et Montréal du 5 au 8 octobre 2015, pendant la belle saison des couleurs d’automne.

Autumn - FallUne façon différente de vivre l’agilité, 3 jours « off » pour penser et co-créer en compagnie de vos co-voyageurs, vos co-participants, Charlotte, Claude, Clodio & Pablo

Ce Raid Agile, c’est une vingtaine de personnes qui se retrouvent au Québec pour une «formAction» agile originale.

Pendant trois jours et trois nuits, ils partagent leurs expériences, jouent ensemble, goûtent à des outils d’intelligence collective, randonnent dans la nature, mangent et boivent des spécialités locales et s’ouvrent l’esprit aux nouvelles pratiques du management, de l’agilité organisationnelle et de la gestion de produit.

Tarif «lève-tôt» pour ceux qui s’inscrivent avant le 1er juillet !

16 Juin – Luxembourg – Agile Interest Group Meetup

9 juin
lux future lab

Next Agile Interest Group Luxembourg Meetup the 16/06 at Lux Futur Lab!

Register now for the event! http://aiglu.org/event/aiglu-meetup/

Visit the web site

Visit the web site

The Agile Interest Group Luxembourg (AIGLU) objective is to foster knowledge sharing between agile practitioners and all interested people alike, promoting agility in Luxembourg (and the Greater Region). Agile software development of course, but not only… Agility outside IT and more generally connections with Lean, Business and Project Management.

Activities
  • Regular think tanks and drinks
  • Events, conferences and workshops
  • Web site (currently reworked)

May 26 – Webinar – Agile Metrics with Don McGreal

11 mai

Scrum Pulse Episode #5 – Agile Metrics

May 26, 2015 7:00 PM – 8:00 PM CEST (France)

Scrum and Agile Webcasts

Scrum and Agile Webcasts

Scrum Pulse is a free monthly webcast by Scrum.org Professional Scrum Trainers addressing common challenges faced by the software profession.

measureIn this interactive webcast, Don McGreal of Improving Enterprises will discuss the disconnect between the delivery organization and the business is prevalent within the software industry. Somewhere along the line, the real vision behind our projects gets lost. We all know it.

Can better metrics help?

In this session, we will examine some common and not- so-common metrics before introducing how we can use them as a guide for continuously measuring business goals, aligning them with software development efforts, and then deciding what to do next.

Save your spot ! Space in each session is limited.

ne vous précipitez pas sur la dette (technique) par Jeff Ball

5 mai

Bien faire ou faire vite? Il y a parfois un prix à payer quand on “fait vite”. C’est ce qu’on appelle la Dette Technique.

facturesMS-DOS est probablement l’exemple le plus connu de Dette Technique. En 1981, IBM demanda à Bill Gates de développer un système opératif pour son nouveau PC. Pour respecter les délais, il prit le QDOS (Quick and Dirty Operating System, Système Opératif Vite fait Mal fait) et le renomma MS-DOS. Bâclé et grossier, MS-DOS a été alourdi par une dette dès sa conception, il était doté d’un ensemble de commandes qui laissaient à désirer et de caractéristiques limitées.

Dans le monde de la gestion de projet, le respect des délais est un point clé pour mesurer la réussite de la plupart des projets. En vous pressant pour respecter les délais, il se peut que vous accumuliez une dette sans vous en rendre compte, silencieusement… mais de manière constante.

La Dette Technique peut prendre les formes suivantes:

  • developer womanDocumentation ou manuel d’utilisation inexistants
  • Programmation de mauvaise qualité (non structurée, avec peu de commentaires, codage en dur)
  • Bases de données mal structurées (données redondantes, erreurs de données)
  • Mauvaise conception (mauvaise architecture, non modulable)
  • Mauvais processus (inefficaces, entraînant une perte de temps, sujets à erreurs)

Habituellement, on parle de dette pour des projets de développement de logiciels, mais elle ne s’applique pas uniquement au software – toutes sortes de projets peuvent générer une dette.

Souvent, la Dette Technique est issue de la pression exercée pour respecter les délais, mais ce n’est pas seulement une question de précipitation.

Plusieurs facteurs peuvent être source de dette :

  • Image courtesy of ambro / FreeDigitalPhotos.net

    Image courtesy of ambro / FreeDigitalPhotos.net

    La vitesse: la précipitation est probablement la première cause de Dette Technique

  • Vision à court terme: rapiéçage et raccommodage. Solutions dénuées d’architectures
  • Contre-la-montre: efforts concentrés sur le retard accumulé (au lieu de penser au futur)
  • Innovation de pointe : apprentissage sur le tas
  • Manque de compétences: assignation de personnel n’ayant pas les bonnes compétences (ou pas de compétences du tout) à des tâches complexes.

Pourquoi s’en inquiéter?

La Dette Technique est comme la dette financière… vous pouvez l’ignorer pendant un temps, mais l’accumulation de dette reviendra vous hanter. En présence de dette, le résultat final sera chaotique – un patchwork ou un sac de nœuds difficile à comprendre ou à changer.

Partenaire de DantotsuPM

Partenaire de DantotsuPM

Ce sera une surcharge potentielle pour tout ce qui sera entrepris par la suite – la Dette Technique peut ralentir et compliquer des projets futurs. Elle peut aussi engendrer un vieillissement prématuré – l’accumulation de dette peut raccourcir la durée de vie de votre solution.

Ne vous précipitez pas sur la dette.

le livre de Chris Sterling

le livre de Chris Sterling

La principale source de dette est la précipitation. Certaines méthodes de gestion de projet se basent sur la rapidité ; c’est le cas de la plupart des variantes légères d’Agile. Ces dernières, comme Scrum, généreront nécessairement une dette si l’on se focalise trop sur la rapidité. Les délais seront peut-être respectés, mais si c’est au prix d’autres facteurs de bonnes pratiques, tels que le design, la planification ou la qualité, alors il se peut que vous accumuliez une dette.

Il existe deux façons de contourner ce problème pour les projets Agile : essayer de rendre cette méthode légère plus robuste (comme décrit dans le livre « Managing Software Debt » de Chris Sterling) ou utiliser une solution Agile.

Pourquoi utiliser Agile?

APMG-AgilePMLes méthodes Agile telles que DSDM Atern (parfois appelée AgilePM) permettent de combiner agilité avec architecture et design. Atern possède également un ensemble d’outils assurant une approche à long terme (plans, étude de rentabilité, etc.) – qui aident aussi à établir le compromis entre rapidité et dette (et par conséquent à éliminer ou réduire la dette).

Quelle que soit la solution que vous choisissiez, que vous utilisiez Agile ou non, vous devez garder cette notion de dette à l’esprit.

Jeff Ball

Jeff Ball

Vous ne pourrez probablement pas vous en débarrasser totalement, mais vous devez appliquer ces trois règles d’or :

  1. Commencez dès aujourd’hui à rembourser les anciennes dettes (chaque nouveau projet rectifie des erreurs et confusions passées)
  2. Évitez de nouvelles dettes (bien faire les choses à l’avenir, équilibrer rapidité et qualité)
  3. Si, pour un projet, vous n’avez pas d’autre choix que de générer une dette, éliminez-la le plus vite possible
Institut International de Conseil et de Formation Accrédité aux Bonnes Pratiques PRINCE2® (Gestion de Projet), ITIL® (Gouvernance du SI), P3O® (Management d'un PMO) et MSP® (Management de Programme).

Partenaire de DantotsuPM

© Copyright QRP International 2011. Reproduction in full or part is prohibited without prior consent from QRP International

Pour aller plus loin:

May 7 – Geneva – Lean Projects Start with a Lean Backlog

24 avr

In order to stay competitive, product development organizations must deliver more valuable products to the market faster.

wikipedia leanThe failure of some organizations to get the right product fast enough has sparked (a much needed and long lasting) debate to find a « perfect » innovation process that could develop any product faster and better than anyone else. New project management methods such as the lean startup, SCRUM, lean product development and so fourth make fairly similar promises to fix very difficult challenges.

The truth is rather that there is no quick fix to deliver great products in such a short time. Instead, successful companies use pragmatic approaches where the solution varies greatly depending on their specific context. One trend places the backlog in the center. It has been proven that, if properly adapted to the context, lean backlog management together with actionable metrics can make a major impact on project success.

The presentation Lean Projects start with Lean Backlog will have three parts:

a summary of some theory behind a great backlog, a walkthrough of two cases from very different organizations with similar lessons learned and finally our suggestions on how to get started with lean backlog management and actionable metrics.

Partenaire de DantotsuPM

Partenaire de DantotsuPM

Suivre

Recevez les nouvelles publications par mail.

Rejoignez 1 327 autres abonnés

%d blogueurs aiment cette page :