le poids de la dette technique

Technical Debt

par Derek Huether

La dette technique et la dette de design sont des métaphores synonymes se référant aux conséquences finales d’une pauvre architecture logicielle et d’un développement logiciel à la va vite. La dette de code se réfère à la dette technique dans un code de programmation de logiciel.

Ward Cunningham a fait la comparaison entre la complexité technique et la dette dans un rapport de retour d’expérience 1992 :

La livraison du premier code ressemble au fait de s’endetter. Une petite dette accélère le développement tant est qu’elle soit remboursée promptement par une réécriture … Le danger se présente lorsque la dette n’est pas remboursée. Chaque minute passée sur du code pas tout à fait exact s’ajoute alors aux intérêts de cette dette. Des organisations entières d’ingénierie informatique peuvent parvenir à un blocage total sous le poids des dettes d’un développement non consolidé qu’il soit orienté objet ou pas.

Les développements réalisés en amont dans le projet peuvent augmenter le coût “du remboursement de la dette” à l’avenir. Une équipe devrait saisir les occasions, sur une base régulière de rembourser (ou régler) cette dette. Réservez un pourcentage de votre cycle de développement ou dédiez un cycle entier pour compléter ce travail. Si vous ne le faites pas, il reviendra vous hanter. Si votre bidouille de solution ne revient pas pour mordre l’équipe de développement, elle hantera probablement le « help desk », l’équipe de support, ou quelqu’un d’autre en aval.

Comme toute dette, vous vous trouvez devant l’obligation de la rembourser tôt ou tard. En tant qu’ancien Manager de Génie logiciel et maintenant que conseiller auprès de mes clients, j’ai vu (et vois) ce que la dette technique peut avoir comme impact sur la vélocité d’une équipe. Elle les prive de temps précieux, après coup. L’équipe de développement achète l’idée que faire les choses de la mauvaise manière, fait gagner du temps dans l’intérim et que cela justifie les risques et le coût total. C’est vraiment un processus de pensée à court terme. La dette technique ressemble à l’obtention d’un prêt d’usurier qui jetterait les dés pour décider de votre taux d’intérêt. Aussi, si vous n’êtes pas absolument obligés de prendre le risque, ne le faites pas.

Soyez honnête avec votre client, votre équipe et vous-même. Évaluez votre travail et tenez vos estimations. Ne laissez pas quelqu’un d’autre vous dire combien de temps il faudra pour livrer un travail de qualité. Si vous y êtes forcés, vous devrez juste délivrer moins de travail. Donc, ne prenez pas de dette en premier lieu.

Plus sur la dette technique sur Wikipedia

comment convaincre votre directeur financier d’utiliser SCRUM

How to Convince Your CFO to Use Scrum

parJan Van den Nieuwenhof

Convaincre votre directeur financier (Chief Financial Officer: CFO) et autres cadres sup de votre société d’utiliser Scrum est en réalité très simple, dans la théorie. Essayez cette stratégie la prochaine fois vous devez aider des exécutifs à comprendre pourquoi Scrum est un processus important et utile pour le développement logiciel.

Selon mon expérience, les experts financiers et les directions sont très attentifs à savoir ce qui arrivera si de certaines situations se produisent et veulent souvent simuler des scénarios dans leur stratégie de management des risques.

stop arrêt de projet "no go"La meilleure approche dans cette situation est d’exposer la valeur business que vous livrerez si le projet devait s’arrêter en cours d’exécution.

Il y a plusieurs raisons pour lesquelles des projets de développement de logiciel sont arrêtés avant leur date de fin :

  • sévères compressions budgétaires
  • changement de priorités de projet,
  • la société a été rachetée
  • le budget approuvé n’est pas suffisant pour couvrir le périmètre complet du projet

En justifiant au management pourquoi utiliser utiliser Scrum il y a quelques années, nous avons posé cette question à la direction : Et si le projet devait être arrêté à environ 60 % de son effort ou calendrier ?

Pour cette démonstration, nous avons comparé deux projets. Le projet W, est exécuté dans une approche traditionnelle en cascade (Waterfall). Le projet S, utilise une approche agile.

Le projet W a un modèle de réalisation et une dépense typique par phase :

  • 10 % du temps/effort concernent la préparation et la définition du projet
  • 25 % du temps/effort sont passés sur une analyse minutieuse du livrable logiciel
  • 40 % du temps/effort sont passés sur le développement et les tests de système
  • 20 % du temps/effort concernent les tests d’intégration et de recette ainsi que les corrections de bogue
  • 5 % du temps/effort sont requis pour mettre le logiciel en production et le lancer avec les clients.

Comme vous pouvez voir, si on ordonne à l’équipe d’arrêter le développement à 60 % du parcours dans ce processus nous serons en réalité en plein milieu de l’écriture de code et de l’exécution de quelques tests système. Dans ce scénario, « la valeur » que le projet W délivre à la société est en fait un tas de documents d’analyse et un morceau de logiciel non testé.

Maintenant jetons un coup d’œil au modèle de dépense du Projet S, fonctionnant en mode Scrum:

  • 10 % du temps/effort concernent la préparation et la définition du projet
  • 85 % du temps/effort sont passés à analyser, développer et tester des incréments de fonctionnalités qui sont livrés itérativement dans des « sprints » bihebdomadaires
  • 5 % du temps est nécessaire pour clôturer correctement le projet

Si le Projet S doit s’arrêter à 60 % en temps ou en effort dépensé, l’équipe aura déjà complété une bonne quantité de sprints  et délivré un certain logiciel utilisable. Dans ce scénario, le projet S délivre une valeur réelle et des fonctionnalités utilisables (probablement environ 40 % à 50 % du produit total) au client.

Dans l’entretien avec la direction, nous avons utilisé un graphique sur la valeur acquise pour mieux illustrer notre point. Il inclut les suppositions suivantes :

  • Le démarrage et la définition d’un projet / produit correspondent à 0 % de la valeur totale
  • La documentation d’analyse et de conception représente 15 % de la valeur totale
  • Le code source avec les tests unitaires système correspondent à 35 % de la valeur totale
  • Le logiciel complètement testé et packagé représente 50 % de la valeur totale

Notre directeur financier et les autres cadres supérieurs ont décidé de commencer à utiliser Scrum pour nos développements de nouveaux produits parce qu’ils croient fermement que, d’une perspective de management des risques de la société, il vaut mieux utiliser Scrum qu’un développement par phase.

le site de microsoft projet en français
Partenaire de DantotsuPM

spécialistes et généralistes dans une équipe projet

Specialization and generalization in a team

Par Bas Vodde

La spécialisation est un sujet chaud dans Scrum depuis de nombreuses années. Cette discussion surgit à chaque cours Scrum que je donne. C’est un sujet important et approprié pour une nouvelle équipe dans son premier Sprint.

La spécialisation arrive quand j’explique aux gens que d’après la définition de Scrum, une équipe doit être cross-fonctionnelle. Je recommande aussi aux membres d’être à 100 % dédiés à une équipe (ils ne sont pas membres de multiples équipes). La plupart des personnes qui sont nouvelles sur Scrum l’acceptent sans considérer les implications. Parfois quelqu’un demandera : « mais que fera la personne des tests au début du Sprint ? »

Il y a un couple de suppositions derrière cette question. La première supposition : le test peut seulement commencer après que le développement soit fait. Cette supposition courante n’est pas vraie. En adoptant des pratiques modernes comme l’ Acceptance Test-Driven Development, les tests commencent avant que le développement n’ait commencé. La deuxième supposition est qu’un spécialiste des tests peut seulement faire des tests. J’ai personnellement constaté qu’une plus grandes compétences des personnes est qu’elles peuvent apprendre de nouvelles choses! Aussi, je ne tiens pas non plus cette supposition pour être vraie.

La question peut être généralisée : « Que fait une personne avec la spécialisation bleue quand il n’y a aucun travail bleu ». « Bleu » pourrait être tester, développer l’interface utilisateur, coder en Java, en C, réaliser changements sur la base de données, écrire la documentation ou autres choses de la sorte. Cela arrive presque toujours dans une équipe utilisant Scrum. Pourquoi ? Regardons le scénario dans l’image ci-dessous.

Dans cette équipe, les membres de l’équipe sont spécialisés – rouge, vert, bleu, violet et noir. Tous les membres sont dédiés à cette équipe et ont une responsabilité partagée de réaliser tout le travail du Sprint Backlog. Le Product Owner choisit le travail sur la base de sa valeur pour le client. Si la priorité numéro 1 pour choisir le travail est la valeur pour le client, quelle chance y-a-t-il que le travail s’équilibre parfaitement sur les compétences dans l’équipe ? Dans la plupart des équipes avec lesquelles j’ai travaillé, la probabilité est proche de 0 %. Donc, dans la plupart des équipes (particulièrement dans les plus grandes organisations), il y a une disparité entre le travail à réaliser et les compétences de l’équipe.

C’est cette disparité qui amène les gens à dire : « Scrum nécessite des généralistes! »

Cette conclusion est incorrecte. Une disparité entre compétences et pré-requis ne signifie pas que chacun dans l’équipe doit pouvoir tout faire. C’est une erreur de raisonnement typique que de penser que le monde est binaire avec seulement deux possibilités : spécialiste ou généraliste.

La vérité est que « le spécialiste dans exactement un seul sujet » et le « généraliste » sont les extrêmes sur l’échelle de spécialisation. Il y a beaucoup de personnes entre ces deux extrêmes ! Par exemple, je peux être principalement un spécialiste bleu, mais je peux aussi savoir faire du violet et du noir. Je pourrais ne pas être aussi efficace que le super spécialiste violet, mais je me débrouillerai.

Trouver la bonne balance dans la spécialisation

Quand une équipe prend vraiment la responsabilité partagée pour tout le travail d’un sprint cela crée le besoin d’équilibrer la spécialisation. Les personnes dans l’équipe doivent apprendre un peu de la spécialité de chacune des autres. Cela ne signifie pas que tous les membres de l’équipe doivent être des généralistes, mais plutôt que les membres s’éloignent de l’autre extrême – être spécialisé dans un unique domaine. Les membres de l’équipe apprennent de multiples spécialités, mais probablement jamais toutes.

L’équilibre dans la spécialisation aboutit à l’équipe dynamique

  • La spécialisation est utilisée quand c’est la manière la plus rapide de produire de la valeur.
  • Il y a des opportunités pour les membres de l’équipe d’avoir de multiples spécialisations.
  • Il y a des opportunités pour les membres de l’équipe de se concentrer sur leur spécialisation tant qu’ils produisent de la valeur.
  • Une disparité entre compétences actuelles et nécessaires crée automatiquement de l’apprentissage dans l’équipe

Regardons celles-ci une par une :

spécialiste bleuspécialisted rougeMaximisez la spécialisation quand c’est possible

Si une équipe consiste en deux spécialistes bleus et deux spécialistes rouges et que le travail bleu est choisi, le spécialiste bleu fera probablement le travail. La plupart des équipes se rendent compte qu’il y a de la valeur dans la spécialisation, donc, quand nous pouvons utiliser la connaissance spécialisée des personnes, nous le faisons. De plus, les membres de l’équipe deviennent activement spécialistes sur des secteurs particuliers parce que cela augmente la productivité de l’équipe.

Opportunités de spécialisations multiples

multi compétences« J’ai été un spécialiste bleu pendant beaucoup d’années. Au Sprint suivant un peu de travail bleu et un peu de rouge sont choisis. Les membres de l’équipe peuvent prendre le travail bleu pour que je puisse apprendre une nouvelle spécialisation rouge. » Beaucoup de personnes veulent activement apprendre de nouveaux secteurs. Cela garde le travail intéressant et leur connaissance fraîche. Dans une équipe qui équilibre la spécialisation l’opportunité d’étendre ma spécialisation devrait exister.

Opportunités de se concentrer sur une spécialisation

« Je me suis plongé dans rouge pour les derniers Sprints. J’avais toujours voulu être un spécialiste rouge. Donc, sur les Sprints suivants, si il y a du travail rouge, je voudrais le faire. » Les personnes à l’intérieur d’une équipe ne devraient pas être forcées d’apprendre une nouvelle spécialisation. Tant que leur connaissance crée la valeur pour le client, elles peuvent continuer à se concentrer sur leur spécialisation. L’équipe devra manager la situation quand il n’y a absolument aucun travail dans un secteur de spécialiste – d’habitude en cassant la spécialisation.

Apprentissage automatique

Si l’équipe consiste principalement en des spécialistes bleus et que les Sprints suivants ont principalement des besoins violets, l’équipe doit casser leurs spécialisations et apprendre le violet. Si le Sprint suivant est constitué principalement de besoins verts, ils devront casser de nouveau la spécialisation et apprendre le vert. Plus les secteurs de compétences dans les besoins changent plus l’équipe devient généraliste. Si le secteur de compétences dans les besoins ne change pas beaucoup alors l’équipe devient plus spécialisée.

Impact sur l’organisation

L’équilibre dans la spécialisation s’est produit dans chaque équipe Scrum avec laquelle j’ai travaillé. Cela cause souvent des conflits dans les premiers Sprints où les nouveaux membres de l’équipe crient « j’ai été bleu pendant des années ! Je ne ferai pas du violet ! » L’équipe devra résoudre ce conflit en apprenant comment travailler en équipe. Un bon ScrumMaster facilite la résolution de ces conflits dans l’équipe.

Les structures et les règles dans beaucoup d’organisations rendent le bon équilibre de la spécialisation plus difficile à trouver. Par exemple, si je suis le spécialiste bleu et sur un plan de carrière bleu et que j’ai un directeur fonctionnel bleu », alors voudrais-je apprendre le violet ? Probablement pas car ce serait nuisible à mon statut et ma carrière. De même, si j’ai pour objectif de performance de devenir encore plus bleu, alors sortir de ce secteur de spécialisation ne se produira pas.

Un autre obstacle commun consiste en ce quand l’organisation « se débrouille autour du goulot d’étranglement de spécialisation » en allouant à temps partiel les gens à de multiples équipes. Cela empire même la situation car il n’y aura aucune motivation du tout à casser les goulots d’étranglement de spécialisation dans ces organisations.

Les ScrumMasters doivent identifier ces dynamiques organisationnelles et essayer de les supprimer. C’est un travail difficile car il exige de changer l’organisation. Quand les obstacles organisationnels tombent, trouver le bon équilibre dans la spécialisation arrivera ‘automatiquement’ dans les équipes.

Une intéressante observation finale consiste en ce que cette même dynamique d’équipe s’applique au niveau organisationnel : les compétences nécessaires correspondent toujours mal aux compétences requises. Cela signifie que les organisations qui optimisent la spécialisation de leurs ressources humaines ne délivreront jamais par rapport à la valeur pour le client.

Vélocité (dans le développement logiciel)

La Vélocité est une mesure de productivité souvent utilisée dans le développement de logiciel avec les méthodes Agile.

vélocitéLa terminologie suivante est utilisée dans le calcul et le suivi de la vélocité.

Unité de travail

L’unité choisie par l’équipe pour mesurer la vélocité. Cela peut-être une unité réelle comme des heures ou des jours ou une unité abstraite comme des points de « user stories ». Chaque tâche dans le processus de développement logiciel devrait alors être estimée en termes de l’unité choisie.

Intervalle

L’intervalle est la durée de chaque itération dans le processus de développement logiciel pour lequel la vélocité est mesurée. La longueur d’un intervalle est déterminée par l’équipe. Le plus souvent, l’intervalle est une semaine, mais il peut aller jusqu’à un mois.

Comment cela fonctionne-t-il ?

L’idée principale derrière la vélocité est de fournir une méthode simple et légère (agile) de mesurer l’allure à laquelle une équipe travaille et faciliter l’évaluation du temps nécessaire à produire des fonctionnalités supplémentaires dans un logiciel.

Pour calculer la vélocité, une équipe doit d’abord déterminer combien d’unités de travail valent chacune des tâches et la longueur de l’intervalle. La vélocité est donc mesurée en comptant le nombre d’unités de travail complétées dans un certain laps de temps, déterminé au démarrage du projet. Le suivi de la vélocité est le fait de mesurer de la vélocité réelle par rapport à la vélocité annoncée. Ce suivi de la vélocité fournit des informations qui permettent d’évaluer la performance d’une équipe dans le temps.

Pendant le développement, l’équipe doit faire un suivi des tâches complétées et, à la fin de l’intervalle, compter le nombre d’unités de travail complétées pendant l’intervalle. L’équipe note alors la vélocité calculée dans un diagramme ou sur un graphique.

La première semaine fournit peu de valeur, mais est essentielle pour établir une base de comparaison. Chaque semaine suivante, le suivi de la vélocité fournira de meilleures informations car l’équipe fournit de meilleures évaluations et devient plus familière de la méthodologie.

nouvelles certifications de APM Group en management de Projet Agile et Earned Value Management

APM Group, qui propose déjà les certifications Prince 2 élargit son offre avec deux nouvelles certifications: Management de projet Agile et Earned Vamue Management (EVM).

Deux niveaux de qualification Agile Project Management sont prévues: « Foundation » et « Practitioner ». Seule la certification « Foundation » est pour l’heure disponible.

La certification EVM, est elle aussi pour le moment seulement disponible en version « Foundation » avec un test à choix multiples de 40 questions sur une heure couvrant votre compréhension de la terminologie et connaissance théoriques des méthodes de Management par la Valeur Acquise.

Si vous décidez de passer ces certifications, merci de nous donner vos retours d’expérience.

PMGS Formations en management de projet
Partenaire de DantotsuPM

Le multitâche vous ralentit

Multitasking Gets You There Later article de Roger Brown

Le business moderne repose sur le multitâche pour réaliser le travail. Les salariés sont évalués sur leur capacité à travailler en parallèle sur de multiples tâches. Les professionnels de l’informatique sont habituellement assignés à de multiples projets. Avons-nous toujours fait cela ? Le multitâche marche-t-il ? Quels sont les impacts réels du multitâche ? Il y a une alternative ?

Monotâche serait le nom pour représenter comment nous avons eu l’habitude de travailler sur le logiciel avant le multitâche. Par multitâche, je veux vraiment dire « le travail en parallèle sur de multiples projets ». Le business moderne en est venu à appeler cela « multitâche » et à le considérer comme une stratégie pour une production plus efficace des employés. Nous faisons aussi du multitâche à une petite échelle dans nos vies quotidiennes, au travail et en dehors. Il y a des ressemblances à la fois sur comment nous le faisons et sur ce qu’il nous fait.

Une Perspective Différente

scrum methodologie agileQuand nous présentons l’approche Agile (ou Scrum) à de nouvelles personnes, une des plus grandes pierres d’achoppement est l’idée que les équipes travaillent beaucoup beaucoup mieux quand leurs membres sont dédiés à l’équipe à plein temps. Ce n’est pas nouveau. Pendant des années nous avons assemblé « des équipes tigre (tiger team) » et « équipes de choc (swat teams) » pour traiter des problèmes spéciaux, souvent en temps de crise. Cependant, nos organisations en sont venues à préférer un modèle basé sur des individus organisés par silos de compétence assignés à de multiples projets en même temps. C’est devenu la solution de facto pour avoir un grand nombre de choses réalisées en même temps. On le considère comme étant l’utilisation la plus efficace « des ressources rares », c’est-à-dire pas suffisamment de personnes et toutes spécialisées.

Le modèle Agile retourne ce modèle sur sa tête. Formons des équipes de personnes concentrées sur un petit ensemble de choses à la fois. Au lieu de créer le travail et de faire passer les personnes au travers, nous créons les équipes de personnes et faisons passer le travail vers elles. Et nous tirons au lieu de pousser.

Le changement est difficile. Faire les choses de manière différente demande un objectif clair, une vision des bénéfices et du courage. Donc la résistance est naturelle; les personnes ne se sentent pas en sécurité quand les choses commencent à changer autour d’elles. Si nous pouvons faire un changement vers le mode « LEAN », nous pouvons démultiplier deux principes centraux « du respect pour les personnes » et « améliorer continuellement le système » pour définir un objectif, prévoir les bénéfices et entamer les premières étapes vers l’amélioration. Beaucoup de personnes entendent « LEAN » et pensent comment mieux faire ce que nous faisons déjà. « LEAN » dit aussi que nous pouvons souvent éliminer encore plus de gaspillage si nous arrêtons complètement de faire certaines choses, des activités de faible valeur.

Les coûts du Multitâche

Une personne qui travaille sur plus d’un projet encourt un coût à chaque passage d’un projet à l’autre. Le coût primaire est le temps requis pour changer de contexte. Nous savons que des interruptions simples comme un appel téléphonique peuvent coûter au moins 15 minutes de temps de récupération. Plus la tâche est complexe, plus il faut de temps pour effectuer le changement.

Si vous travaillez sur plus de deux projets à la fois le coût peut être encore plus élevé. Il peut s’être écoulé beaucoup de temps depuis que vous avez travaillé pour la dernière fois sur ce projet, demandant plus d’efforts pour vous souvenir d’où vous vous êtes arrêtés. Alternativement, si vous changez fréquemment, votre temps de commutation de contexte demandera une plus grande proportion de votre temps de travail.

Il y a des études qui montrent que les personnes sont assez douées pour des changements entre deux contextes sur de petites tâches. Sur une période de temps réduite, cela semble avoir un rapport avec nos deux hémisphères cérébraux. Jusqu’à un certain degré, nous pouvons travailler en parallèle sur deux tâches indépendantes. Pour de plus grands changements, nous devrions nous attendre à un certain coût de commutation. Jerry Weinberg a montré que le contexte s’intensifiant, si chaque tâche a une pénalité de 10 %, en réalité les coûts cumulés sont fréquemment plus hauts.

Quand une personne fait partie d’une équipe, traditionnelle ou Agile, il y a un coût additionnel de commutation. Quand un membre de l’équipe part pour faire une tâche non liée au travail de l’équipe, l’équipe souffre de l’absence du membre. Quand le membre absent revient, l’équipe passe du temps à l’aider à rattraper les événements qui se sont produits pendant son absence.

Multitâche Agile ?

Mais, vous pouvez dire: « attendez un peu ». Une équipe Agile est transversale et occupée à faire toutes sortes d’activités chaque jour. Celles-ci incluent l’élaboration de besoins, l’analyse, le design, les tests et la programmation. N’est-ce pas du multitâche ? La réponse dépend de la portée de contexte. De vastes sauts de sujet et de technologie exigent plus de temps de commutation. Le cerveau est excellent avec les faibles changements d’activités. Sur une équipe resserrée, toutes les activités quotidiennes sont centrées sur une bande réduite de fonctions et technologies. Seulement quelques « storyboard » sont travaillés en même temps. Le contexte est étroit bien que l’éventail d’activités soit varié. De plus, Agile a un certain nombre de dispositifs pour garder le focus – la collaboration, les tableaux de tâche, le test automatisé, l’examen rétrospectif. Ce sont les larges sauts de contexte qui créent problèmes – d’autres projets, d’autres collaborateurs, d’autres parties prenantes.

Neuroscience de Multitâche

Le cerveau humain est fort en multitâche interne. Il le fait tout le temps. Il le fait même la nuit. Il y a beaucoup de parties du cerveau qui fonctionnent ensemble et seules tout le temps. Sinon, nous ne pourrions pas fonctionner dans nos environnements complexes. La plupart du multitâche est subconscient – le filtrage d’apport sensoriel, l’intégration d’informations connectées, déplacer des données de la mémoire à court terme vers celle à long terme, maintenir le cœur et les poumons en marche.

Et nous faisons du multitâche extérieurement – conduire de la voiture tandis que nous naviguons et écoutons les informations de circulation, parler au téléphone pendant que nous dînons, planifier des vacances en sarclant le jardin. Quelques tâches comme plier le linge, marcher, etc. sont mécaniques et n’encourent pas de coût de commutation de tâche. D’autres comme de naviguer à travers un document en frappant des touches ou renommer une méthode peut être faites mécaniquement après quelque temps. Mais le travail de développement logiciel n’est pas si simple. Beaucoup de ce travail en multitâche automatique marche bien. Cependant, il a vraiment des limites.

La commutation de contexte de missions multi-projet modernes crée une nécessité potentielle de re-travail mental. L’intelligence humaine a deux sortes de mémoire séparées – à court terme (la mémoire de travail) et le long terme. Il y a des mécanismes pour déplacer des informations entre les deux. Il n’y a aucune garantie que tout est déplacé ou que les informations entrant sont les mêmes qui en reviendront plus tard. Nous éditons constamment nos mémoires, à chaque fois nous les rejouons. De nouvelles informations doivent résider dans la mémoire à court terme pendant un certain temps avant d’être déplacées dans la mémoire à long terme. Par exemple, le bachotage peut vous permettre d’obtenir une meilleure note mais vous risquez de vous rappeler peu de choses deux semaines plus tard. Simplement, il est possible que vous ne puissiez pas conserver les dernières choses sur lesquelles vous avez travaillé avant la commutation de contexte. Et celles-ci sont probablement les choses que vous voulez le plus vous rappeler quand vous revenez sur le projet.

La recherche suggère beaucoup de façons dont le multitâche est inefficace ou même nuisible.

Considérez :

  • Il y a évidence que le multitâche dégrade en réalité la mémoire à court terme, pas seulement sur les sujets du multitâche, mais probablement en ayant un impact sur certains secteurs du cerveau. Le multitâche crée du stress; le stress invoque les parties plus primitives du cerveau qui sont concernées par la sécurité personnelle, tirant l’énergie des parties plus modernes centrées sur la pensée de plus haut niveau. Le stress peut aussi endommager des cellules nécessaires pour de nouvelles mémorisations.
  • Nous sommes plus enclins aux erreurs quand nous faisons du multitâche aussi la qualité de nos résultats de travail baisse. Cela, bien sûr, ajoute des coûts au projet parce que les choses devront être réparées.
  • Quelques parties du cerveau sont des processeurs séquentiels, capables d’accepter seulement une saisie à la fois.
  • Le cortex préfrontal, la partie du cerveau la plus utilisée pour la connaissance complexe et la prise de décisions, est la plus grande consommatrice d’énergie dans le cerveau. La charge supplémentaire du multitâche mènera à un épuisement plus rapide de capacité cognitive et un besoin plus fréquent de temps de récupération.

Monotâche pour Équipes Agiles

Comment réduire la quantité de multitâche pour des personnes dans un contexte Agile ? Nous y avons mentionné quelques approches. Un environnement plus physique engage davantage de parties du cerveau, menant à la synthèse plus rapide et plus complète d’informations. Un effort plus concentré maintient une portée de contexte étroite. Des interactions humaines et un ScrumMaster pour faciliter certaines des interactions aideront à garder ce focus.

Quelques pratiques techniques modernes améliorent le focus, par exemple :

  • Le Développement piloté par les tests permet de focaliser le travail technique dans un court laps de temps.
  • L’intégration continue aide à porter une attention immédiate à un « build » raté ou test non réussi.
  • « Pair programming » permet à deux personnes de se concentrer sur un petit secteur de code.

Monotâche pour Organisations

On connaît les arguments contre le multitâche depuis longtemps, cependant notre culture d’entreprise moderne est habituée à cette forme « d’équilibrage de charge » pour maximiser l’utilisation efficace de « ressources » humaines. Nous assemblons les équipes de personnes dans de libres groupements de fournisseurs de compétences travaillant à temps partiel sur plusieurs choses à la fois. Pouvez-vous construire une équipe à hautes performances à partir de membres à temps partiel ? comment en sommes-nous venus à penser qu’il est plus important que chacun semble être occupé tout le temps ?

Une des parties les plus difficiles d’apprendre est de devoir désapprendre les comportements actuels. C’est vrai pour les organisations autant que pour les individus, il est simplement difficile de faire le saut mental depuis ce que nous faisons maintenant à ce qui pourrait mieux fonctionner. Voici un argument visuel simple qui pourrait aider à guider un changement qui est non seulement plus facile sur les personnes, il a du sens financièrement.

Un scénario simple montré dans la Figure suivante comporte 4 personnes travaillant sur 3 projets courts. La dynamique est la même pour davantage de personnes et de plus grands projets. Dans le premier scénario, les gens font du multitâche sur 4 projets

La figure: Personnes en Multitâche

La figure qui suit montre un deuxième scénario dans lequel les mêmes personnes forment une seule équipe et complète les projets séquentiellement. Ce scénario fait la supposition très conservatrice qu’il n’y a aucun gain de productivité de teaming ou du nombre réduit de commutations de contexte. Remarquez que tous les projets sont achevés à la même date dans les deux scénarios, mais que 2 des 3 projets finissent plus tôt dans ce scénario. Imaginez les bénéfices financiers résultants.

La figure: Formez une Équipe pour Faire les Projets Séquentiellement

Avec la réduction de commutation de contexte et un modeste gain de 10 % dans la productivité en raison des synergies teaming, nous nous attendrions même à voir tous les projets finir plus tôt comme illustré dans la Figure suivante.

La figure : Une réalisation  plus courte grâce au monotâche et aux synergies d’équipe

Johanna Rothman couvre ce sujet plus en détail dans : « Gérez Votre Portefeuille de Projet »

La Variété est l’Épice de la Vie

Si le multitâche est clairement mauvais, nous devrions ne jamais le faire, n’est-ce pas ? Alors comment le concilions-nous avec l’idée que « la variété est l’épice de vie » ? Des recherches sur le cerveau ont montré que la nouveauté est attractive – elle produit la dopamine, un neurotransmetteur qui nous fait en redemander. La réponse a un rapport avec le focus et la portée. Si la commutation de contexte est importante, le multitâche prend un droit de passage sur la personne et ses collaborateurs. Si la commutation est faible, elle convient à notre manière de penser et peut très bien marcher. Nous obtenons une dose de nouveauté suffisante dans un contexte d’équipe Agile en apprenant l’un de l’autre et en produisant d’autres bons neurotransmetteurs par nos achèvements et nos succès.

Conclusion

La commutation de contexte entre les projets prend du temps et est un coût pour l’organisation. Plus il y a de projets impliqués et plus ils sont complexes, plus le coût est élevé. En se concentrant sur une chose à la fois pendant une période plus longue, les individus peuvent travailler plus efficacement. En formant des équipes pour aborder des projets séquentiellement, nous pouvons réduire le coût de commutation de contexte et gagner encore davantage par des synergies d’équipe.

Utilisez des « burn down charts » dans vos rapports de management de projet

Use burn down Charts in your project management reports

Les Gantt Charts sont très efficaces pour comprendre le progrès et statut du projet. Mais ils sont lourds côté planification. Ils donnent peu de compréhension de ce qui se passe. Un « burn down chart » est d’autre part bon pour comprendre le progrès du projet et où en sont les livrables.

Un « burn down chart » est la représentation graphique du travail qui reste à faire par rapport au temps. Le travail en attente (ou backlog) est souvent présenté sur l’axe vertical, avec le temps en horizontal. C’est-à-dire c’est un graphe d’exécution du travail en attente (du reste à faire). C’est utile pour prévoir quand tout le travail sera terminé.

Fabrication d’un « burn down chart » sous Excel

Étape 1 : Arrangez les données pour faire un « burn down chart »

Pour faire un « burn down chart », vous devez avoir 2 jeux de données. Le calendrier des tâches réellement exécutées et celui des tâches planifiées. Comme avec la plupart des graphiques, nous devons arranger les données. Je montre 3 colonnes supplémentaires que j’ai calculées pour réaliser le graphique « burn down chart ». Vous pouvez facilement deviner les formules.

Étape 2 : Faites un bon vieux graphique à lignes

Choisissez juste les séries « Balance Planned » et « Balance Actual » et créez un graphique à lignes. Utilisez la première colonne (des jours) dans la susdite table pour les labels sur l’axe des abscisses.

Étape 3 : Ajoutez les valeurs complétées quotidiennes (Daily Completed) pour compléter le « burn down chart »

Choisissez la colonne « Daily Completed » et ajoutez-la au graphique. Une fois ajoutée, changez le type de graphique pour cette série à histogramme (lisez comment combiner 2 types de graphiques en un : combine 2 different chart types in one)

Étape 4 : Ajustez le formatage et des couleurs

Ajouter ou supprimer les lignes de grille selon vos désirs. Ajustez des couleurs et la légende si nécessaire.

Téléchargez le modèle “burn down chart”

Click here [.zip version here] to download the excel burn down chart template. Use it in your latest project status report and tell me what your team thinks about it.

Download 24 Project Management Templates for Excel

faciliter le suivi d’un projet Agile avec Sharepoint

Dans son billet « Agile moving forward », Ryan Endres explique comment il a mis en place un environnement collaboratif basé sur microsoft sharepoint pour documenter et suivre son projet.

Ce Sharepoint projet lui permet bien sûr de stocker tous les documents projet à commencer par la charte, plan de communication, plan de test… et également les notes de réunion en permettant de plus du micro-blogging pour de échanges rapides.

Il indique aussi dans cet article le modèle de document utilisé pour décrire les besoins dans le backlog projet et leur allocation dans les Sprints de développement.

Enfin, j’aime beaucoup son idée de tourner de brèves vidéos des nouvelles fonctionnalités du produit en fin de Sprint pour garder les sponsors et autres parties prenantes informés et impliqués dans le projet.

 

le site de microsoft projet en français
Partenaire de DantotsuPM

 

la dernière version du Scrum Guide en Français et les certifications ScrumMaster et Scrum Developer

Scrum
Connaissez-vous le site Scrum.org?

On peut y trouver des guides, dont les dernières versions du  Scrum Guide écrit par Ken Schwaber et Jeff Sutherland et ce en différentes langues dont le Français: Scrum Guide en français

On y trouve aussi des détails sur les programmes Professional ScrumMaster et Professional Scrum Developer avec des tests payants en ligne ($100) pour valider votre niveau de connaissance de Scrum et des rôles des différents intervenants sur les projets Agiles.

PMGS Formations en management de projet
Partenaire de DantotsuPM

SCRUM ne serait pas l’apanage des seuls projets de développement de logiciels

Un point de vue original de Craig Brown sur SCRUM en tant que méthode universelle et non pas seulement réservée aux projets de développement de logiciels.

Voici ce que je retiendrais de la description qu’il en donne et qui s’applique à tout projet:

  1. Commencez avec un objectif. Puis, décomposez-le en étapes incrémentales.
  2. Discutez les étapes avec l’équipe qui doit livrer la solution.
  3. Définissez des périodes de temps standards (timeboxing) pour les itérations. Faites de votre mieux pour livrer quelque chose de pratique et d’utile à chaque itération.
  4. L’équipe doit prendre ses « ordres » du client au début de chaque itération et faire un rapport sur ce qui a été « fait » à la fin de chaque itération.
  5. L’équipe doit mettre du temps de coté au début de chaque itération pour planifier son travail.
  6. L’équipe doit mettre du temps de coté pour une brève session journalière d’échanges entre membres sur les progrès et les problèmes.
  7. L’équipe doit s’engager à l’amélioration continue et mettre du temps de coté à chaque itération pour réfléchir sur ce qui est allé bien ou pas et où l’on peut s’améliorer.
  8. La planification, la revue et les sessions de réflexion et réunions d’équipe quotidiennes doivent avoir lieu à des heures régulières pour aider l’équipe à acquérir un tempo.

Confessions of an Agile Project Manager

Des présentations au format Pecha Kucha (20 slides de 20 secondes, soit un peu plus de 6′ par video) à découvrir tant pour le contenu que pour le format.

We have many excellent confessions, now we need your help to pick the best

The community has spoken and we are impressed. With our official call for videos now concluded, we have eight distinct « Confessions » of project managers sharing their experience using Agile practices.

The PMI Agile Community of Practice (CoP) invites you to share these experiences and help us by voting for those you think are best. We will be accepting votes via Youtube comments through June 14th.

You can view and rate the videos by going to the PMI Agile YouTube Group or the PMI Agile PBWiki page: http://agile-pm.pbworks.com/Confessions-of-an-Agile-Project-Manager.

Participation: Anyone is eligible to vote on videos

10 false ideas about Agile Methods

For once, I decided to translate French articles for our English speaking readers and those of us based in France who work in an international context and would like to share these with our foreign colleagues.

The original articles (2 posts in fact) were published by Renaud Choné on the blog of his company, Time Performance: http://www.timeperformance.com/blog/16-generalites/101-5-idees-fausses-a-propos-des-methodes-agiles

The wide variety of agile methods and their practices generates numerous false ideas on this subject. The object of this article is to demystify the most common false ideas found in the debates on Web by answering these factually.

The arrival of the Agile Methods is generating a ditch between their partisans and those of traditional methods. This rupture is strengthened by the fact that 4 founding principles of the agile methods contradict directly the classic approach:

  1. Individuals and interactions over processes and tools
  2. Working software over comprehensive documentation
  3. Customer collaboration over contract negotiation
  4. Responding to change over following a plan

( Cf. the Agile Manifesto, the official site: Http://agilemanifesto.org/)

The idea here is not to take position but to allow healthy debates. Indeed, at Time Performance, we are convinced that there is no good method for every situation. And it is moreover why our management of software projects was designed to be flexible while being inspired by the best practices and tools, agile or classic.

False Idea n°1: the Agile Methods apply only to « small » projects

False, forgery and ultra-false… It is nevertheless the most wide-spread idea. It is also the most false.

1) The reason for being of Agile Methods is to allow the project to adapt itself easily to the changes ( » Reponding to changes « ). It makes sense only for the projects of rather long duration, because the risk of change is strong all the more as the project goes on. Furthermore, the duration is necessary to take the full benefits of the heavy investments made in the tests, their automation and the quality of the code, which are at the heart of the agile methods.

Moreover the Agile methods were designed for the development of software products (hence the term of Product Owner which we find in SCRUM), for which the life cycle extends over several years or even several decades.

This false idea was maybe inspired by the brevity of the development cycles. And precisely, an iterative development aims at avoiding the risk of tunnel effect, which is important all the more as the project is long.

Thus the Agile methods are particularly adapted, even recommended, for long projects and not for the small ones.

2) Concerning the size of the team, it is true that SCRUM limits the size of the teams to 8 or 9 individuals, and XP recommends it in practice, because it is the optimal functioning. But nothing forbids establishing several teams which will work each on a sub-project. Moreover SCRUM embeds it with a coordination mechanism which is called the SCRUM of SCRUMs. A team of several dozens of persons can be so constituted.

False Idea n°2: the classification « Agile Method » determines a homogeneous group

The Agile methods are very different from one to another. They are even sometimes almost totally complementary, as XP and SCRUM. If these last 2 methods mark a real break with regard to the classic approach, some as Unified Process establish intermediate steps in the evolution of the methods during the last 20 years.

All these methods agree only on the 4 principles, that is little. Furthermore, the Agile Manifesto offers certain freedom in interpretation. It is thus risky to speak about Agile Methods generally. It is better to speak about practices proposed by such or such method.

On top, it is necessary to add that the implementations of these methods are even more heterogeneous.

False Idea n°3: the Agile Methods are methods of project management

Firstly, the object of the agile methods is software development and not the management of projects. If certain topics of project management are mentioned such as the estimates and the planning, others are plainly absent (for example costs management).

Secondly, the agile methods are not methods. The authors of XP and SCRUM define them as sets of good practices.

False Idea n°4: the Agile Methods are methods of rapid development or prototyping

Short cycles of delivery do not mean that the developments are rapid. It implies simply to validate the progress regularly and concretely.

There are even chances that the developments will be less fast at first with regard to a V cycle, because of the requirements in quality of code and tests coverage, including of numerous re-developments. It is not thus a good approach to use for prototyping.

The Agile projects are marathon runners and not short-distance runners. That is why they travel light. And on the distance, they are generally the fastest and consume less.

False Idea n°5: the agile developments are with difficult to maintain because of the lack of documentation

The fear of seeing the knowledge of the functioning of the software leaving with developers at the conclusion of the project is perfectly justifiable when the documentation is insufficient.

However it is an error to consider that there is no documentation. Following the example of Open Source, in an Agile approach, the main documentation is the source code. And as numerous deliveries are realized throughout the project, everything is made to guarantee a perfect maintainability.

On one hand, the coding rules are very strict and their validation is automated. Several practices at the heart of the Agile methods (the refactoring, the absence of Code Ownership, the Pair Programming etc.) guarantee in the end an appropriate, well designed, legible and well documented source code.

On the other hand, in the source code it is necessary to include the tests (unit, integration, functional etc.). The tests are similar to a document of detailed specifications and an integrated validation tool. It is a significant but indispensable investment for the maintainability and the evolution.

In an agile approach, the source code and the tests stand for respectively detailed design and detailed specification, expressed in natural language in comments and in IT language. The big advantage is to guarantee that the documentation is always up to date with regards to the code, and that the code corresponds to the specifications thanks to the daily tests execution and continuous integration. An agile development should thus be very easy to maintain.

Really, the true question is: « between a complete documentation (specification, analysis, design etc.) and an appropriate and well tested source code which would you choose? »

The agile methods give the priority to the source code and to the tests. The V cycle favors in practice the documents which are generated upstream in the project, to the detriment of the code and the tests situated downstream in the cycle when the pressure to go fast, too fast, is much stronger.

False Idea n°6: the Agile Methods, it is the freedom to do it its own way

Team in « self-management » mode, questioned project manager’s role, redistribution of the responsibilities, the abolition of the contractual aspects, no detailed planning, absence or almost of documents, mainly verbal communication…

All these elements which seduce the teams have a flavor of freedom and emancipation which will frighten more than a manager.

However it would be false to consider that the Agility is synonymic of absence of rules, constraints and structures.

The Agility is above all a change in priority, as demonstrate the 4 principles of the Agile Manifesto. With more distance, it is also a change in the nature of a project, the objectives of which are not any more the respect for a requirements book, at costs and on time.

Now all these changes rest on different organization models which have their own rules.

To be Agile, it is not enough not to apply the former rules, it is especially necessary to apply the new ones.

False Idea n°7: the Agility, it is simple thus it is easy

Following the example of a chess game, the rules of the Agility are simple but their application is not. Several years of practices are needed to master well the game.

The Agility is synonymic of lightness and simplicity. It is natural to see a promise of ease there.

This promise is confirmed by books on Agility. They are generally less thick and less heavy than their equivalents; the principles and the presented concepts are much less numerous and simpler.

To acquire the theory is thus easy, but what about the practice?

In practice, the Agile methods impose very strong requirements on the individuals and the organizations.

For the individuals, there is at first a requirement in technical skills to produce an evolutionary, quality and easy to maintain software, well tested etc. This does not apply only to the Agile methods. The difference is that it becomes a priority with the Agility.

For the individuals, there is then a requirement of behaving and personal discipline to collaborate, communicate, make a commitment, and demonstrate self discipline… It is very difficult to set up Pair Programming; and Daily Scrum can easily turn into chaos.

Some organizations would need almost reorganization. For example, to involve more the business in the development, to redefine the jobs (project manager, scrum master etc.) etc.

For organizations, there is also a problem of the lack of mid-term and long-term visibility with an impact on how projects are budgeted.

Finally, the Agility rests on a strong requirement of Transparency. It can have heavy implications for organizations and individuals. Ken Schwaber, co-author of the Scrum method, expresses with provocation a direct consequence of this transparency strengthened by fast feedbacks:  » [the Agility] expose  the incompetence « . Stated this way, it makes you think…

In practice, very few teams arrive at the end of an Agile step(initiative). But fortunately, the passage in the Suppleness can be gradually made with immediate gains (cf n°9).

False Idea n°8: the Agile Methods require senior developers

The requirements of Agility on the individuals (cf. N°7) lead to think that the agile methods are reserved for experimented teams, teams of champions of the development. This is exaggerated.

The minimum required by the Agility would be rather a team consisting of an experimented coach and open-minded individuals, capable of questioning, capable of learning and especially who want to progress.

With regard to other methods, an advantage of the agile methods is to facilitate the fast grow in skills of the team members.

How? Simply thanks to the very short iterative cycles which allow fast feedbacks on performance and improving for the following iteration. In SCRUM, it is institutionalized under the shape of a Retrospective at each iteration end.

Besides, practices such as the Pair Programming and the Daily Scrum facilitate largely the transmission of knowledge between the members of the project.

We can retain a principle: the less the team is experimented, the more the « Coach » owes to be.

False Idea n°9: incompatibility with the classic approaches

The agile methods propose practices which, taken separately, are not incompatible with the classic approaches (cascading cycle, CMMI, PMBoK etc.).

For example, it is possible in a cascading cycle to introduce Peer Programming, Retrospect, daily meetings, the Palnning Poker, Burndown charts, continuous integration, the Test Driven… Why not?

If there is incompatibility, it is not at the level of the practices, but rather at the level of the values.

False Idea n°10: the Agility can apply to anything and everything

When, to test its software, it was necessary to reserve several days in advance some machine processing time on the central server and print its software on punch cards, the Agility and its Test Driven and Continuous Integration would have made anyone laugh out loud

To be Agile, it is necessary to have the will but also the means.

In domains, as construction or industry *, the constraints certainly do not allow to be as agile as in the software development.

In a project at fixed price, a purely agile approach is inconceivable. It is inevitably necessary to fix the perimeter.

In a deployment project, the Agility may bring more inconveniences than advantages.

To be able to be Agile, the change has to be desirable but also possible at low-cost. That is why the software development is the privileged domain of the Agility.

* In the industry, there is a Lean Manufacturing. This approach shares some of the values and objectives of the Agility, but with different practices oriented towards the industry.

Comment comparer ScrumMaster et Chef de projet ?

Article lu récemment sur www.pmi.org de Lisa A. Grant, MBA, PMP, CSM: Http://www.pmi.org/eNews/Post/2010_03-26/ScrumMaster-Compare-To-PM.html

Un ScrumMaster peut-il être un manager de projet — les positions sont-elles identiques ? J’ai réfléchi sur cette question pendant environ trois semaines après être devenue ScrumMaster certifiée et ai conclu qu’elles ne sont pas les mêmes, elles sont plutôt deux rôles distincts. Cependant, un chef de projet peut remplir le rôle ScrumMaster et le fait même souvent.

Techniquement, Scrum, qui est une approche de développement logiciel Agile, est idéalement faite justement pour cela : le développement logiciel. En fait, elle est conçue pour le développement logiciel rapide par les membres d’une équipe fortement qualifiés et auto motivés.

Il y a, cependant, beaucoup d’activités dans le cycle de vie du développement logiciel qui ne sont pas directement reliées au développement de fonctions logicielles. Ces activités incluent le développement de Business Case, des activités de préparation opérationnelle, la formation et le déploiement en production, pour en nommer quelques-unes.

Les meilleurs ScrumMasters sont des leaders techniques, des architectes ou des managers. Ceux-ci sont des ingénieurs de développement logiciels seniors qui peuvent évaluer les tâches et offrir des conseils techniques dans le processus de développement. Ils sont destinés à être techniques.

Le chef de projet est la personne qui gère tous les aspects du projet, dont l’un est le cycle de développement du logiciel.

Le chef de projet est le manager d’ensemble, la personne responsable au niveau de projet, tandis que le ScrumMaster est le responsable du développement de livrables logiciels.

À la différence du chef de projet, le ScrumMaster manage :

  • Le processus qui supporte si le logiciel répond vraiment au niveau fonctionnel aux besoins des parties prenantes (sous la direction du propriétaire de produit, le « product owner »);
  • La justesse et l’adaptabilité de la conception technique; et
  • Les tâches requises pour construire le produit de façon itérative en produisant un logiciel fonctionnel après chaque itération.

Le chef de projet s’assure que le business case est clairement défini, les documents de conformité sont correctement complétés, les activités de déploiement du produit bien exécutées — et il ou elle gère tous les autres aspects business du nouveau lancement de produit.

Il y a beaucoup de façons d’allouer les rôles par rapport aux ressources allouées au projet. Cependant, comme ils sont assignés dans un environnement Agile, je veux réitérer que Agile est destiné et a été conçu pour le développement de produits logiciels.

Il est possible d’utiliser Agile pour d’autres types de projets, mais la valeur pourrait être réduite à une liste de tâches avec un alignement de leurs dates de livraisons par itération. Une approche Agile performante fournit de la valeur pour le client à la fin de chaque itération, et pas simplement l’achèvement d’une liste de tâches.

La question à laquelle on doit répondre est : “Est-ce que le client a obtenu de la valeur avec ce que nous avons livré à la fin de l’itération ?” Si la réponse n’est pas positive,  Agile n’est pas vraiment réussi.

Donc votre chef de projet joue-t-il aussi le rôle ScrumMaster ? Posez-vous ces questions :

  • Le chef de projet a-t-il l’expertise technique d’évaluer des tâches techniques et de donner la direction ?
  • Le chef de projet a-t-il été formé à Scrum ?
  • Le chef de projet a-t-il le respect de l’équipe pour son expertise du sujet ?

Si la réponse à l’une ou plus des susdites questions est « Non », alors, laissez la personne qui a vraiment cette expertise exécuter le rôle de ScrumMaster. Si la réponse est « oui, » il ou elle peut probablement exécuter avec succès le double rôle de ScrumMaster et de chef de projet.

Rappelez-vous qu’il est difficile de garder une vue d’ensemble du projet ET une vue des tâches; c’est pourquoi il y a des chefs de projet. Pour équilibrer les deux rôles, les parties « business » du projet devront être mineures en comparaison du développement logiciel. De cette manière, le chef de projet/ScrumMaster peut se concentrer sur la gestion du temps et la facilitation des tâches de développement logiciels et les questions/problèmes et passer e reste du temps sur des activités comme le business case, le déploiement et la formation.

Si votre environnement évolue vers Scrum, ne présupposez pas automatiquement que le chef de projet devrait être le ScrumMaster. De plus, souvenez-vous qu’il y a toujours un rôle à jouer pour le chef de projet.

Ces deux positions devraient travailler de concert de même qu’un chef de projet et un manager de développement le font.

En « cascade » + RUP + Agile : Complémentarité plutôt qu’opposition

J’ai apprécié cet article où l’auteur a pris le parti de la complémentarité plutôt que de l’opposition entre les méthodes de développement traditionnelles et plus récentes.

Le choix entre les méthodes « en cascade », RUP et agile, y dépend à la fois de l’expérience de l’équipe, de la culture d’entreprise, du type de projet, de l’environnement, du mode de développement interne/externe, et prend en compte la dimension géographique.

Ce qui représente en soi, un bon exemple d’agilité dans le choix même de l’approche qui pourrait être une combinaison des trois méthodes selon les moments du cycle de développement.

Utilisez vous d’autres critères de choix de l’approche de développement?

En « cascade », RUP et Agile : quelle est la bonne méthode de développement logiciel  pour vous?

Article original de Serhiy Kharytonov, SoftServe © 2009

Http://www.executivebrief.com/software-development/waterfall-rup-agile/

Rationalisez la production avec les processus rapides et efficaces « en cascade », RUP et Agiles. Créez le bon mélange des stratégies de développement de logiciels afin de répondre aux besoins spécifiques de votre projet.

Malgré les signes de reprise dans l’économie, la réalité persiste dans le développement logiciel. La plupart des sociétés et clients ont besoin de leur logiciel pour hier avec les fonctionnalités les plus avancées au coût le plus faible possible. Pour atteindre ces buts apparemment contradictoires, les développeurs cherchent à rationaliser la production avec les processus rapides, efficaces qui peuvent donner au client ce qu’il/elle veut en un laps de temps le plus court possible.

Ces faits et les échecs de développement passés ont mené à un changement dans le développement logiciel depuis des méthodes très structurées, séquentielles de développement logiciel du passé, souvent appelé le modèle « en cascade », aux modèles plus itératifs et progressifs tels que « Rational Unified Process (RUP) » et « Agile. »

Les partisans d’Agile sont nombreux et il peut parfois sembler que des processus de développement plus traditionnels sont tombés en défaveur, mais en réalité les trois modèles ont leurs avantages, des côtés négatifs et leurs environnements de projet favoris. Au bout du compte, la meilleure méthode ou le meilleur mélange de méthodes pour vous dépend d’une compréhension minutieuse des trois processus et comment ils s’adaptent à votre projet logiciel, la culture business et l’environnement de développement.

En « cascade »

La programmation en « cascade » est un processus fortement structuré qui compte lourdement sur la planification initiale et un ensemble d’étapes séquentielles, prescrites qui coulent de l’une dans l’autre comme une chute d’eau. Chaque étape a typiquement son équipe propre d’experts et des jalons soigneusement préparés d’avance et aucune étape ne peut commencer tant que l’étape précédente n’a pas été complétée. Le but est de recueillir tous vos besoins détaillés tôt dans le processus et de fournir une seule solution complète  avec des résultats qui sont fortement prévisibles.

Typiquement les étapes dans le développement en « cascade » sont :

  1. Recueil des besoins et rédaction du cahier des charges
  2. Analyse fonctionnelle
  3. Développement du code
  4. Intégration
  5. Test et mise au point
  6. Installation
  7. Maintenance

Le développement en « cascade » peut marcher très bien pour des applications complexes, critiques à la mission de l’entreprise et qui s’intègrent avec de nombreux autres systèmes ou pour des organisations comme la NASA ou l’armée qui exigent les plus hauts niveaux de fiabilité.

Les détracteurs disent que la « cascade » demande simplement trop longtemps et manque de la flexibilité – ou de l’agilité – requise pour le marché logiciel d’aujourd’hui et un environnement de développement en constant mouvement. Les projets qui suivent la méthode en « cascade » prennent typiquement des mois ou des années et au moment où ils sont finis, on découvre parfois que les besoins ont changé ou que les besoins originaux étaient incorrects depuis le départ. Le résultat peut être des corrections onéreuses, explosant le budget.

RUP

Comme la « cascade », le Rational Unified Process (RUP), produit par Rational Software et plus tard par IBM, est aussi un processus lourd, mais c’est une approche itérative qui prend en compte le besoin d’accommoder le changement et l’adaptabilité pendant le processus de développement.

Comme la « cascade », RUP a une série de phases et des jalons qui coulent l’un dans l’autre. Les phases consistent en :

  1. Création (« inception »), où la portée du projet, l’évaluation des dépenses, des risques, le business case, l’environnement et l’architecture sont identifiés.
  2. L’élaboration, où les besoins sont spécifiés en détail, l’architecture est validée, l’environnement de projet est détaillé et l’équipe de projet est configurée.
  3. La construction, où le logiciel est construit et testé et la documentation de support est produite.
  4. La transition, où le logiciel est testé au niveau système et utilisateur, corrigé et déployé.

RUP définit aussi les rôles et les activités de membres de l’équipe en détail et compte à chaque étape sur la production de modèles visuels, qui sont les représentations graphiques riches de systèmes logiciels et des cas d’utilisation spécifiques plutôt que les grandes quantités de documentations requises pour chaque étape de la « cascade ». Tous les membres de l’équipe ont accès à la même grande base de connaissance de directives, modèles, outils et autres articles pour assurer qu’ils partagent les mêmes langage et perspective sur le projet.

Alors que cela apparaît semblable au développement en « cascade » de prime abord, la plus grande différence du RUP est son approche de développement itérative, qui construit le produit dans plusieurs étapes basées sur des revues fréquentes avec les parties prenantes. Les premières itérations RUP sont surtout de la définition de besoin et d’architecture et l’exploration d’idées différentes, tandis que les itérations ultérieures essayent de rassembler un produit complet. Chaque itération est un livrable exécutable et chaque phase RUP peut interagir avec les phases précédentes pour s’adapter au besoin.

Non seulement le processus RUP est itératif dans son ensemble mais RUP suppose aussi que chaque phase ait plusieurs itérations internes basées sur des retours d’utilisateur.

RUP adresse bon nombre des critiques du développement en « cascade » et est une bonne méthode pour des agences gouvernementales et institutions éducatives qui apprécient un cycle de développement de logiciel stable et répétable, ainsi que pour des organisations qui « offshore » dans des pays comme l’Inde et la Chine, ou qui produisent des progiciels.

Les critiques disent que RUP n’est pourtant pas aussi rapide et adaptable que d’autres méthodes, comme Agile et ne marche pas bien quand un délai de mise sur le marché rapide est crucial ou bien pour le Web 2.0 et les environnements Software-as-a-Service (SaaS) où on s’attend à des mises à jour fréquentes et des compléments de fonctionnalités.

Agile

Tandis que la « cascade » et RUP penchent vers la prévisibilité, les buts principaux d’Agile sont la vitesse et l’adaptabilité. Il y a beaucoup de types différents de processus de développement Agile, y compris XP et SCRUM, mais tous s’efforcent de mettre une version de produit basique mais fonctionnelle entre les mains du client aussi vite que possible.

Ils font alors suivre cette version par des versions successives qui ajoutent et changent des fonctions nécessaires au fil du temps pour fournir un produit plus robuste. Chaque module successif est planifié, codé, testé et complété sur de courtes sessions de deux à quatre semaines. Bien que le processus Agile soit planifié d’avance comme la « cascade » et RUP, il fait passer les gens et la collaboration avant le processus lui-même.

Plutôt que de dépendre de nombreuses équipes d’experts, le processus de développement Agile entier est typiquement entrepris par une seule, petite équipe, cross-fonctionnelle, censément auto-organisée, qui doit inclure un représentant client, qui suit des réunions quotidiennes et s’assure que l’équipe travaille sur les choses dont le business a vraiment besoin. La collaboration en face à face constante est le but, avec le représentant du client utilisé comme l’un des collaborateurs les plus importants. La documentation est dé-priorisée par rapport à la « cascade » et même à RUP pour sortir quelque chose aussi rapidement que possible.

Avec son approche modulaire, progressive, faite en collaboration, Agile est rapide et fortement adaptative au changement de besoins et des défis compétitifs, qui sont les raisons de tant de partisans. British Telecom est fréquemment cité comme une société qui a utilisé la programmation Agile avec beaucoup de succès, avec des cycles de développement de 30 à 90 jours qui ont rapporté une productivité spectaculaire et des avantages business par rapport aux 18 mois ou plus pris dans le passé pour produire un logiciel utilisable.

Mais même s’il est facile de tomber amoureux d’Agile, elle a aussi ses limitations et inconvénients. Son accent sur les réunions quotidiennes en physique et la collaboration rapprochée rendent le processus difficile à adapter à l’externalisation des développements, aux clients et développeurs géographiquement distribués, ou aux clients qui n’ont tout simplement pas la main d’œuvre, les ressources ou l’attention nécessaires.

Son accent sur la modularité, le développement progressif et l’adaptabilité ne convient pas facilement aux clients qui veulent des contrats avec des évaluations fermes et des calendriers fixes. Sa dépendance sur de petites équipes auto-organisées rend difficile l’adaptation aux grands projets logiciels avec beaucoup de parties prenantes aux besoins  différents et néglige de prendre en compte du besoin de leadership pendant que les membres de l’équipe s’habituent à travailler ensemble.

De plus, le manque de documentation complète peut rendre la maintenance et les nouveaux développements difficiles quand les membres de l’équipe originale laissent leur place à d’autres. Cela peut mener à des modules aux fonctionnalités et interfaces inconsistantes. Finalement, plus qu’avec la « cascade » et RUP, le développement Agile dépend éminemment de la capacité à recruter des analystes fonctionnels très expérimentés qui savent comment travailler indépendamment et s’interfacer efficacement avec des utilisateurs métiers.

Le meilleur de chaque monde

Si Agile, RUP et des modèles en « cascade » ont chacun leurs inconvénients, lequel devriez-vous choisir ? De plus en plus, le secret au développement logiciel réussi est de comprendre les trois processus dans le détail et sélectionner les parties de chacun qui conviennent le mieux à votre livrable et environnement particuliers. Puis, être agile dans l’approche même du processus, en regardant sans cesse sur ce qui a été réalisé, en réévaluant et révisant le processus de développement jusqu’à ce qu’il s’adapte au mieux à vos circonstances actuelles.

Par exemple, si vous développez du logiciel SaaS ou Web 2.0 dans un marché fortement concurrentiel, alors vous ferez probablement le meilleur choix en penchant vers des méthodologies Agiles. SaaS se prête particulièrement bien à Agile puisqu’il prévoit un accès constant au logiciel pour ajouter ou changer des caractéristiques. Dans un tel marché concurrentiel avec des besoins utilisateur changeants vous voudrez probablement être capables d’apporter rapidement des changements.

D’un autre coté, si vous produisez pour le médical, l’ingénierie, ou d’autres systèmes qui exigent un haut degré de conception et de certitude, alors il semble logique de commencer par la « cascade ».

Si vous produisez un progiciel grand public « sur étagère », avec de nouvelles versions qui doivent être des enrichissements des versions précédentes, votre processus devrait probablement pencher vers RUP, avec une attention particulière au recueil des besoins, à la définition du périmètre et du contenu au début, ainsi que des standards de navigation, et d’interface utilisateur.

Cependant, les développeurs peuvent tout de même utiliser des techniques Agiles pour présenter des prototypes fréquents et des modules progressifs aux chefs de produit de la société pour s’assurer qu’ils sont sur la bonne voie. La fréquence et l’intensité de collaboration entre chefs de produit et développeurs dépendent vraiment de leur proximité et de la culture de société – selon que ces équipes soient plus ou moins habituées à une telle collaboration. Quand la géographie est un problème, les outils de collaboration comme la conférence à plusieurs sur le web et la vidéo peuvent être d’une grande aide.

Ce même mélange de techniques peut être utilisé dans un environnement d’entreprise externalisant le développement en « offshore ». En fait, avec les différences de fuseaux horaires et de cultures, il est important d’intégrer autant d’étapes itératives et progressives et autant de contact de suivi qu’il est possible pour votre projet, la culture de votre société et celle de vos partenaires de développement.

Choisir de partir sur des équipes auto-organisées ou une approche plus « top-down »  de management dépend vraiment du niveau de compétence et d’expérience de vos développeurs. Beaucoup de projets peuvent exiger au départ un leader qui va ajouter une certaine urgence, une direction et une gestion des risques du projet jusqu’à ce que les membres de l’équipe s’habituent à travailler ensemble. Alors le rôle de leadership peut être réduit selon les besoins pour les itérations suivantes.

Le bilan est qu’il n’y a probablement aucun processus parfait pour tous les projets et environnements, ni même pour un seul. C’est pourquoi les sociétés doivent intégrer fréquemment « les leçons apprises » pour évaluer et réviser le processus lui-même, qui peut se déplacer d’un bout à l’autre du spectre à différents moments dans le cycle de développement. Bref, en choisissant entre Agile, RUP et en « cascade », adaptez le processus à vos besoins, plutôt que d’adapter votre projet au processus.

make a real impact in your company/organization: take a lead role in its continuous transformation

leader 2I’d like in this post to explain why I believe that, as Programme/Project directors or Projects Portfolio Managers (I’ll use the PMs abbreviation in the rest of the article), we are ideally skilled to become transformation leaders in our companies and organizations.

PMs are used to run projects to launch new products, services and systems, and create unique customer deliverables. Most of these introduce changes in processes, organizations and people behaviors. We know from experience how to structure a complex programme or a portfolio of projects, collect individual project data, analyze it, organize it, clarify and confirm deliverables, timelines and ownership. We’re also able to validate and take commitments for an entire programme or project. We often have to build and effectively communicate simple and powerful messages to management, customers and team members. So, I propose that we make a step forward and evolve from change agents on a specific project to transformation leaders for an entire portfolio of transformation initiatives at organization or company level.

Introduction

You’ve most probably already been engaged in transformation and continuous improvement programmes in your professional or personal life. I have experienced many of these and I’ll mention some as we go along in order to put the talk into perspective.

  • Kaizen is a Japanese word referring to a philosophy focusing on continuous improvement. When applied to the workplace, kaizen typically refers to activities that continually improve all functions of a business.
  • continuous improvementsContinuous Improvement Process (CIP, or CI) is a management process  whereby company processes are constantly evaluated and improved in the light of their efficiency, effectiveness and flexibility.
  • Reengineering or Business process reengineering (BPR) is an approach aiming at improvements by increased efficiency and effectiveness of end to end business processes by a full review and rethink of these from A to Z.
  • Rebranding and more specifically Corporate Rebranding is the process by which a company is marketed or distributed with a different identity. This may involve radical changes to the logo, name, image, marketing and advertising. It often includes real desire of cultural changes of the company being rebranded.

Current pitfalls and issues experienced

  • Kaizen and Continuous improvement approaches: I have always liked these incremental approaches where people doing the job constantly try improve the way things are done. kaizenThe very name of this blog, DantotsuPM, is about constantly thriving to improve our PM skills. One of the main issues with incremental and continuous improvements is that the better you conduct them, the less visible they are. I mean that when you manage these changes really well: you will have prepared the organization, gradually introduced changes and followed up to ensure they are functioning properly… Your greatest testimony of success is when people think of these changes as natural evolutions rather than revolutions. But how can we get proper management attention and funding for something that seems so natural that it has become « almost » invisible?
  • Reengineering: In the 1990s, many authors wrote on this topic. The most famous I can recall (as they were often quoted in the company I worked for at the time) were Michael Hammer and James A. Champy with their famous book « Reengineering the Corporation ». It did cost our company a leg and an arm to try to follow their precepts and reengineer from A to Z our Order to Cash chain of processes and systems with mixed results. On one side, it certainly helped to bring all IT and Business/Process experts together and force the revisiting of all processes in this chain. These processes had been created years ago and a refresh was more than welcome. return on investment However, if you calculate the cost per order (say over 5 to 7 years of lifetime of the reengineered solution) of all investments and expenses, you will find that it added a very significant amount to each and every order (over one hundred Euros in some business cases I reviewed). Therefore, one could say that it reduced our price competitiveness (or decreased our margins) on each order for several years. Of course, this is to be tempered by the cost of doing nothing (if the company had not engaged on this massive reengineering programme). And, the success rate of such initiatives remains quite low. So, what is the true Return of Investment of such and undertaking?

marque

  • Rebranding: This is also one area I had a chance to actively contribute to. It was a wonderful, motivating and challenging experience. We managed to merge multiple brands in our companies portfolio into a single one. It increased its power and its impact. It clarified the messages and also reduced overall marketing and advertising costs. So, it certainly brought most of the rewards the company was expecting. The one place where I think we could have done better is on the culture behind the brand, especially its meaning and values for the employees and management of the company. We had a great start with 8 core values well articulated that we spent time to explain and discuss with all. However, past the Rebranding initial big push, we did not hammer these values to really make them become part of our DNA. I trust that a few years later, most managers and employees would be challenged to list these 8 core values from memory. An important aspect of transformation programmes is that they take long to bed in.

Some of the key pitfalls I have witnesses with the above examples and others are:

  • directionsNebulous Objectives and Goals: Some Business Process Reengineering initiatives were driven as IT programmes often called Order to Bill, Customer Relationship Management, or Enterprise Resource Planning. The focus was more on the tools than the business processes transformation required. The risk in this situation is that what we are really trying to achieve from a business stand point gets lost in techie world.
  • Never ending or unclear timelines and deliverables: humongous programmes, multi years, millions of investments, thousands of man days… While starting from a good idea, the definition of the scope and management of changes often derail. Small is most often beautiful in project management. One clearly defined step at a time is better than engaging in a long trip towards an unclear destination and without clearly defined stops/stages.
  • A multitude of small initiatives that are loosely coupled at best, unrelated in most instances. We may have a lot of excellent changes to execute but cannot articulate them into something really meaningful for the company. We run the risk of rapidly loosing focus, support and momentum. Additionally, there is a lack of overall leadership for these to ensure proper attention and progress.

  • Loss of focus/business drive and support: The span of attention of key executives is often only minutes as they have to juggle so many things in parallel. If change/transformation programmes do not capture enough of their attention in a short time-frame they will not get their full support. And for any transformation, executive support is critical. The same applies to employees at all levels. If we cannot keep them engaged in our transformation initiatives, we will not be successful.

I will focus in this post on the continuous improvements type of changes and transformations. The Reengineering and Rebranding transformations should already be run as projects or programmes and if you hear about such an undertaking in your company then volunteer to lead or be part of it. It will always be a great learning opportunity.

What can PMs do about continuous improvement?

We can apply our skills and experience to transformation ideas, change/transformation projects and programmes.

  • Bring structure: After all, it is a key characteristic of PMs to be organized, structured, paying attention to details… We can apply these very skills with great success to transformation initiatives. We will collect the base data about all on going transformations and change ideas for a given domain, organization or division. At the initiative or idea level, we will structure it like we do for projects. We will identify information gaps and then fill these gaps. We will position/categorize all initiatives into consistent buckets; propose criteria for prioritization of the overall portfolio of ideas together with a simple overall process to manage the portfolio. For example, define what stages an idea would go through before it eventually becomes a project and delivers benefits to the company. These stages could be: unqualified idea, real opportunity, launched initiative/project, draft deliverables, final deliverables. Doesn’t this sound familiar to the ears of PMs?
  • Clarify: From experience, I can tell that you will find many transformation/change initiatives and ideas where the ownership is not well defined nor accepted, where people are fuzzy about what the idée communedeliverables will be and even fuzzier about when they will be ready. So, very much as we do it for any project, we will spend time ensuring that each initiative in the portfolio of potential transformations is clearly defined, ownership accepted, deliverables understood and target dates agreed by the people who will work on them. Each change idea will be treated as a small project with clear deliverables, ownership and target timing. Also, metrics to measure the impact of the change shall be defined and current performance data gathered. A spreadsheet with the following columns will get you started: Identifier, Category, Priority, Name, Owner, Status, Expected Deliverables, Next Steps, and Target Dates for draft and final deliverables and for the other stages you may have defined to progress the initiative.
  • funnelSimplify: Because many ideas appear to be brilliant, justified, attractive… You will inevitably have too many candidate proposals for the resources available to work on them. Additionally, if all were run in parallel, they could generate far more changes than the organization can absorb at once. So, you will attempt to give sense to the portfolio through prioritization and alignment on overall company and organizational objectives. The first pass should really aim at pruning the portfolio of ideas, keeping only juiciest ones. The second pass will look at staging these over time depending on urgency, resources the company can afford to dedicate to these and availability of the best resources. In fact, the last point is often a key driver: There are only so many resources able to lead some of the difficult change initiatives your company may want to undertake. Another area to simplify is the process for getting new ideas into the pipeline and reviewing them in a structured manner. This shall aim at facilitating new suggestions introduction and review.
  • momentumPush, action, move, create a momentum: You will need to ensure that all initiatives are progressing per the agreed timelines;  that their owners remain committed; that more people want to join and have their change or transformation ideas added to the portfolio. These are things you are used to do as PMs for your programmes and projects.
  • Communicate with clarity. If a PM’s job is often said to be 80% about communications, when you lead a transformation project or portfolio of change initiatives, then, most of your time will be spent on communications. A key difficulty is that you may have over a few dozens items running in parallel and all could be addressing different aspects of the business. Yet, your message shall remain simple and targeted for your audience. As indicated earlier, the categorization of communicatethe ideas to structure the portfolio will help. The alignment of your portfolio on corporate or organization strategy will also greatly facilitate communications. For example, if the big themes of your company are Customer Satisfaction, Profitability, and People development; you may want to organize your portfolio of changes around these 3 main themes. It will facilitate communications and appropriation as people will easily relate the changes to a model they are familiar with. Communication shall also highlight the benefits already achieved through completed changes and provide a taste for the ones to come.
  • Take the lead personally on some of these initiatives to work on the sweatcontents and also to experience the processes you’re deploying. This recommendation was given to me by my boss and I think he hits a very interesting point. It is about eating what you bake, i.e. being users of the approach we’re putting in place. It is also about bringing your personal value add to selected key change/transformation initiatives and being very instrumental in the success of these. You will also want to keep the momentum and give a good pace to the portfolio. Suggestion: Set up a portfolio board that meets regularly and includes all key players. It will encourage contributors to progress their initiatives as agreed, it will provide a forum to review and improve their deliverables, and it will provide visibility and momentum to keep things moving.

Act: take the lead! And benefit from doing so.

Current tough business conditions favor a desire throughout the enterprise to support or at least understand the need for changes. I would be most surprised if no major changes were happening at this very moment in your own environment and organizations. I sincerely hope that this post will have given you the will to consider such changes with a new eye and with the view of a Programme/Project director or Project Portfolio Manager.

volunteerYou have the skills to become a leader of transformation in your business or organization. Go for it!  Propose a new and structured approach to manage transformation and change initiatives and you run great chances to be listened to.

Additionally, I’m convinced that it is a win-win. Along the journey, you will personally acquire and/or reinforce critical and valued skills. You will then exploit these in many other situations: leadership, change management, prioritization, business alignment, big picture view, communications, networking…

Are you Agile?

agileIf you work in any industry or administration that uses IT to support its business (i.e. any of them) and your IT department hasn’t yet spoken to you about Agile development methodologies, you should certainly question why?

If they have, you’re probably confused with some of the concepts and all of its geek terminology. This short post aims to help you approach this promising way to incrementally develop new software. Agile development methodologies like Scrum structure some of the prototyping approaches we’ve used since quite a long time.

http://blogs.orange-business.com/live/2009/09/are-u-agile.html

And last week’s Agile 2009 conference featured a milestone in the project management profession: the formal launch of the PMI Agile community…
http://www.jessefewell.com/2009/09/04/agile-2009-and-pmi/

Agile en environnement onshore/offshore – Agile in an onshore/offshore environment

Excellent article dans la newsletter du mois de juin du chapitre PMI de Bombai en Inde (pages 16 à 18). Comment implémenter une approche agile de type Scrum dans un environnement où une partie de l’équipe est offshore? Un retour d’expérience vu depuis le coté offshore pour une fois. Voilà qui devrait intéresser beaucoup d’entre nous qui avons des équipes distribuées sur plusieurs pays et continents!

You will read a very good article in the PMI Mumbai’s newsletter on pages 16 to 18. How can an Agile approach such as Scrum be implemented with success in an environment where part of the team is offshore? An experience sharing that is coming from the offshore side this time. This shall be of interest to many of us who run teams distributed across several countries/continents.

http://64.78.9.230/sharepoint/mumbai/documents/Shared%20Documents/June_2009.pdf

Agile 2

1 heure sur SCRUM – video – 1 hour worthwhile investment

http://www.betterprojects.net/2009/02/schwaber-on-scrum.html

scrum

Ken Schwaber a co-développé le processus Agile, Scrum. Il est un fondateur de l’Alliance Agile et l’Alliance Scrum et signataire du Manifeste Agile.

Dans cette heure de présentation, Ken partage un peu de son expérience pratique de Scrum. Il fournit des idées sur comment utiliser Scrum au mieux et parle aussi des raisons de certains des principes de l’approche comme timeboxing, les Équipes fonctionnelles mixtes, la transparence, …

Ken Schwaber co-developed the Agile process, Scrum. He is a founder of the Agile Alliance and Scrum Alliance, and signatory to the Agile Manifesto.

In this hour of presentation, Ken shares some of his practical experience with Scrum. He provides hints on how to best use Scrum and also talks about the reasons behind some of the approach’s principles like timeboxing, Cross functional Teams, transparency, …

Et n’oubliez pas, si vous n’avez que 8 minutes: http://www.pmthink.com/2008/12/agile-scrum-primer.htm

Agile ou en Cascade / Agile versus Waterfall

J’ai apprécié la comparaison terre à terre des approches et les commentaires  de la présentatrice sur la mise en place de l’approche agile pour des sociétés qui viennent d’un modèle en cascade (concept, analyse, design, construction, livraison) traditionnel. ScreenShot34 I greatly appreciated this comparaison of the two approaches. The practical comments of the author on the implementation of  the agile approach for companies coming from a traditional waterfall model (concept, analysis, design, build, deliver).

http://www.cardinalsolutions.com/CORUG/presentations/Planning%20Iterative%20Development%202006%2002%2023%20Final.pps#256,1,CORUG

by Annie Kerregan of Cardinal Solutions on project planning for iterative style projects versus Waterfall traditional projects.

Scrum en 8 minutes max / Scrum in less than 8 minutes

SCRUM: Les concepts en moins de 8 minutes

http://www.pmthink.com/2008/12/agile-scrum-primer.htm

Une excellente vidéo pour appréhender les concepts Scrum en 7 minutes et 59 secondes. A great video to grasp the concepts of Scrum in 7 minutes and 59 Seconds !
Un bon investissement. L’auteur passe en revue les fondamentaux de Scrum. Depuis la liste des besoins (le product backlog) jusqu’au contenu de version (Release backlog) et aux Sprints (découpage d’une version en plusieurs livrables). video I found the video really worth watching. The author takes us through the very basics of Scrum. Starting with a product backlog (list of requirements) to a Release Backlog (what you’ll embark on the next product release) to Sprints (breakdown of the release into multiple work packages).
Il nous parle également de 2 méthodes très utiles pour contrôler l’avancement: les « Burn Down charts » qui représentent visuellement le reste à faire pour compléter chaque livrable et version. Et le superbe concept des meeting journaliers debout pour continuer à avancer rapidement. burn down chart It also covers 2 useful methods to control progress: Burn Down charts that visually represent remaining work to be done to complete each spring and release and a wonderful concept of daily standing meetings to keep moving fast.