Bienvenue sur Développement Agile

Référence sur le développement logiciel Agile. Nous traitons de conception, de programmation, de pratiques de génie logiciel, d'essais et d'autres sujets connexes.

Une offre d'emploi inspirante

Publié par David Beaumier le mardi 15 avril 2014 à 18:22

Il y a quelques temps, mon collègue Félix-Antoine me faisait part d'une offre d'emploi se démarquant du lot. J'ai tardé un peu à la partager avec vous, mais, même si les postes sont maintenant comblés, je trouve tout de même qu'il vaut la peine d'en parler. L'offre de l'équipe de la plateforme de radio-canada.ca se distingue nettement des offres qu'on rencontre habituellement.

Offre-Emploi-Radio-CanadaBien que je trouve que l'offre parle d'elle-même, je me permet tout de même de souligner, ci-dessous, quelques points que je trouve forts intéressants.

  • Le mot ressource n'est jamais utilisé pour désigner un candidat. On utilise plutôt des mots comme "allumé" ou "personne", des termes beaucoup plus inspirants.
  • On n'utilise pas les énumérations habituelles du type "votre tâche consistera à faire ceci, cela et toute autre tâche connexe". On présente plutôt le profil recherché et les qualités attendues des candidats.
  • On met l'emphase sur les capacités du candidat à comprendre les concepts qu'à avoir un nombre minimal d'années d'expérience.
  • On utilise un langage technique juste et précis. On sait clairement quelles sont les compétences recherchées.
  • On parle de l'équipe et de contribuer à son succès en relevant des défis.
  • La terminologie Agile/Scrum utilisée indique bien dans quel cadre l'équipe oeuvre.

Embaucher un employé dans le secteur des technologies de l'information représente aujourd'hui un bon défi. Cependant, je n'ai aucun doute qu'une telle offre d'emploi aura permis à Radio-Canada de dénicher des candidats au profil recherché. Plusieurs organisations auraient avantage à sortir des sentiers battus et à s'inspirer de cette offre d'emploi lorsqu'ils présentent des opportunités de carrière en développement logiciel.

Rétrospective d’une décennie en affaires

Publié par Vincent Crépin le jeudi 6 mars 2014 à 21:03

Le mois de mars 2014 représente un moment tout spécial pour l’équipe d’Elapse Technologies. Et oui, ça fait 10 ans ce mois-ci que mon partenaire Pascal Roy et moi-même avons fondé l’entreprise. Je trouvais intéressant de partager avec les lecteurs de notre blogue une rétrospective de nos dix premières années à travailler à l'amélioration de la profession du développement logiciel.

Si on revient au tout début, en janvier 2004, l’entreprise qui nous employait alors venait d’être achetée par un gros joueur dans l’unique but de faire monter la valeur de sa propre action à la bourse. À partir de cet instant, il n’y avait plus de vision, plus d’avenir, et ce, malgré tous les efforts que nous avions investis au cours des années précédentes. Les aspects financiers étaient devenus tout ce qui comptait dans cette organisation et nous avions l’impression de n’avoir plus aucun contrôle sur la situation.

Pascal et moi avons alors discuté et convenu que nos objectifs de carrière étaient différents de ce que nous offrait cette organisation. Nous pensions sincèrement être en mesure de faire une différence dans l’industrie, si petite soit-elle. Nous avons donc établi les principales valeurs auxquelles nous croyions : indépendance par rapport aux banques et investisseurs, respect total des personnes avec qui nous travaillons quotidiennement, prudence et réflexion dans nos actions ainsi qu’excellence dans nos interventions. À partir de cette idée, nous avons recruté 5 autres personnes qui travaillaient pour la même entreprise que nous et voilà, Elapse venait de naître!

Les débuts nous prouvèrent rapidement que nos valeurs étaient bonnes. Malgré les enjeux associés au démarrage d’une entreprise, nous sommes passés au travers des premières années grâce à l’appui de fidèles clients et de partenaires d’affaires. J’en profite pour souligner au passage le soutien de mon bon ami Yves Bilodeau durant cette période.

Si Elapse est devenue ce qu’elle est aujourd’hui, une entreprise qui peut faire une différence pour ses clients par la qualité de ses interventions, c’est grâce à son équipe.  Bien sûr, certaines personnes nous ont quitté en cours de route, ça fait partie de la vie d’une entreprise. Cependant, nous avons toujours misé sur la rétention de nos gens. Pour une firme qui recrute des individus d’exception, je dois vous dire qu’il est essentiel d’être capable de bâtir une relation de confiance durable. Probablement que notre modèle de transparence à livre ouvert y est aussi pour quelque chose. En tout cas, je suis fier de pouvoir vous dire que les résultats démontrent que nous avons fait de bons choix.

Au cours de cette première décennie l’offre de services d’Elapse a beaucoup évolué. L’accompagnement et la formation sont venus s’ajouter au service-conseil. Nous avons développé  des spécialités très en demande comme l’agilité, l’architecture de solutions et la conception logicielle, pour ne nommer que celles-là. En fait, l’agilité s’est imposée d’elle-même au fil du temps. Lorsqu'on prend un peu de recul, on peut remarquer que les valeurs de respect, de collaboration et de transparence que l'on associe avec le développement Agile sont aussi fortement alignées avec les valeurs fondamentales de notre organisation. L'agilité est devenue notre approche de choix pour amener les équipes avec qui nous travaillons à réfléchir sur leurs façons de faire et leur permettre d’envisager de nouvelles pratiques pour mieux atteindre leurs objectifs.

Je me dois évidemment de souligner la confiance que nous a accordée notre clientèle au fil des ans. Nous sommes conscients des opportunités fantastiques  qui se sont présentées à nous et nous sommes immensément fiers d’avoir pu relever ces défis en collaboration avec nos clients.

En rétrospective, je suis très fier d’être associé à une équipe passionnée et motivée à rendre la profession du développement logiciel meilleure. Des gens qui croient qu’on peut faire mieux chaque jour pour faire progresser les règles de l’art et qui n’hésitent pas à sortir de leur zone de confort et proposer des solutions novatrices et originales.  D’ailleurs, nous sommes toujours à l’affut de personnes exceptionnelles qui partagent nos valeurs et qui souhaiteraient faire partie de l’aventure pour la seconde décennie.

Ah oui, il faut que je vous dise en terminant qu’au cours de l’année qui vient nous comptons célébrer cet anniversaire en grand et partager avec vous encore plus de contenu relié au développement logiciel. Nous vous invitons à continuer à nous suivre sur notre blogue et sur les médias sociaux pour ne rien manquer de tout ça.

Mots-Clés :

La saison des évaluations annuelles

Publié par David Beaumier le mercredi 18 décembre 2013 à 21:05

Avec la saison du rhume et les premières neiges revient la période des évaluations annuelles des employés. Chaque organisation possède une façon bien à elle pour gérer ces « cérémonies ». Une chose est certaine toutefois, plusieurs redoutent cette période. Et ce, autant d’un côté que de l’autre du bureau.

Il existe plein de techniques pour mener ces rencontres : des formulaires, des procédures et tout le tralala. Ça vaut la peine de structurer le processus, aucun doute.  Cependant, la réflexion qui me vient chaque année est la même : au-delà des critères « comportementaux » de chacun des employés (ponctualité, assiduité, respect des politiques, etc.), est-ce que la majorité des gestionnaires en développement logiciel sont bien outillés pour souligner l'apport des personnes les plus méritantes et, bien entendu, pour favoriser la progression professionnelle de leurs équipiers?

Impliquer l’équipe dans l’évaluation

Une chose est certaine, qui est mieux placé que ceux qui côtoient une personne pour évaluer son travail et son apport à l’équipe? Je ne propose pas de remplacer l’évaluation annuelle par un sondage dans l’équipe. Ce n’est quand même pas un concours de popularité! Cependant, la perception des pairs est un aspect important. Il est peut-être plus simple de juger de la performance d’un employé en se basant sur un ensemble de faits récoltés aupès de l'équipe que de dresser un portrait complet à partir d'une feuille blanche. Pour ce faire, plusieurs recommandent que les mesures utilisées dans l’évaluation viennent directement de l’environnement de travail.

Certaines organisations Agiles ont mis sur pied des systèmes d’évaluation assez sophistiqués pour obtenir une rétroaction de l’équipe sur les performances individuelles. L’exemple d’eBay est assez intéressant, mais ce n’est pas à la portée de toutes les équipes, soyons honnête. 

Des façons  de faire plus simples peuvent être mieux adaptées à une organisation de plus petite taille. Pensons à une approche où chaque membre de l’équipe se voir attribuer un certain nombre de cartes de félicitations qu’il peut attribuer à un collègue qui fait un bon coup. Cela permet de souligner des situations qui sortent de l’ordinaire. Par exemple, je peux remettre une carte à ma collègue Jacinthe parce qu’elle est venue me donner un fier coup de pouce pour préparer l’analyse d’une nouvelle fonctionnalité alors qu’elle était déjà occupée avec son propre projet.

Ce n’est peut-être pas aussi scientifique, mais ça favorise la collaboration dans l’équipe et cela permet d'identifier les personnes qui se dépassent et ceux qui ont peut-être besoin d’encouragements additionnels pour le faire.

Mesurer l’apport à l’équipe

On peut aussi être tenté de mesurer l’apport d’un individu dans son équipe. C’est faisable, mais il faut être prudent lors de la sélection des indicateurs. Une personne peut aider beaucoup ses collègues tout en n’étant pas celle qui écrit le plus de lignes de code ou celle qui règle beaucoup d’anomalies. Comment mesurer l’apport d’une personne qui a tendance à identifier beaucoup d’anomalies pertinentes lors des revues par les pairs par rapport à une qui est moins rigoureuse?  Ce n’est pas facile d’obtenir une mesure quantitative de cet aspect.

Évaluez souvent

S’il est bon pour l’équipe de faire une rétrospective chaque Sprint (donc au moins une fois par mois) pourquoi faudrait-il attendre 12 mois pour évaluer le rendement d’un employé? La boucle de rétroaction est inutilement longue, ce qui limite grandement la possibilité pour l’employé d’apporter des correctifs à son travail. Serait-il possible de rencontrer les équipiers 2 fois par année? 3 fois? À chaque fin de livraison? Quitte à réserver la question salariale pour la dernière rencontre, si c’est la politique de l’organisation.

À mon avis c’est souvent plus rapide de procéder par des rencontres plus courtes et plus fréquentes. En plus, lorsqu’on n’évalue qu’une seule fois par année on a tendance à souligner plutôt les mauvais coups, car ce sont eux que l’on retient plus (c’est humain je crois). Dans leur livre Behind Closed Doors : Secrets of Great Management, Rothman et Derby associent trois conséquences principales au manque de rétroaction par les gestionnaires :

  • Perte de confiance de la part de l’employé;
  • Perte de productivité de l’employé et de l’équipe;
  • Ressentiment de l’équipe, particulièrement dans les cas où un membre ne contribue pas à sa juste mesure.

Adoptez une évaluation à double sens

Pourquoi ne pas demander aux employés d’évaluer leur gestionnaire immédiat en plus de leur performance individuelle? Si cela est fait dans le respect et qu’un lien de confiance mutuel est installé entre les deux individus, une telle activité ne peut être que bénéfique. Peut-être les équipiers trouvent-ils que leur gestionnaire ne communique pas assez? Se peut-il qu’ils trouvent les rencontres de l’équipe trop longues et pas assez structurées? C’est en échangeant que l’on peut s’améliorer.

Références

En terminant, je me permet de vous proposer quelques références additionnelles.

Et vous, comment avez-vous adapté le processus d'évaluation dans votre équipe Agile? N'hésitez pas à partager vos impressions, commentaires et suggestions. Joyeuse saison des évaluations annuelles!

Faire le point sur l'état de Scrum dans votre équipe

Publié par David Beaumier le mardi 19 novembre 2013 à 16:18

Dernièrement, je parlais avec un collègue qui m'expliquait, en ses termes, que l'Agilité dans son équipe allait plutôt bien. Ça fait quand même près de deux ans qu'ils utilisent Scrum. En même temps, il était aussi conscient que l'équipe avait certaines lacunes et qu'il y avait encore place à l'amélioration. Malgré tout ce temps, l'équipe n'en était pas rendue à sa phase de performance, tel que décrit dans le modèle de Tuckman.

C'est bien d'admettre qu'on peut faire mieux, mais comment identifier clairement les éléments sur lesquels l'équipe pourrait travailler? J'ai alors pensé lui proposer le Test Nokia, aussi connu sous le nom de test Scrum But. Originalement développé en 2005 par un consultant qui oeuvrait chez Nokia, ce test a été amélioré au fil du temps. En 2008, Jeff Sutherland (le co-créateur de Scrum) a ajouté un système de pondération en remplaçant les réponses oui/non par des choix multiples.

C'est un test assez rapide à compléter (environ 5 minutes) et il en existe des versions électroniques qui comptabilisent les résultats automatiquement et vous donnent un score global (sur 10 points). Selon Sutherland, une équipe qui prend le test au sérieux et se sert des résultats initiaux pour s'améliorer va grandement augemer sa vélocité: "We are finding that for teams that can establish a baseline velocity, raising the score two points will typically double velocity and quality. Raising to over 9 out of 10 will triple velocity.".

Voici quelques versions disponibles sur le Web:

Il est vrai que le test a été maintes fois critiqué pour sa simplicité et le fait qu'il ne couvrait pas tous les aspects d'une équipe Agile. En même temps, il couvre les aspects fondamentaux et essentiels de Scrum. Si votre équipe obtient un score plus élevé que 9, peut-être auriez-vous effectivment avantage à identifier d'autres aspects à mesurer afin de continuer à vous améliorer.

Je vous invite à faire le test vous aussi et ainsi faire le point sur l'état de Scrum dans votre équipe. Je suis certain que cela pourra alimenter certaines discussions lors de votre prochaine rétrospective!

One more time...

Publié par Louis-Philippe Carignan le mercredi 2 octobre 2013 à 11:00

In 1968, Frederick Herzberg published the article "One More Time: How Do You Motivate Employees?" in the Harvard Business Review (HBR). Over time, it has become a HBR classic, having sold 1.2 million reprints by 1987 and was the most requested article from the publication.

During the annual meeting of Scrum Trainers at Scrum.org last June, I had the chance to hear Mike Vincent give a 15 minute introductory talk about this article. Time not being on my side at that moment, I had to put this article in my backlog until I could have some time to read it. Now, months later, with some free time, I had the opportunity to dwelve into the article. It was such an enlighting text that I decided to write a blog post about it because I feel Agile coaches, Scrum Masters and managers could benefit from this article.

The article is about 15 pages long, including a retrospective commentary as I read the 1987 publication which included comments from Herzberg at the end. The article is divided in three sections:

  • Myths about motivations
  • Hygiene versus motivators
  • Job enrichment

Here's a summary of each sections in the hopes that it will incite you to read the article.

Myths about motivations

The article starts with some humour about how to motivate employees with the good old kick in the ass, which the author refers to KITA. He goes on by identifying different types of KITA:

  • Negative physical KITA: This is literally kicking someone in the ass to get him to do something. Obviously, it won't produce any positive long term effects on the employee.
  • Negative psychological KITA: Same as above but with no visible traces.

Herzberg then uses the example of his dog to explain positive KITA. He says that when he wants his dog to do something, he shows him a biscuit and gives it to the dog once it has accomplished his task. The same goes for employees. The rational is that the company will give money to the employee in exchange for some tasks. While this is perceived as motivation, Herzberg states that it is positive KITA. The manager is motivated by showing the cookie. The employee just produce movement.

He then comes back to what is motivation and how KITA isn't producing motivation. For Herzberg, and I agree with him, KITA produces movement, not motivation. He then list 9 myths about motivation, or what he calls other forms of positive KITA. For each myth, he takes one or two paragraph to explain what it is, why it is not motivation and why it failed. Here's how I summed up each myth:

  • Reducing time spent at work: Motivated people want to work more, not less.
  • Spiraling wages: The only motivation in this is to wait for the next pay raise.
  • Fringe benefits: More cookies to the dog will just get more movements, not more motivation.
  • Human relations training: Managers did not know how to communicate.
  • Sensitivity training: Employees did not appreciate how managers were trying really hard to communicate.
  • Communications: Employees and managers did not understand each other.
  • Two-way communications: Employees and managers still did not understand each other.
  • Job participation: Employees did not know why they were involved in the company.
  • Employee counseling: Employee's emotions were getting in the way of their rational acts of work.

Having established that these myths got us nowhere, Herzberg sets the table for part two where he presents his theory about motivation.

Hygiene and motivators

Herzberg starts by restating the title of the article: How do you install a generator in an employee? He then goes on saying that satisfaction and dissatisfaction are not opposite but orthogonal (separate and distinct). For Herzberg, the factors involved behind employee dissatisfaction are not the same ones behind employee satisfaction. Each theme must be treated seperately. As quoted from the Herzberg article: "The opposite of job satisfaction is not job dissatisfaction but, rather, no job satisfaction; and similarly, the opposite of job dissatisfaction is not job satisfaction, but no job dissatisfaction."

Herzberg states that hygiene factors will eliminate job dissatisfaction while motivators will improve job satisfaction. He also adds that hygiene factors are external while motivators are internal.

Hygiene factors are:

  • Company policies
  • Supervision
  • Relationship with supervisor
  • Work conditions
  • Salaries
  • Relationships with peers
  • Status
  • Security

I find these factors palpable. I can read the policies. I can talk to my supervisor. Salaries are tangibles. Work conditions and status (business cards, corner office) are concrete things.

While motivators are internal to each person:

  • Achievement
  • Recognition
  • Work itself
  • Responsibility
  • Advancement
  • Growth

I can't touch any of these factors. They are harder to measure objectively. Each person might have different perspective on each motivator.

The hygiene factors will only prevent job dissatisfaction. But they won't bring any job satisfaction. Policies, status, salaries and other hygiene factors have to be taken care of to eliminate job dissatisfaction. But they won't produce job satisfaction. This is where the manager should work with growth, responsibility and other factors listed above.

Job enrichments

In this final section, Herzberg gives a 10 steps recipe to enrich the jobs of employes. I had a hard time agreeing with some steps. For example, step #7 states that employees should not be involved in enriching their jobs because it will only provide a sense of participation, which is a myth of motivation that Herzberg stated earlier. To help the readers have a better idea of what job enrichment consist of, Herzberg gives a list of examples and how they follow the principles of job enrichment.

Parallels with Agile

On page 10 of the article, Herzberg presents a list of principles on which to enrich the job of workers. While reading them, I could easily make links to what Agile and Scrum promotes. Here is the list of principles listed by Herzberg:

  • Removing some controls while retaining accountability.
  • Increasing the accountability of individuals for own work.
  • Giving a person a complete natural unit of work.
  • Granting additional authority to employees.
  • Making periodic reports directly available to the workers themselves rather than the supervisors.
  • Introducing new and more difficult tasks not previously handled.
  • Assigning individuals specific or specialized tasks, enabling them to become experts.

I can draw so many parallels with Scrum in this list. For me, a user story is a great example of giving a person a complete natural unit of work. The theme of self-organisation in Scrum is, for me, found easily in most of the principles above. I can see the transparency pillar of Scrum in the principle of making periodic reports available to workers and a great way to do this for me is with visual management. The Agile principle that asks to "give them the environment and support they need, and trust them to get the job done" is, in my opinion, all about the hygiene factors.

Herzberg adds a 2 page retrospective commentary at the end of the article. In it, I find this paragraph interesting:

"By backing into the system, you can identify who serves whom - not who reports to whom - which is critical in trying to enrich jobs. You identify the external client, then the core jobs, or internal client jobs, serving that client. You first enrich the core jobs [with the job enrichments mentionned in the article] and then enrich the core jobs that serve these internal clients"

 

I feel that we have been doing the same thing with Scrum. We start by identifying the Product Owner (PO), the person who is the client, and then assemble a development team that will serve this client. As we can have a core team (or core jobs to use the words of Herzberg), we can also enrich them with Subject Matter Expert (SME). For example, you might need a technical writer or a UX designer for a few sprints to help the core jobs of developers, testers and analysts on the development team.

Herzberg gives the example of a case study he did at the U.S. Air Force where he states:

"The avionics mechanic's external client is the test pilot, and although he reports to his supervisor, his supervisor serves him. The sheet metal mechanic and the line mechanic serve the avionics mechanic. And so on back into the system"

 

Conclusion

My first impression about this article is its accessibility. It is an easy read written in terms and with a style that everybody can understand. For Agile coaches out there who would like to discuss this topic with Scrum Masters or managers, it is easy to get together around a lunchbox and talk about it.

I also find the information to be hands-on. Once I was done reading this article, I had a new tool in my toolbox. I knew to look for hygiene and motivators factors around my teams. For example, one of my items on my action list could be to do a survey of which hygiene factors are not addressed in my teams. In other words, the call-to-action after reading this article is pretty easy to imagine in my opinion.

Finally, I find the conclusions of Herzberg have a striking ressemblance to what the Agile community has been promoting for the last 12 years. Whatever your looking glass (Scrum, XP, Kanban, Lean), this article fits well with what we are advocating in our industry. As Agile is sometimes said to be how we used to do software 50 years ago, I hope this old article will also become, once again, very popular with the new generation of IT professionals.

Mots-Clés :

Archive