Scrum - Méthodes agiles

Dans mon billet d'hier, je trouvais abusif la référence à une culture française spécifique à propos du suivi de projet. Coïncidence, je viens de trouver l'usage de la même expression franco-française sous la plume de Louis Naugès, mais cette fois je suis bien d'accord avec son emploi.

Il y a plus d'un an, je constatais qu'une organisation de type MOA MOE provoquait souvent une division du travail à l'opposé des recommandations des méthodes agiles. L'Agilitateur avait apporté, avec brio comme d'habitude, des compléments sur l'origine de cette pratique, qui est répandue dans nos administrations et nos grandes entreprises.

Bonne nouvelle, Louis Naugès a assisté à la présentation d'un rapport du CIGREF sur le thème système d'information et création de valeur et nous dit dans le billet qui en parle :

Il signe en tout cas la mort définitive d’une invention franco-française qui a fait beaucoup de dégâts, la séparation maîtrise d’ouvrage, maîtrise d’œuvre.

La mise en oeuvre d'une méthode agile y contribue en forçant à la collaboration au sein d'une seule équipe, je le constate dans les organisations basées sur ces notions de maîtrise d'ouvrage et maîtrise d'oeuvre et qui passent à Scrum.

Les équipes agiles sont plus efficaces avec des généralistes ou des spécialistes qui se généralisent

Lire la suite -->

Emmanuel Chenu a publié des illustrations sur les principales pratiques de Scrum et de l'Agilité. Les dessins sont en anglais et les commentaires qui les accompagnent sont en français.
C'est sympa, mais pourquoi sont-ils tous chauves ? Dans un genre différent, j'utilise maintenant les icônes de IceScrum pour illustrer les rôles Scrum dans mes formations et mes présentations :

Vous avez reconnu les différents rôles ?

Le manifeste agile rappelle que les personnes et leurs interactions sont plus importantes que les processus et les outils. Faire un outil qui reste dans cet esprit tout en assistant utilement lors de l'application d'une méthode agile, ce n'est pas facile. Le pari a l'air réussi pour la nouvelle version d'IceScrum.

Lire la suite -->

Avec le Product Owner

Lire la suite -->

Il n'y a pas que l'utilisateur et l'administrateur ...

Lire la suite -->

Un découpage plus fin qu'avec Scrum ou XP du rôle de représentant des clients

Lire la suite -->

Je viens de lire Project Management and Scrum – A Side by Side Comparison(pdf), une comparaison entre le rôle traditionnel de chef de projet (selon le PMBOK) et le rôle de ScrumMaster. Cette comparaison factuelle montre un grand nombre de différences ce qui est normal puisque les principes de management du PMBOK et de Scrum sont radicalement opposés. Des billets récents de l'Agilitateur donnent sur le sujet un point de vue complémentaire.

L'existence simultanée des 2 rôles dans une organisation est d'ailleurs possible provisoirement^[1]. De nombreuses activités de gestion de projet comme le reporting^[2], la participation au comité de pilotage, le budget, la gestion des ressources humaines ne sont pas faites par le ScrumMaster qui se consacre uniquement à l'animation de l'équipe.

Nous sommes 33 sur le projet Wilos, c'est bien plus que la taille normale d'une équipe Scrum.

Lire la suite -->

Un résumé du rôle de ScrumMaster, l'animateur d'une équipe qui applique Scrum.

Lire la suite -->

Un résumé du rôle, appelé Product Owner dans Scrum et Customer dans XP

Lire la suite -->

Le rôle de "client" dans Scrum s'appelle Product Owner. Je l'ai traduit jusqu'à maintenant par propriétaire de produit. Je joue ce rôle sur des projets, je le connais bien, mais le terme propriétaire ne m'a jamais bien plu. Client ne convient pas non plus. Je viens de lire How to be a Product Director de Brian Marick. Il propose d'appeler ce rôle directeur de produit. Il justifie pourquoi. Je trouve ça très bien, je vais l'adopter.
Rappel : dans Scrum il n'y a que 3 rôles : l'équipe, le ScrumMaster et donc le directeur de produit. C'est lui qui est responsable d'alimenter le Backlog avec les user stories, à destination de l'équipe.