SysML, l’UML de l’analyse système

Voici un court papier écrit en 2005. Les reflexions qu’il soulève restent pertinentes. Je me suis bien éloigné de ces considérations depuis une dizaine d’années. Si les efforts pour structurer les exigences paraissent louables, je ne peux m’empêcher de les trouver vains. Ou tout au moins aurait-il falu les compléter par une structuration des tests (via des stéréotypes ?) à différents niveaux…

Je ferais certainement l’effort d’une note de lecture sur l’ouvrage de Pascal Roques un de ces jours. En attendant : enjoy !

Champfrogs Checklist, un Management Workout par Jurgen Appelo

Pour Jurgen Appelo, le business ne doit plus seulement être adaptatif, il doit être transformatif ! Et pour rendre cela possible, nous devons, en tant que personnes, être des transformateurs. Etre un transformateur dans notre monde super-connecté signifie être soi-même connecté et surtout pouvoir influencer les autres dans la direction qui nous convient.

Où l’on parle de motivation intrinsèque…

Oui, être agent du changement, c’est bien mais en réalité les personnes que nous voulons changer répondent d’avantage à leur part d’irrationnel (leurs envies, leurs peurs) qu’à leur part de rationnel. C’est là qu’interviennent les « moving motivators », la détection des motivations intrinsèques qui servirnt de levier au changement, que Jurgen Appelo a popularisé dans son jeu. L’auteur a lui-même repris Daniel Pink qui les évoquent dans Drive :

  • L’acceptation (par les autres, par les collègues)
  • La nourriture. Ce sont les besoins essentiels, cux qui constituent le niveau de base de la pyramide de Maslow.
  • La famille
  • La liberté, l’indépendance.
  • Le sens. C’est la nécessité de savoir que l’on oeuvre dans un but, pour une finalité.
  • Le sens de l’honneur et de l’intégrité.
  • La compétence et la maîtrise.
  • Le sens de l’ordre et donc de la stabilité. Un besoin qui tire plutôt dans une direction différente des entreprises connecté et du changement.
  • Le pouvoir et l’influence, si chers à nos hommes politiques.
  • La connexion sociale et le besoin de tisser des liens.
  • L’amour. Disons que c’est l’étape suivante !
  • Le sens de la propriété, l’appartenance.
  • Le status social.
  • La sécurité et la tranquilité (retour à la pyramide de Maslow)

On l’on évoque (enfin) le Champfrog

De cette longue série, Jurgen Appelo extrait les éléments qu’il juge pertinent dans le contexte d’une organisation. C’est le fameux acronyme CHAMPFROG.

  • Curiosité : Se demander comment et quoi apprendre, mais aussi donner de la perspective sur les idées des autres.
  • Honneur : Quel est notre engagement de confiance et de responsabilité envers les autres ? Comment construire une confiance réciproque ?
  • Accepation (ou approbation) : De quelle manière notre comportement, nos signes extérieurs sont inclusifs envers les autres ? Utiliser le principe d’association lors de réussite pour construire une acceptation collective.
  • Maîtrise : Comment gagner en compétence et en tant qu’organisation rendre cette acquisition de compétence possible ? Mais aussi : comment valoriser la compétence des autres ?
  • Pouvoir : Montrer son autorité sur un sujet sans faire preuve d’arrogance, c’est l’autorité situationnelle. L’étape suivante est de parvenir à abandonner cette autorité aux autres.
  • Freedom (liberté) : Littéralement, c’est abandonner les contraintes implicites et explicites que l’organisation fait peser sur ses membres pour qu’ils puisse juste faire ce qui est nécessaire…
  • Relations sociales : Etre connecté, c’est d’abord s’ouvrir aux autres. C’est le prémice pour avoir un impact sur les personnes qui nous entourent.
  • Ordre : Il répond à un besoin de simplicité, de limpidité même dans la façon dont une organisation fonctionne.
  • Goal (But) : Pour Jurgen Appelo, la recherche d’un but a à voir avec l’optimisme et l’alignement des besoins de l’entreprise et de ses employés.
  • Statut social : C’est la crédibilité que nous avons et celle que nous accordons aux autres. Sur quels critères est-elle basée ?

Et après ?

Après, il y a le « moving motivator », une activité pour reflechir et expliciter nos motivations… Et bien sûr le présent « workout » !

The New New Product Development game, par takeuchi et Nonaka

Cette publication est connue pour être la source d’inspiration des créateurs de Scrum. Il fut publié en 1986 dans le Harvard Business Review et Hirotaka Takeuchi et Ikujiro Nonaka en sont les auteurs. Ils viennent du marketing et non du développement logiciel.

Les 6 caractéristiques du “Scrum”

On parle bien déjà de Scrum ! Et l’on prête à ce processus 6 propriétés fondamentales :

  • Une instabilité intrinsèque : le top management ne donne aux équipes qu’une direction générale avec un challenge très élevé à relever. Par ailleurs ce management donne une grande liberté d’action et d’interprétation. Cela crée une tension dans l’équipe à même de favoriser la créativité.
  • Des équipes auto-organisées. Elle apparait quand sont réunies 3 conditions :
  • L’autonomie : peu d’intervention du top management, son rôle est de fournir les ressources adéquates. L’entité fonctionne comme une startup.
  • L’auto-transcendance : L’équipe est dans une quête continuelle pour dépasser ses limites.
  • L’auto-fertilisation : une équipe pluri-disciplinaire renforçant leur connaissances respectives à l’image d’un impact hub.

Des phases de développement en chevauchement : le rythme de développement agit comme le poul de l’équipe. Pour permettre le développement selon ces phases courtes, il faut adopter le “sashimi system”. Le multi-apprentissage : il s’effectue à différents niveaux (individuel, collectif, entreprise) et dans les différents domaines d’expertise de l’équipe.

  • Le contrôle subtil : le management influe par petites touches sur l’équipe pour prévenir le chaos. Les auteurs identifient 7 axes d’action :
  • La sélection des membres de l’équipe
  • L’environnement de travail
  • L’encouragement à voir ce qu’il en est sur le terrain (où l’on rejoint le Lean…)
  • Une évaluation et des récompenses au niveau du groupe et non au niveau individuel
  • Gérer des différences de rythmes entre le début et la fin du projet.
  • Tolérer et anticiper les erreurs.
  • Encourager les fournisseurs à devenir eu-même auto-organisés.

La gestion du transfert de connaissance : Il est réalisé de manière osmotique, en réaffectant les membres de l’équipes sur d’autres équipes une fois le projet terminé.

Limitations et implication du management

  • On parle ici d’efforts extraordinaire, de journées de 60 heures ou plus … on est loin du “sustainable pace"…
  • Ce processus ne s’applique pas aux projets d’innovation disruptive
  • Il ne s’applique pas aux organisations centrées autour d’un "génie”.

Au niveau managérial, il faut 3 changements :

  • Un style de management promouvant ce processus.
  • Le management doit accepter que le développement des produits ne s’opère pas linéairement mais itérativement.
  • Le processus implique une suite d’essais / erreurs.

Les entreprises ont pour habitude de voir les projets innovants comme de nouvelles sources de revenus. Mais ils sont en fait avant tout des agents du changement. C’est donc avant tout un changement culturel.

The SCRUM Development Process

Cet article est réellement le premier à présenter Scrum, c’était en 1995. Petit détail que j’ignorais, Ken Schwaber l’a mis en oeuvre pour le développement de Delphi ! Déjà l’auteur présente son approche comme étant « boite noire » et empirique, bien adapté au développement de systèmes complexes. Et oui, Scrum est bien en rapport avec le Rugby !
Bien sûr, à cette époque, il n’était pas encore question du mot « agile ». Ken Schwaber situe Scrum comme une évolution des procesus itératifs, non comme une disruption.

Quand il parle du développement logiciel, c’est toujours à la notion de complexité que revient l’auteur. Il la définit comme suit :

Complexité = f(dev. environnement var. + target env. var.)

Toutes ces varaibles changeant par ailleurs au cours du projet.

Quand il compare Scrum aux procesus classiques, Ken Schwaber ne se contente pas de le comparer au cycle en cascade, déjà il met en évidence que la nature intrinsèque du modèle en spirale de Boehm est identique au cycle en V en cela que l’approche reste linéaire par essence ! Il pousse même ce raisonnement vers les processus itératifs dont il met en évidence qu’ils restent aussi « linéaires ». Une démarche qui reste incomprise de beaucoup plus de 20 ans après ! Car toutes ces méthodes sont basées sur l’illusion que le processus de développement peut être défini !

La méthodologie Scrum

Dans cet article, Ken Schwaber présente Scrum comme structuré en 3 phases

  • Planning et architecture système
  • Sprints
  • Clôture

Une structure que l’on ne retrouvera guère par la suite. Si la 1ère et la dernière sont des phases « définies », l’auteur qualifie la phase des sprints « d’empirique ». Notons aussi que l’auteur inclut dans la phase de clôture un « pré-release testing »… qui va à l’encontre du « potentially shippable » dont on parle aujourd’hui (et dont il ne parlait pas à l’époque) ! Par contre la durée des sprints est présentée simplement comme allant de 1 à 4 semaines, et non 30 jours (ou moins) ! Bref, comme on dit, c’était mieux avant !

A cette époque, on ne parle pas non plus encore « d’inspect and adapt » et donc encore moins de rétrospective !

Au niveau de la structure d’équipe, on ne reconnait guère la description actuelle : un management et des équipes de 3 à 6 personnes (donc l’équivalent de feature teams), responsables de sous-ensembles du backlog ! On ne parle pas encore de Product Owner.

Une emphase importante est mise sur l’utilisation des technologies objet, qui apportent la flexibilité nécessaire à une mise en oeuvre réussie de Scrum.

Les estimations se font en utilisant les points de fonction. Mais … Ken Schwaber met en garde sur la productivité qui est au moins le double du standard ! Sacré garnement !

Scrum an tant que processus

Dans cette partie, l’auteur rentre d’avantage dans la théorie des méthodes de développement, comment elles se définissent par le biais de métamodèles et en quoi il est important de reconnaitre si elles sont définies ou empiriques. Cela permet à l’auteur de revenir sur l’inadéquation des processus théoriques par rapport aux systèmes complexes sous un autre angle.

Et de conclure cet article !

Le guide Scrum, millésime 2013

On a pu voir différents retours sur le Scrum Guide 2013

Avant d’aborder le fond, ma première remarque: le document a de toute évidence été écrit avec Word sur Mac. Les auteurs ont utilisé le style par défaut sans rien changer aux styles proposés (Titre, titre 1, titre 2 et normal entre autres). J’aime bien aussi le copyright “1991-2013”, même si le premier article publié date de 1993…

Rentrons dans le fond.

La transparence

C’est un ajout par rapport aux versions précédentes. Bravo. Cela dit, c’est très centré “inspection”. J’aime bien la notion de “done partagée” (pour les items de backlog, car il y a aussi un “done” des tâches qui ne concerne que l’équipe), et pour moi la transparence passe plus par le partage d’information : tableau des tâches, backlog, etc… pas simplement à l’intérieur de l’équipe mais aussi à l’extérieur.

Le Product Owner

Cela n’a pas bougé depuis 2011. Mais je reste assez dubitatif de cette position qui créé un schisme entre l’équipe et le “responsable fonctionnel”. Je m’en étais ouvert dans ma rubrique “en finir avec” dans un post dédié aux Product Owners. Ma position n’a pas changé, et ce partage des eaux ne m’a jamais semblé agile.

La Scrum Team

Comme d’autres, je pense qu’une taille de 9 est le début de la rupture. En fonction de la dynamique de groupe, ça peut tenir ou pas, ou la rupture peut être avant. Quand je dis “rupture”, je veux dire qu’en fait l’équipe se restructurera d’elle-même en sous-groupes de manière informelle. Pas la peine de luter, ça se passera de toute façon.

De toute manière, l’art de fixer une taille est un peu osé. Une équipe de deux, ça peut marcher et avoir un sens pour certains projets, même en Scrum !

Le Sprint

Plus ça va, moins j’aime le mot “sprint” qui a trop une connotation de “rush” à mon goût. Itération me va bien. Bien sûr l’insistance sur les 30 jours (même si l’on précise que cela peut être moins) devient drôle. Plus personne au monde, à part Ken Schwaber et Jef Sutherland, ne parle d’une limite maximum à 30 jours, mais bon…

Planning meeting

Comme mes petits camarades, j’ai noté la présence du “sprint goal”. Voici une évolution que j’accueille à bras ouverts ! Depuis pas mal de temps déjà je commence mes planning meeting ainsi, et note cet objectif sur un A3 qui figure ensuite au-dessus du tableau des tâches. Il est vrai que j’arrive rarement à faire une itération avec un seul objectif, mais je ne dépasse jamais 3.

Quoi qu’il en soit j’ai pu noter une différence extrêmement importante de motivation et de productivité entre des sprints ayant un objectif clair par rapport à la vieille méthode “liste à la Prévert” qui nous transforme plutôt en ouvriers spécialisés ! C’est ce qui aide à créer du plaisir et de la motivation : donner du sens à notre travail. C’est bien plus efficace que de coller des niko-niko au mur…

Bravo pour cette évolution qui va dans le bon sens !

Daily Scrum

De manière concomitante, le Daily Scrum prend une orientation qui est en concordance avec le “sprint goal”. C’est pure logique.

Un effet de bord est que l’on parle moins d’engagement sur la liste des stories (voir plus du tout) mais d’engagement sur le but du sprint, qui donne la souplesse d’adapter le contenu en cours de route pour rester dans la ligne de l’objectif mais éventuellement en déscopant des choses !

C’est encore une évolution que j’apprécie. Je n’ai jamais été à l’aise avec la notion d’engagement telle qu’elle été exprimée. Pour moi, l’engagement est moral. La qualité et la conformité au “done” doivent être maintenus coûte que coûte. L’engagement sur une liste de stories est pour moi une manière de demander à l’équipe de s’enchainer volontairement. Elle est le stigmate d’un manque de confiance et au bout du chemin demande implicitement de renoncer au “rythme soutenable”, ce que je n’accepte pas non plus.

On a ce pour quoi on paie. L’engagement sur un ensemble de stories se paie. Souvent en rush avec à la clé une qualité abdiquée, des heures sup’ avec une conséquence désastreuse sur le moral et la confiance et le plus souvent un cocktail de tout cela. Le tout en parfaite conformité avec les valeurs du management contrôle/commande que l’on prétend avoir abandonné !

Ce qui peut paraitre un petit ajustement est pour moi un gros virage dans le bon sens !

Sprint review

Apparemment il fait toujours 4 heures ! Bon je sais que l’on parle d’itérations d’un mois que personne ne pratique. Mais cette durée est ridiculement longue. Je vise une heure maximum pour une iteration de 2 semaines. Et c’est plus souvent de l’ordre de 30 minutes. Bref, je suis aligné sur Pablo visiblement sur cet aspect.

D’ailleurs la pratique des micro-démo tend à conforter la durée de 30 minutes, voir moins.

Sprint rétrospective

Je me suis fait la même remarque que Pablo: il est curieux qu’elle soit plus courte que la démo. Mes rétrospectives sont à peu près toujours de l’ordre de 2 heures pour 2 semaines. En fonction du contexte, ça peut aller jusqu’à 2h30 ; il est plutôt rare qu’elles soient plus courtes.

Product backlog

On parle d’items qui peuvent être complétés dans un sprint. Certes, mais pour moi cela reste une granularité bien trop élevée ! Difficile d’être adaptable au sein d’un sprint si seule un item ou deux figurent au programme ! Mais bon, ce point n’est pas nouveau… Je dirais que là-dessus je suis clairement d’accord avec ce que Gilles Mantel met au programme de son Scrum Master Academy.

Surveiller les progrès vers un but

Ce point devrait être en principe en concordance avec ce qui est dit sur le sprint planning et le Daily meeting. Il ne semble pas, car on parle de monitorer à la fin de chaque sprint ! De plus je trouve que ce point n’est pas très clair…

La transparence, encore et toujours…

J’aime bien ce nouveau focus. Toutefois je le trouve incomplet. Tout d’abord il ne concerne que le “done” et la liste des items pris dans le sprint, alors que je pense qu’il doit s’étendre à l’ensemble des artefacts de l’équipe, notamment le suivi des tâches.

Ensuite pour moi la définition de terminé ne doit pas seulement venir de l’équipe, mais de l’ensemble des parties concernées par le produit : product owner, opérations, hot line s’il y a lieu, etc…

En conclusion

Globalement, ce Scrum guide n’est pas une révolution. Ce n’est pas non plus ce que l’on attendait. J’aimerai bien que les auteurs abandonnent une fois pour toute leur notion de sprint d’un mois qui était déjà ridicule il y a 10 ans et est maintenant franchement embarrassante.

Mais de manière générale, je trouve que ce Scrum guide va dans le bon sens. Les auteurs ont résisté à la tentation d’alourdir Scrum. En fait ils l’ont même allégé de notions pas indispensables, comme celle de release. D’un autre côté, je suis un grand fan de cette notion de “sprint goal” qui nous éloigne d’idées précédentes pas franchement agiles.

Bon boulot, donc !

Personal Maps, un Management Workout par Jurgen Appelo

Quelle maîtrise un manager enfermé dans son bureau a-t-il de son équipe ? Probablement pas grand chose ! L’espect prépondérant d’un manager est l’information. Or nous « irradions » de l’information. Or, comme pour tout rayonnement, plus grande est la distance, plus faible est ce rayonnement. Le manager doit donc chercher à être proche du travail qui est important pour lui. Ce n’est d’ailleurs pas seulement vrai des managers !

3 approches à essayer

Bougez vos pieds

C’est le Gemba du Lean, ou le Management by Walking Around, si vous préférez. Pas seulement déambuler, bien sûr, mais se connecter et être en prise avec le terrain. Et évidemment pas contrôler ce qui se passe ! Maintenant, on peut aussi trouver l’idée de devoir se déplacer pour se rendre compte pas très naturelle. Ce qui nous amène à l’option 2

Bougez votre bureau

Ce n’est plus se déplacer, mais être au centre de l’action, quoi qu’il se passe ! C’est aussi être impliqué dans ce qui se passe. Un « management by sitting around » en quelque sorte…

Bougez votre micro

Si la collaboration est améliorée avec la productivité, ce n’est pas nécessairement le cas de la productivité. Permettre de mixer télétravail et présentiel peut permettre d’avoir le meilleur des deux. Bien entendu, cela signifié mettre à disposition l’outillage de travail à distance adéquat !

Effet d’Hawthorne et principes de proximité

Que ce soit en bougeant le bureau ou en déambulant, la présence du manager n’est pas neutre : elle irradie elle-même une information, que le manager se soucie de ce qui se passe.

  • La distance aux personnes doit être proportionnelle à l’importance de leur travail
  • Rendre la question de la proximité variable et non prédictible

Il n’y a pas 1 « sweet spot » de distance, mais deux ! La communication nécessite de la proximité tandis que la créativité nécessite de s’isoler. Ainsi la proximité doit être ajusté en permanence.

Personal map

La distance géographique a une importance, mais elle tend à s’estomper. Ce qui est prépondérant, c’est la « distance mentale ». Jurgen Appelo nous invite à tracer notre mind-map de relation aux autres, dans nos cercles privés, professionnels, éthiques, etc..

Comment commencer ? En suivant les indications de Jurgen, en page 18 de cet article !

Yay Question, un management workout par Jurgen Appelo

C’est de célébration dont Jurgen veut nous parler aujourd’hui. Car nous ne célébrons pas assez nos accomplissements. C’est sans doute la raison qui l’a amené à mettre en place une cloche en cuivre au milieu d’un open-space !

Célébrations

Mais que doit-on célébrer : les succès ou les échecs ? Car certains disent qu’il faut célébrer les échecs. D’après Don Reinertsen, nous acquierons le maximum d’information lorsque la quantité d’échecs égale la quantité de succès ! Ce n’est donc pas l’échec ou le succès qu’il faut célébrer, mais le fait d’avoir appris quelque chose.

Deux questions

Pour aider à se focaliser sur ce qui doit être célébré, Jurgen Appelo nous propose 2 questions :

  • Qu’avons-nous fait correctement ? (en suivant des pratiques)
  • Qu’avons-nous appris (en expérimentant)

Renforcer les pratiques qui marchent en les célébrant mérite d’être fait. D’un autre côté, les expérimentation dont on ne peut prédire l’aboutissement peuvent conduire au succès ou à l’échec, mais c’est l’enseignement qui en ressort qui est important. Pour l’auteur, célébrer, c’est :

  • Célébrer fréquemment, même pour de petites choses.
  • Célébrer de façon notable, que tout le monde puisse voir.
  • Célébrer de façon mémorable, avec votre propre rituel.

Finalement, Jurgen Appelo nous propose un board pour mettre en oeuvre celà dès demain !

Delegation Board, un management workout par Jurgen Appelo

La délégation, ce n’est pas facile : c’est une perte de contrôle. C’est en racontant une histoire de chevaux que Jurgen Appelo aborde l’un des points cruciaux du management, le contrôle. Car les humains se comportent en résonance avec la façon dont ils sont traités : un style magistral entrainera du laisser aller des subordonnés. La solution réside dans la distribution du management !

Néanmoins, certaines tâches relèvent du management hiérarchique : les embauches et les licenciements ou la signature des contrats, par exemple. Mais il y en a assez peu finalement.

Empowerment

Redistribuer le contrôle au travers des strates de l’organisation est plus facile à dire qu’à faire. La tendance en ce sens est pourtant inévitable, car les personnes en charge de leur travail sont les mieux informées sur les décisions à prendre le concernant. La véritable question est : comment l’implémenter efficacement ?

La délégation requiert en premier lieu des limites claires et l’autorité nécessaire, ce que Don Reinertsen nous apprend dans « Managing the Design Factory ». Toujours en suivant Don Reinertsen, Jurgen Appelo nous invite à dresser la liste des « key decision area » et de décider du niveau d’autorité / délégation à donner à autrui sur chacun d’entre eux.

La délégation n’est pas un modèle binaire. Inspiré du Leadership situationnel de Paul Hersey, Jurgen Appelo a développé sa propre variante, plus « symétrique » que l’original. Il comporte 7 niveaux :

  • « Tell » : Le manager prend la décision et en demande l’exécution sans qu’une discussion s’engage.
  • « Sell » : Le manager prend la décision mais cherche à convaincre de manière à impliquer la personne en charge de l’exécution.
  • « Consult » : Le manager s’informe auprès des concernées afin de prendre une décision qui respecte les opinion des personnes impliquées
  • « Agree » : Décision sur la base d’un consensus entre le manager et les personnes impliquées.
  • « Advice » : Le manager laisse la décision aux personnes concernées, mais en leur donnant des conseils dans l’espoir qu’ils seront entendus.
  • « Enquête » : Le manager laisse les personnes concernées prendre la décision, mais en leur demandant après coup de le convaincre du bien-fondé de leur décision.
  • « Délègue » : Le manager laisse la décision aux personnes concernées sans demander à en connaitre les détails d’exécution.

Le tableau de délégation

Ce tableau, de préférence physique liste verticalement les « key decision area » et horizontalement les 7 niveaux de délégation. Il clarifie le niveau de délégation mutuellement accordé entre le manager et les autres personnes de l’organisation.

La délégation ainsi est un investissement. Car au départ, elle nécessite du temps et de l’aide de la part des managers ! C’est aussi l’avantage de ces 7 niveaux : ils permettent d’accroitre progressivement le niveau de délégation.

Au final, la délégation doit aussi être vu comme un accomplissement. La « puissance » doit être égale à la somme des délégations accordées !

Scrum Shu Ha Ri : l’article

Après vous avoir infligé le support de la présentation que j’avais faite lors du Printemps Agile à Caen, voici le contenu de la présentation elle-même. Peaufiné, retravaillé, il ne correspond peut-être pas (certainement pas, en fait) à la transcription de ma présentation, mais en révèle le contenu de manière plus approfondie.

En effet, ce ne sont pas moins de 93 renvois et 80 références bibliographiques (sans compter les 27 illustrations) qui émaillent les 29 pages du texte.

Bonne lecture !