J’ai besoin de votre avis sur un truc. On le sait bien Scrum est très minimal. Est-ce trop minimal pour nos clients “corporatifs”?

Ceux chez qui le département de TI s’est développé autour d’un processus très lourd avec plusieurs rôles et biens livrables s’y retrouvent-ils?

Pourrait-on mieux les encadrer?

On sait que l’Agilité c’est une façon d’être et qu’au delà du processus il y a les individus (et leurs interactions). Cependant, je me retrouve dernièrement devant des clients qui recherchent désespérément des réponses à plusieurs questions auxquelles Scrum ne répond pas. La théorie du leadership de situation me dit qu’il faut être plus directif avec ses clients. Je crois qu’il faut jeter les bases pour eux et ensuite leur apprendre à développer une culture d’amélioration continue où les bases jetées ne sont que le point de départ de l’amélioration.

Dans ce contexte, pouvons-nous (devons-nous) aller plus loin que le simple Scrum?

Je vois 2 solutions :

1) Piger dans leur processus actuel (pour des définitions de rôles et des biens livrables) et l’encadrer à l’aide de Scrum.

ou

2) Mettre en place un processus Agile plus lourd tel que OpenUp ou DSDM.

J’ai l’impression qu’appliquées avec la bonne attitude (ce qui est aussi vrai avec Scrum) ces méthodes ont beaucoup de sens.

Qu’en pensez-vous?

Allez n’aillez pas peur, jetez un oeil sur OpenUp … elle ne vous mangera pas

OpenUP is a lean Unified Process that applies iterative and incremental approaches within a structured lifecycle. OpenUP embraces a pragmatic, agile philosophy that focuses on the collaborative nature of software development. It is a tools-agnostic, low-ceremony process that can be extended to address a broad variety of project type?

François Lapointe :

Je crois que l’idée est bonne, les entreprises fortement hiérarchisées, politisées (ce qui est, entre nous, le propre de toutes les grandes entreprises) et bourrées de contrôles de toutes sorte ne peuvent, malgré toute la bonne volonté sautée dans l’Agilité. On pourra au plus avoir un projet de temps à autre en Agilité, mais ces projets resteront des ‘curiosités’ malgré le succès incontestable de ces projets .
En fait je crois même que l’Agilité comme on la connaît, n’est pas viable en grande entreprise.
De ce fait, une approche Agile ‘structurée’ ou ‘lourde’ est une excellente option.

Mathieu Szablowski :

 

J’ajouterais à la réponse de François que ces ‘grandes entreprises’ sont en général nombrilistes et que leurs dirigeants voient dans la méthode et les processus un façon d’innover en reprenant des briques de choses existantes pour les accommoder à leur sauce. Maintenant si on regarde les autres méthodes proposées, en quoi différent-elles de Scrum? Je pense qu’elles ajoutent du formalisme (guidance, process…) là où Scrum réclame du bon sens (ex. : processus de livraison même si rien n’est défini mais que l’on a déjà livré en logiciel jusqu’en production, on a un processus de livraison…). Les entreprises à qui tu proposes ces méthodes n’ont pas l’air d’être des ‘start up’s’. Personnellement, je me dirigerais plutôt vers l’étude de leur processus interne et tenterais de ‘fusionner’ ce qu’ils ont déjà avec un processus plus Agile (notamment dans la conduite de projet). Tu obtiendrais par ailleurs ce qu’ils veulent, c’est-à-dire un processus rien qu’à eux

Jean-René:

Bon point… c’est exactement ce qu’on a proposé à un de nos clients. Étude du processus en place (bien livrable, rôles, étapes,…) à partir duquel on dégagera un Scrum Type version 0 qu’on améliorera au fil des itérations.

Isabelle Therrien :

Le danger des méthodes lourdes est d’avoir à faire des choix en début de projet sans trop connaître ce dans quoi on s’embarque.

“Choisissez entre les 40 rôles proposés et les 56 processus”, ce n’est pas facile, et ils se retrouvent donc avec des méthodes trop lourdes qui ne font que déplacer les problèmes, plutôt que de les révéler.

Le nouveau cadre Ensemble est intéressant aussi, on pourrait quasiment dire que c’est une “méthode lourde”. Ça met une couche de gouvernance sur la méthode Scrum. En fait, tout le monde crée la sienne, et je commence à penser que c’est nécessaire, surtout dans les gros projets ou les grosses entreprises.

Mais pour plusieurs raisons, dont la gestion du changement beaucoup plus facile, et aussi parce que je le fais par réflexe, je préconise d’introduire les valeurs et pratiques Agiles dans la méthode “actuelle” en place chez le client.

Avec un suivi constant, il est possible de leur mettre en lumière des changements à faire “à mesure”… enlever ceci, puis cela, et au bon moment, ils vont s’apercevoir qu’ils sont beaucoup plus efficaces qu’avant, qu’ils collaborent mieux et qu’ils livrent du logiciel de meilleure qualité.

Vincent Tencé :

Je travaille avec un client depuis le début du moi du juin pour les aider à proposer une approche de développement officielle basée sur Scrum et qui respecte leur SLC (Software Lifecycle) corporatif. Notre dernière rencontre a eu lieu la semaine dernière et j’attends leur présentation qui me permettra de documenter les résultats. En quelques mots, nous avons une approche compatible CMMI niveau 3 et qui s’arrime sur les jalons de leur cycle de vie R&D.

Je crois que çe sera utile dans les situations que tu décris Jean-René de proposer une approche qui cadre mieux avec leur culture corporatif sans compromettre les principes et valeurs de l’agilité. Comme me le disais Bob hier, ça fait moins « révolutionnaire » et ça nous permet d’être entendu.

Sylvie Trudel :

Mon expérience à essayer d’adapter un processus générique (de type RUP) à une organisation qui appliquait autre chose :

- Ça prend plus de temps que de définir un processus “from scratch”.

- Ça a peu de chance d’être adopté par les équipes qui ne s’y reconnaissent pas.

Par contre, prendre ce qu’ils font déjà (processus, biens livrables, rôles et responsabilités) et les adapter, fait en sorte que l’organisation adhère plus vite aux changements parce qu’ils ne font qu’ajouter ou moduler ce qu’ils connaissent et maîtrisent déjà. Plus facile. Dans ce contexte, conserver une processus de développement pour ses biens livrables en le découpant en sprints devient relativement simple. Au pire, il faudra commencer par la conception/programmation avant de pouvoir remonter à l’architecture. Compromis acceptable quand la marche est trop haute. Faut quand même pas oublier qu’on travaille d’abord avec des individus; les processus sont un side effect…

Mathieu Szablowski :

Sylvie, quand tu dis : “Au pire, il faudra commencer par la conception/programmation avant de pouvoir remonter à l’architecture”, tu ne crois pas que le plus important sera d’engager les utilisateurs (ou un PO) dans le développement?
Les équipes techniques sont impatientes de tester les pratiques et les concepts Agiles mais s’essoufflent rapidement si aucun retour n’est effectué sur leur production. C’est aussi leur donner un but, un objectif voire une certaine pression parce que la présentation régulière est ce qui coûte le plus cher à l’organisation.

Sylvie Trudel :

Dans un contexte où la hiérarchisation des rôles est carrément calquée sur la métho (P+, pour ne pas le citer) et que l’architecture relève d’une vice-présidence séparée qui détient l’exclusivité de la communication avec un pilote (représentant des utilisateurs qui appartient à la ligne d’affaires et qui détient l’exclusivité de la communication avec les utilisateurs), et que notre mandat nous vient de la vice-présidence de la réalisation, notre carré de sable se limite à la portion conception/programmation/tests (cas vécu dans une grosse boîte l’an dernier, 200 développeurs, plus de 3000 utilisateurs). C’est par là qu’on peut commencer à agir. Quand j’ai suggéré d’inclure la portion “architecture” dans la démarche d’amélioration, je me suis vite butée à une guéguerre politique entre les 2 VP.

Donc, la question que j’ai dû me poser a été “veut-on avoir raison, ou veut-on avoir du succès?”. La réponse est venue assez vite merci. On a eu du succès en se limitant à notre carré de sable, mais avec beaucoup d’impact sur la formation du VP. Ça a fait des p’tits en un an et demi, à un point où Pyxis est solicitée pour “alléger” leur méthode. Faut être prudent et très patient parfois avec les grosses boîtes. Ils ne vivent pas dans notre “espace-temps”. On dit que les paquebots ne virent pas sur une pièce de 10 centimes.

De toute façon, l’idée est qu’ils se mettent à développer des réflexes d’inspection/adaptation de leurs façons de faire. Quand on y arrive, on a déjà accompli beaucoup et le reste va finir par suivre. Il ne faut juste pas s’attendre à ce que ça se fasse à notre vitesse, mais à la leur.

Vincent Tencé:

Très juste. On ne peut pas brusquer le changement, simplement créer les conditions pour qu’il prenne le moins de temps possible.

Stéphane Lécuyer:

My 2 cents…

Personnellement, dans un premier temps, je préfère mettre l’accent sur les “valeurs et principes” de l’Agilité et essayer de trouver, avec les gens en place, ce qu’ils font de bien et qui est en accord avec ces valeurs et principes. Une métho plus lourde ne ferait, selon moi, que déplacer le problème d’une métho à une autre.

En mettant systématiquement l’accent sur les valeurs et principes, j’ai découvert que les organisations tendent à trouver eux-mêmes leurs bonnes pratiques tout s’obligeant souvent à remettre en questions leurs pratiques courantes. De plus, ca les force à s’ouvrir au monde extérieur et à garder un esprit ouvert vs tout ce qui pourrait les aider à faire du meilleur logiciel tout en misant sur le facteur humain.

Ultimement, ce qu’on essaie de faire avec Agile, c’est d’exploiter tout le potentiel de l’humain en l’incluant systématiquement à chaque étape du développement. En mettant l’accent sur l’humain, on “force” les entreprises à re-considérer chacune de ces étapes en tentant de découvrir comment on peut maximiser celles-ci à partir de ce qui existe déjà dans l’entreprise…. soit les individus, la hiérarchie et l’implication du client.

Agile, c’est un gros changement pour les grosses boîtes et le problème majeur que je rencontre très souvent, c’est la résistance au changement et la peur de la perte de pouvoir de la direction. Si on met l’accent sur ça, je crois que les gens, en général, arrivent très facilement à trouver les bonnes réponses (le bon process). Je crois que la réponse est plus dans le type d’accompagnement et qu’on arrive à leur faire comprendre que tout le monde (y compris la direction) peut gagner si ils respectent les valeurs et principes de l’Agilité et que ce n’est pas seulement une affaire de développeurs.