Peut-on faire de l’Agilité en Recherche et Développement?

OUI !

Mais bon, lisez quand même l’article, ca me fera plaisir 🙂

J’ai récemment monté et présenté un atelier de mise en contexte Agile pour des chargés de projet qui ne sont pas liés à des projets informatiques, mais à de la R&D.

Lire la suite

Pourquoi visualiser notre travail?

Cet article a été rendu possible grâce à la collaboration de mes collègues Éric Wursteisen et Caroline Humbert. Éric a contribué au remue-méninges de l’atelier et Caroline a été la première à l’animer avec son équipe et sa rétroaction et ses commentaires ont été intégrés.

Si vous êtes comme nous, la plupart de vos interventions comme coach ou Scrum Master ont un lien avec la visualisation du travail.

Or, plusieurs personnes ne comprennent pas pourquoi et comment il peut être bénéfique de visualiser leur travail. Tout est dans leur tête ou disséminé ici et là et elles vivent très bien avec ça. Peut-on leur démontrer par un mini-exercice les bienfaits d’une visualisation, aussi simple soit-elle?

Cet article présente un atelier simple qui ne parle que de visualisation des travaux.

Lire la suite

Prendre des décisions Agile et Lean

Au delà des méthodes et des pratiques, il y a les concepts de base. De nos jours, Agile et Lean sont devenus des buzzwords qu’on utilise à toutes les sauces. Pourtant, quand on creuse la question, on réalise souvent que notre interlocuteur n’a aucune compréhension de la philosophie derrière les mots.

Que se cache-t-il derrière ces grands concepts? Qu’est-ce qui distingue quelqu’un qui est Agile et Lean de quelqu’un qui ne l’est pas?

La réponse réside dans la façon dont les décisions sont prises. Pour déterminer si une méthode, une décision ou une pratique est Agile et Lean, on doit la peser selon un filtre décisionnel bien précis.

Lire la suite

Être performant, une étape à la fois…

Très régulièrement, coachs Agile et Scrum Masters se font demander par certains gestionnaires de rendre leurs équipes performantes. Objectif louable en soi, mais qui peut être difficile à atteindre s’ils ne donnent pas également leur définition de « performante ». Pire encore, souvent, coachs Agile et Scrum Masters ne la demandent pas non plus et ça laisse place à de la confusion, une mauvaise compréhension du besoin et crée de fausses attentes.

En voici quelques exemples : les joueurs d’une équipe n’ont que quelques sprints derrière la cravate ensemble et certains gestionnaires se demandent pourquoi ils ne sont pas performants. D’autres comparent la vélocité de leurs équipes et aimeraient que celle-ci augmente comme celle de l’équipe qui cumule le plus de points sprint après sprint. D’autres se disent « Je ne comprends pas, cette équipe est composée de tous nos meilleurs joueurs, mais malgré tout, elle n’arrive pas à atteindre le niveau de performance qu’elle devrait avoir ! »

Lire la suite

Une revue de sprint n’est pas une démo

(English follows)

Faites-vous des revues de sprint, démo ou un mix des deux? Le faites-vous de la mauvaise façon? Ne pas le savoir peut être coûteux. Par exemple: sentez-vous que vous devez sacrifier des fonctionnalités pour préparer vos revues de sprint ou vos démos? Malheureusement, plusieurs équipes Agile le font. Voici comment éviter ce piège en comprenant la différence entre ces deux événements.

Lire la suite

Passer des fausses certitudes aux doutes adaptables

(English follows)

Avant de donner un GO à un nouveau projet ou lors du suivis d’un projet en cours, les parties prenantes et organisations exigeront toujours d’avoir un minimum de confiance dans la planification. En méthodes traditionnelles (e.g. en cascade), ceci se reflète souvent par un besoin de savoir exactement ce qui va être fait, quand ce sera fait et à quel prix. Comme nous le savons maintenant, peu importe la précision de ces prédictions initiales, la réalité en constant changement du projet a tendance à rendre le plan inapproprié. Dans de telles cultures de développement, minimiser les écarts face au plan est plus important que de maximiser la valeur du projet.

Lire la suite

Planifiez-vous pour gagner ou pour ne pas perdre?

low-bar

(English follows)

Imaginez que, en tant que membre d’une équipe Agile, vous tentez quelque chose de nouveau afin d’augmenter la qualité de votre produit et que ça ne fonctionne pas. Qu’est-ce qui fait le plus mal? Devoir re-planifier et essayer de nouveau ou devoir rendre des compte sur cet échec?

Imaginez maintenant que vous, toujours en tant que membre d’une équipe Agile, devez faire des choix difficiles dans la gestion de votre temps suite à des imprévues ayant décuplé la grosseur de l’une de vos tâches. Qu’est-ce que vous regretteriez le plus? Ne pas pouvoir augmenter la qualité du produit ou avoir manqué votre estimation?

Voyez-vous où nous allons avec ceci?

Lire la suite

Les 7 flexibilités du backlog Agile

(English follows)

Comment un backlog Agile peut-il survivre à la tempête d’un projet tout en livrant une solution cohésive? En grande partie, ceci vient de ses multiples niveaux de flexibilité. La vision d’un projet, décrite dans un tel backlog, devient adaptable à plusieurs, ou même à la majeure partie, des changements auxquels un projet fait face. Regardons ces options de flexibilité par ordre d’impact croissant sur la portée et la qualité.

Lire la suite

C’est mieux de fonctionner

(English follows)

Le développement logiciel est déjà difficile et, pourtant, face à un choix entre une solution technologique difficile ou une sécuritaire, nous choisissons souvent l’option risquée, souvent accompagnées de bénéfices supérieurs.  Les raisons d’affaires derrière ce choix sont claires, mais que se passe-t-il avec l’engagement de l’équipe face à ce défis supplémentaire?  Regardons de plus près comment, en tant que membre d’une équipe ou en tant qu’équipe dans une organisation, notre engagement change radicalement dépendamment si nous partageons cette charge avec nos gestionnaires.  Ici, l’attitude du leader Agile est clé.

Pour illustrer ceci, regardons une scène du film Moneyball où Billy Bean, le directeur général d’une équipe de baseball, a une conversation avec Peter Brand, un jeune homme avec la folle idée de choisir en utilisant seulement les mathématiques.  Dans la scène, Billy et Peter observent la première pratique de leur équipe nouvellement formée de joueurs indésirables. Peter, clairement stressé par l’ampleur du risque qu’ils prennent, regarde les joueurs, alors que Billy vient vers lui et lui dit: “C’est mieux de fonctionner!” À ce moment, l’attitude de Peter passe d’un bon stress à une peur intense avec la réalisation que Billy est prêt à lui donner le blâme en cas d’échec.  Heureusement, Billy donnait dans l’humour et Peter peut donc retourner dans son état de bon stress, mais toutefois plutôt confus par le sens de l’humour noir de son patron.

Peter, sans une organisation créant un espace sécuritaire pour faire l’essai de sa théorie, n’aurait jamais travaillé sur son idée.   Aussi, Billy aurait pu dire à Peter de mettre en place son idée, tout en le prévenant qu’il serait (Peter) responsable en cas d’échec.  Dans ce scénario, Peter aurait soit refusé l’emploi, soit fait trop de compromis pour éviter l’échec.  En réalité, dans notre histoire, Billy avait vraiment créé un espace sécuritaire dans lequel Peter pouvait prendre des risques, vivre des échecs, apprendre de ces derniers et prendre de nouveaux risques.  Bien que Peter soit responsable de la réalisation de son idée, Billy est clairement imputable d’avoir pris cette nouvelle direction. Cette collaboration, basée sur la confiance, les engage vers un but commun.

Créer un espace pour votre équipe demande un bon effort.  Se joindre à eux dans cet espace est le vrai défi.

tumblr_nhkky7aA0n1s0t6o2o1_500

Phillipe Cantin

This better work

Software development is hard enough, yet, when faced with the choice between a difficult or a safe technological path, we tend to choose the riskier one which often comes with better results.  The business reasons behind such a choice are obvious, but what about the team’s engagement toward this extra challenge?  Let’s take a particular look at how, as a team member or as a whole team inside an organisation, our commitment will change dramatically whether or not we are sharing the load with our leadership.  Here, the Agile leader’s attitude is key.

To illustrate this, let’s look at a scene from the movie Moneyball where Billy Bean, a baseball team general manager, is having a conversation with Peter Brand, a young guy with the crazy idea of selecting players using only math.  In the scene, Billy and Peter are witnessing the first practice of their newly formed team composed of unwanted players. Peter, clearly stressed by the huge risk they are taking, is observing the players as Billy Bean walks up to him and says : “This better work.”  At this moment, Peter’s mood changed from healthy stress to pure fear with the realization that Billy was ready to blame him personally if the plan fails.  Luckily, Billy was only joking and Peter could return to his healthy stress, now combined with the knowledge of his boss’s dark sense of humor.

Peter, without an organization creating a safe space to test his theory, would have never fully tried his idea.  Also, Billy could have initially told Peter to implement his idea while warning him that he (Peter) would be held responsible in case of failure.  In this scenario, Peter would have either not accepted the job or over-compromised in order to avoid failure.  In the actual story, Billy did create a safe space for Peter to take chances, fail, learn and try again.  Also, even though Peter is responsible for the implementation of his idea, Billy is clearly accountable for the decision of trying this new approach. This collaboration, based on trust, engages both of them in the same goal.

Creating a safe space for your team takes effort.  Standing in that space with them is the real challenge.

tumblr_nhkky7aA0n1s0t6o2o1_500

Phillipe Cantin

Astéroïdes – un vrai jeu Agile!

En 1979, Atari lançait le jeu Asteroids… un vrai jeu Agile!

L’utilisation des métaphores et des analogies est une technique de coaching efficace et bien connue.  Elle permet de déplacer une personne de son environnement de travail vers un environnement autre, mais familier, et de discuter de concepts tout en réduisant les « oui, mais ça marche pas comme ça ici ». En voici une qui permet d’expliquer un grand nombre de concepts Agile dans un ensemble cohérent: Lire la suite