Pour réaliser la story « tableau de bord », il faut que le composant qui envoie les données fonctionne. Il est développé par une autre équipe. Vous êtes en train de mettre à jour le plan de release, à quelques jours du démarrage du prochain sprint.
Une présentation de Tom Grant, analyste chez Forrester, met en évidence l’intérêt des jeux sérieux pour favoriser l’innovation dans les sociétés qui développent des produits : Corporate Serious Games Are Changing The Rules Of Product Development
Il montre que pour faire face aux 3 grands problèmes dans le développement : la complexité, le manque d’implication des clients et la difficulté à maintenir la dynamique de groupe, il est temps de changer les règles.
Scrum, le guide pratique de la méthode agile la plus populaire, deuxième édition
La couverture de la deuxième édition fait un peu plus rugby. Je l’avais réclamé dès la première édition, mais à l’époque ça ne se faisait pas dans cette collection chez Dunod[1].
Il y a aussi une différence dans l’épaisseur, l’édition 2 fait 304 pages, 16 de plus que la première.
Le texte de la 4ème de couverture est également changé :
La nouvelle édition du guide Scrum présente la planification de release comme une pratique en dehors de Scrum :
La planification de release est intéressante lorsqu’on pratique Scrum, mais n’est pas exigée par Scrum lui-même.
C’est une évolution car dans la version précédente, même si ce n’était pas toujours bien cohérent, la planification de release était présentée comme une pratique Scrum.
Faire un plan de release, c’est effectivement souvent utile, notamment quand on a besoin de se synchroniser avec d’autres équipes ou d’autres services de l’organisation.
Un sponsor important du projet tient beaucoup à une fonction mais ne sait pas bien de quelle façon elle pourrait être proposée aux futurs utilisateurs du produit. Vous êtes Product Owner, que faire ?
J’ai appris la mise à jour du guide Scrum de Ken Schwaber et Jeff Sutherland quelques jours après avoir envoyé le bon à tirer pour la deuxième édition de Scrum, le guide pratique etc…
Le sprint de 3 semaines a commencé vendredi, avec une équipe de 10 personnes. Le lundi lors du scrum du matin, on apprend qu’un développeur s’est cassé le bras droit au ski, il est plâtré pour une semaine.
J’avais écrit au printemps deux articles montrant comment on pouvait mâtiner Scrum avec des notions venant de Kanban. La mise en œuvre de ce ScrumBan était présentée avec un usage d’iceScrum.
Quelques mois plus tard, après du feedback d’utilisateurs et une utilisation poussée, j’ai remis à jour les articles :
En tant que consultant, j’ai la chance de travailler dans des domaines variés. Après avoir accompagné Sarenza.com dans sa transition radicale et à grande échelle à Scrum[1], j’interviens sur le projet Sirius du CNES avec Thalès.
Il s’agit de développer le patrimoine de base de la dynamique du vol, sur lequel viendront se construire les futurs outils opérationnels pour les mises à poste et maintien à poste de satellites. Sirius consiste en des bibliothèques Java sur la base de OREKIT et Commons Math.
Pour les missions délicates, comme séparer une grosse équipe en plusieurs
Demain, je pars en virée au Pays Basque avec Thierry Cros.
Dans leurs discours, les agilistes mettent en avant l’importance du collectif, avec l’équipe.
Mais quand nous faisons des formations ou du coaching, nous sommes seuls, la plupart du temps. Sauf à faire de l’accompagnement intensif qui laisse le temps de s’immerger dans une équipe, nous devons souvent prendre des initiatives et faire des proposition tout seuls.
Bien sûr, nous nous retrouvons régulièrement dans les conférences, les associations ou même pour un panier repas.
… avant les vacances.
La formation que j’ai donnée la semaine dernière à Paris était très agréable. Merci à Anna, Doriane, Arnaud, Florent, Gérald, Sébastien, Paolo, Thomas et Xavier pour leur participation active.
Ça fait plaisir de voir un groupe se former aussi vite et rester aussi motivé jusqu’à la fin des 3 jours. Plein de questions intéressantes et pas que d’Arnaud[1].
Ils peuvent s’honorer d’avoir suivi une formation agréée Fédération Agile.
Je suis joueur : après avoir lu le billet de Gokjo Adzic hier, j’ai utilisé le jeu de la randonnée en montagne au début de ma formation Scrum dès aujourd’hui.
D’habitude je demande aux participants à mes formations quelles sont leurs attentes en leur demandant d’écrire ça sur des post-it de façon individuelle. Le jeu de la randonnée en montagne permet d’aller plus loin. Premier atelier collectif, il facilite la constitution du groupe et c’est important dans une formation inter-entreprises.
J’ai le plaisir d’annoncer qu’avec mon ami Alexandre Boutin, nous organisons une formation consacrée aux serious games.
Les jeux sérieux constituent une nouvelle façon d’apprendre extrêmement prometteuse.
Ces ateliers ludiques sont le complément idéal d’une approche agile en permettant, par exemple, de construire collectivement un backlog initial à partir d’une idée de produit. Dans ce domaine de la définition de produit, les Innovations Games de Luke Hohmann font référence. J’en parle dans ce blog depuis longtemps et j’en utilise régulièrement en formation ou lors de coaching.
J’ai assisté aujourd’hui à 7 soutenances de stage d’étudiants de Master 2 de l’IUP ISI. Dans aucune d’entre elles n’a été mentionné Scrum ou agile. Des étudiants ont parfois fait du développement itératif, certains ont eu des réunions quotidiennes, guère plus.
Ça remet les idées en place. Comme je baigne dans le mouvement agile, comme je rencontre des entreprises qui y passent ou en font déjà, j’ai parfois tendance à penser (et à dire) que l’agilité est devenue mainstream.
Ce soir c’était le SigmaT18 à la Maison des Associations de Toulouse.
Ce qui aurait pu mieux se passer Plus de monde ! Nous étions une quinzaine seulement. Le temps froid pour un mois de juin qui n’a pas poussé à continuer les discussions sur la terrasse Le champ ouvert, prévu au programme, qui n’a pas eu lieu, faute de temps disponible (le retour d’expérience s’est terminé à 20h30) et de … Thierry Ce qui a bien marché L’histoire bien racontée et pleine d’enseignements de la startup Webinage La façon de nous montrer l’intérêt du feedback par l’évolution du produit depuis le backlog initial Le partage sur le retour d’expérience, avec les très nombreuses questions qui ont fusé lors de la présentation Le module 2 de la Maison des associations est agréable, la logistique impeccable pour ce type d’événement L’apéro, apporté par Marie-Josée Nous avons une nouvelle adhérente Idée Webinage pour ma mère ?
En octobre 2010, je relevais le record de 8000 visites dans le mois et j’envisageais d’arrêter le blog quand j’en serais à 10000. Ils ont été atteints en mai !
Je ne pensais pas y arriver si vite et finalement je vais continuer encore un peu à bloguer. Je vais même améliorer la présentation du blog : hier je rencontrais Damien et Matthias d’ooCube pour discuter d’un petit lifting de mon template DotClear.
On entend souvent parler de bonnes pratiques. Certains pensent que comme elles sont bonnes, elles peuvent s’appliquer partout. Mais les solutions qui ont marché ailleurs ne sont pas forcément bonnes partout et pour tout le monde.
Ce qui compte, c’est le contexte.
L’agilité doit être appliquée en tenant compte du contexte, qui peut être défini par des attributs relatifs au projet. Dans le chapitre Adapter Scrum au contexte de mon livre Scrum, la situation du projet est définie en 10 attributs.
Avec l’épisode ScrumBan au jardin, j’avais présenté une façon de mixer Scrum et Kanban. En voici une autre, toujours dans l’idée de tirer le meilleur des 2.
Cette approche est destinée à ceux qui, ayant essayé Scrum, ont trouvé que le cadre des sprints avec son cérémonial était un peu trop contraignant pour leur contexte. Généralement, ce contexte est caractérisé par une équipe légère qui reçoit un flux relativement continu d’entrées.
