Category : Scrum

Comment décider quand on est 7 à le faire?

Certes, la prise de décision en équipe est moins rapide que lorsqu’elle est prise par un seul individu : chacun doit s’exprimer; il faut organiser des rencontres, produire des comptes rendus, gérer des situations conflictuelles; et tout cela coûte cher. Dans certains cas, il peut même être risqué de communiquer toutes les informations nécessaires.

Pourtant, nous avons la conviction que ça vaut la peine. Nous croyons que les décisions prises en équipe sont plus éclairées, car il y a partage et prise en considération de plus de renseignements. Ensemble, le groupe trouve plus d’idées et de solutions possibles pour résoudre un problème. Prendre une décision en équipe, ça permet aussi d’avoir une compréhension commune du contexte et aussi des raisons qui motivent cette décision. Et tout cela aide surtout pour la suite. L’application de la décision sera facilitée parce que les gens auront participé activement aux choix qui ont été faits. Sans implication, il est très difficile d’aller chercher un réel engagement.

Continue Reading

Achievements : seulement pour les jeux ou pour l’Agilité aussi?

J’ai récemment découvert un ajout intéressant à Visual Studio : les achievements (réalisations). Il s’agit d’un plugiciel que l’on peut installer dans notre environnement de développement et qui permet d’obtenir des médailles (ou badges) que l’on appelle achievements.

Un jeu d’enfants, pas vraiment

Le concept est inspiré des plateformes de jeu. Dans la plupart des jeux modernes, il existe ce concept d’achievement que l’on peut débloquer en réalisant certains exploits lors de nos quêtes. Par exemple, réussir à ramasser tous les jetons d’un niveau ou réussir sans se servir de pouvoir spécial.

Continue Reading

La mesure du succès — Comment vérifiez-vous le succès de vos projets?

Moi qui suis toujours à la recherche de nouveaux moyens pour atteindre les objectifs fixés par les projets, j’ai été interpellé par cet article: Après avoir dépensé 75 millions de dollars, le gouvernement du Québec suspend le projet d’informatisation du système judiciaire, voué à l’échec. Pas tellement parce que c’est un projet public, mais plutôt parce que je crois que le marché du développement logiciel manque toujours d’expertise pour assurer le succès de ses projets. La citation de Michelle Courchesne résume très bien le symptôme: « … On ne peut pas attendre d’avoir dépensé les 105 millions de dollars autorisés et se dire que ça ne marche pas. Sinon, après, il faudra donner encore plus d’argent. C’est fini ça, on ne peut plus faire ça. »
Continue Reading

Vous avez dit DDD, Demo Driven Design?

Être agile

Pour moi être agile c’est savoir s’adapter, éviter les mauvais coups. Un boxeur agile ne frappera pas nécessairement plus fort ou précis mais il recevra moins de coup. Un joueur de hockey agile ne comptera pas nécessairement plus de but mais il pourra se rendre plus souvent dans la zone pour le faire.

Un développeur agile n’est pas vraiment plus rapide qu’un autre, il sait juste éviter les récifs comme s’il descendait les rapides en kayak. Le développeur agile voit venir les coups et sait les éviter. Il sait même se mettre dans une situation où il sera en meilleure posture pour les éviter.

S’adapter c’est développer ses forces pour contrer les problèmes rencontrés. S’adapter c’est aussi laisser de côté ce qui ne fonctionne pas et utiliser ce qui fonctionne. La nature a évolué depuis des millions d’années comme ça. Il faut arrêter de faire ce qui ne fonctionne pas pour ne pas se faire déclasser pas les autres.

Continue Reading

Comment créer des équipes performantes

J’animerai le prochain rendez-vous Agile sur la création d’équipes performantes. Je vous invite à vous joindre à nous le 7 décembre prochain. Venez recevoir des conseils pour être plus efficace dans la prise de décision en équipe et pour savoir engager vos équipes et les responsabiliser.

L’événement débutera à 8 h, pour une durée de 2 heures. Un petit déjeuner sera servi.

Inscrivez-vous maintenant, les places sont limitées.

Au plaisir de vous y voir!

Pyxis est à la recherche des meilleurs praticiens de l’Agilité.

La vague de l’Agilité s’installe à Montréal et à Québec. Pour bien surfer sur cette vague, Pyxis est à la recherche de 9 personnes qui se joindront à son équipe Agile.

Les rôles à pourvoir sont les suivants :

En vous joignant à notre équipe Agile, vous découvrirez des gens passionnés de l’Agilité qui ont à coeur la réussite des projets de développement auxquels ils participent. Vous allez vous surpasser, relever des défis et guider des équipes de développement.

Au cours des 10 dernières années, Pyxis a été un acteur dans la mise en place de l’Agilité à Montréal et à Québec. Pyxis étant fondateur du groupe Agile Montréal et partenaire actif d’Agile Québec, vous avez sûrement déjà rencontré un Pyxissien lors d’une conférence Agile. Pyxis offre aujourd’hui une gamme complète de services de coaching et de formation Agile pour bien répondre aux besoins des équipes de développement Agile.

Faites partie du mouvement Agile avec Pyxis!

“a working proposal” : semaine 3/3

C’est toujours émouvant pour moi d’arriver à ce qui semble être la “fin” d’une aventure. Depuis 3 semaines nous avons eu cette journée en point de mire. La construction de cette offre autour d’un logiciel qui fonctionne chaque semaine a été le fil rouge qui m’a guidé dans une foule d’autres activités.

Ce que j’ai aimé dans cette expérience:

  • binômer avec Xavier
  • avoir un fil rouge parmi une foule d’autres activités

Pour que cela soit parfait, faudrait-il que notre prospect décide de poursuivre ou bien est-ce que cela va chercher ailleurs ? Cette idée de “gagner la propale” dans le future rend-elle meilleure l’expérience passée ?

Comme on nous l’a dit souvent, c’est plus l’aventure, le parcours qui nous rend heureux, moins que la destination. Alors je n’ai pas d’idée pour améliorer l’aventure ; le logiciel oui ;)

“a working proposal” : semaine 2/3

Deuxième semaine de notre aventure de construction logiciel en parallèle de la mise au point de notre offre de développement. Bien sûr cette semaine s’achève avec une revue d’itération et une rétrospective.

C’est l’occasion pour nous de faire le point sur notre incrément, le produit dans son ensemble, notre compréhension actuelle d’une stratégie incrémentale pertinente pour atteindre les objectifs visés. Pour cela nous nous sommes retrouvés autour du second incrément déployé sur Heroku, autour de notre Product Backlog et de notre propale.

La semaine dernière nous n’avions pas partagé avec notre prospect l’incrément réalisé. Cette semaine c’est différent. Maintenant que nous avons deux incréments, nous avons de quoi démontrer ce que veut dire “construire un logiciel par incréments successifs”. Il se trouve que notre prospect n’a jamais travaillé de cette manière. La semaine dernière nous avions décidé de déployer certes mais sans le lui dire. Notre sentiment était que la notion d’incrément risquait d’être très théorique à ce stade. Maintenant nous avons deux incréments, avec des adresses distinctes. On peut donc voir concrètement l’ajout de fonctionnalités entre les deux versions. Quel sera son feedback ? Suspence…