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.

Coach Agile du jour : Bruce Lee

Publié par Philippe Tremblay le dimanche 19 janvier 2014 à 11:20

Il n’est pas rare de retrouver les valeurs et principes agiles énoncés dans des contextes bien différents de ceux du développement logiciel ou du manufacturier (Lean).  Souvent nous croisons ces valeurs dans des environnements où la haute performance des individus est requise.  Des contextes dans lesquels la stagnation, les idées préconçues, la peur du changement et l’inaction ne représentent pas des conditions de succès.  Aujourd’hui, l’alignement de deux de mes passions (développement agile et les arts martiaux) me permet de vous présenter un individu dont les actions et les paroles représentent bien les principes agiles : Bruce Lee.

Approche empirique

Bruce -Lee -Quote -Absorb -what -is -useful

8 Jump In The Water Bruce Lee Picture Quote1

 

Adaptation aux changements

If You Don T Want To Slip Up Tomorrow Speak The Truth Today Bruce Lee Quote

55C9ccc3e35b2f0d5727cebea4ee86f9

 

Amélioration continue

Mistakes Are Always Forgivable

10 Impossible Bruce Lee Picture Quote

3235

 

Logiciel est la principale mesure d’avancement

Bruce Lee If You Spend Too Much Time Thinking About A Thing Youll Never Get It Done

Bruce Lee Apply Do

 

Équipe auto organisée

Wise Man Learn

0Bc319ecb78b20eaa23ff7d96e8cf7b5

Mots-Clés :

What's next ... pour Agile?

Publié par Louis-Philippe Carignan le jeudi 16 janvier 2014 à 17:06

Cela fait maintenant près de 13 ans que le manifeste Agile a été rédigé et signé. Au tout début, et un peu avant même, XP, Crystal, DSDM et Scrum étaient les approches les plus souvent empruntées pour faire du développement « léger ». Pendant la décennie qui a suivi la signature du manifeste, XP, Scrum et Lean Software Development se sont distinguées du peloton. Depuis les dernières années, les sondages annuels de VersionOne ont toujours montré que Scrum et XP étaient les deux approches les plus employées sur le terrain. 

Mais les promoteurs de ces approches vieillissent. Ils sont pour la plupart dans la soixantaine. Certains ont pris leur retraite ou travaillent sur de nouveaux projets. 

Alors que se passe-t-il du côté de la relève? Qui sont les nouveaux joueurs et quelles sont les nouvelles approches qui prennent la relève? Bien que tous s’entendent dans notre communauté pour dire que la manifeste Agile survivra, avons-nous fait le tour avec l'Agilité et sommes-nous simplement rendus à répéter le message?

Voici un tour d’horizon des approches qui, à mon avis, semblent être en émergence.

Lean Startup

Piloté par Eric Ries qui a publié son livre « The Lean Startup » en 2011, ce créneau s’oriente beaucoup plus vers le côté Affaires du développement. Bien qu’il soit le seul homme au front, plusieurs livres ont été écrit en lien avec le sujet dont « The Lean Entrepreneur » et « UX for Lean Startups ». Une conférence a aussi lieu à chaque année et point important à mon avis, il a un logo pour représenter ce qu’il vend (Oups, s’cusé, promouvoit). Âgé de seulement 33 ans, nous n’avons sûrement pas fini d’entendre parler de Lean Startup. Je trouve que c’est une bonne chose que Lean Startup rayonne puisque les 10 premières années de l’Agilité étaient très orientées vers le développement. Lean Startup nous aidera à améliorer nos relations avec les utilisateurs.   

La méthode Kanban

David J. Anderson est à la tête de cette méthode qui, malheureusement, continue de s’accrocher avec Scrum. Probablement à cause des égos dans chaque camp à mon avis. Tout comme Lean Startup, les gens derrière la méthode Kanban tiennent plusieurs conférences annuelles. D’autres joueurs comme Jim Benson, Karl Scotland et Yuval Yeret viennent supporter David dans ses efforts de promotion. Des organismes comme le Lean-Kanban University (LKU) et la Limited WIP Society tentent de pousser cette approche sur plusieurs fronts. La LKU a la responsabilité de former des gens avec l’approche tandis que la Limited WIP Society tente d’être le point d’entrée de la communauté vers des ressources, blogues et outils pour soutenir la méthode Kanban.

Management 3.0

Puisque la majorité des signataires du manifeste Agile étaient fortement encrés dans le côté technique, certaines carences sont apparues avec le temps pour que l’Agilité s’établisse dans des organisations. L’une d’elle était la gouvernance ou plutôt, comment les gestionnaires (directeurs/vp/coordonnateur) doivent s’adapter pour comprendre et garder Agile vivante dans leur organisation. Publié en décembre 2010 par Jurgen Appelo, « Management 3.0 » est un livre orienté pour le gestionnaire Agile et comment ils doivent adopter leur posture lorsque l’Agilité s'enracine dans leur organisation. Par exemple, les auteurs précédant Management 3.0 donnaient peu d’explications lorsqu’ils abordaient le concept d’auto-organisation. Ils mentionnaient tout simplement que la meilleure structure d’une équipe était l’auto-organisation. Jurgen consacre plusieurs chapitres sur ce sujet pour mieux informer le gestionnaire de son rôle dans cette nouvelle structure. 

Agile Coaching Institute

Et pendant ce temps, Lyssa Adkins publie son livre « Coaching Agile Teams » en 2010. Tout comme Jurgen, Lyssa est venu répondre a un besoin manquant mais cette fois-ci, c’est au niveau des Scrum Master et des coach Agile. Encore une fois, les fondateurs de l’Agilité avaient mis l’accent sur l’équipe, le code, les bonnes pratiques (user stories, planning poker, tableau visuel) et la mécanique itérative et incrémentale. Il existait peu de livres pour parler en long et en large du Scrum Master, pourtant un rôle important dans tout ça. Lyssa a d’ailleurs fondé le Agile Coaching Institute avec Michael Spayd en 2010.  L’objectif de cet institut est de faire grandir les coach Agile qui sont des agents de transformation dans les organisation. Pour avoir suivi leur cours « Coaching Agile Teams (CAT) » et « The Coaching Stance », j’ai été très satisfait du contenu ainsi que de l’approche.

Expansion organisationnelle

Pendant que les personnes ci-haut poussent de nouvelles approches en lien avec l’Agilité, des personnes qui sont dans le domaine depuis plusieurs décennies reviennent à l’avant-front avec une façon pour élargir l’Agilité à toute l’organisation.

  • Scaled Agile Framework (SAFe) : Dean Leffingwell, un ancien vp de Rally Software et Rational Software, offre un cadre de développement Agile qui s’étend à toute l’organisation. Intitulé « Scaled Agile Framework », il divise l’organisation en trois couches pour qu’elle livre de la valeur au client : Portfolio, programme et équipe. Le site web de SAFe est particulièrement bien fait avec un schéma global détaillé qui permettre au lecteur d’approfondir les sections qu’il désire.
  • Path to Agility (PtA) : Peut-être par opportunisme, Ken Schwaber vient de lancer un modèle pour Scrum au niveau organisationnel. Nommé « Path to Agility », il n’est pas encore détaillé au grand publique. Bien qu’il ait écrit le livre « The Enterprise and Scrum » en 2007 expliquant comment l’organisation s’adapte à Scrum, Schwaber semble avoir modifié son approche pour inclure une boucle d’amélioration continue.
  • Disciplined Agile Delivery (DAD) : J’ai très peu d’information à propos de « Disciplied Agile Delivery », maintenu par Scott Ambler et Mark Lines. Contrairement à SAFe et Path to Agility, DAD semble est ouvert à toute personne qui désire s'implique dans la conception de DAD. Ils ont écrit un livre en 2012 mais je ne peux pas m'avancer plus à ce sujet.

J'ai aussi omis les approches de développement comme la livraison continue (Continuous Delivery) de Jez Humble et l'intérêt remarqué pour le BDD par des gens comme Matt Wynne. L'unique raison est que mes compétences techniques fondent à vu d'oeil à cause de l'évolution de ma carrière. Je me sens donc hésitant de bien commenter ces approches techniques, mais je les considèrent toujours aussi importantes dans le grand cadre de l'Agilité.

Il est encore trop tôt pour savoir ce qui va arriver avec SAFe, Path to Agility et DAD. Avec l’apparition de nouvelles plateformes telles que les mobiles, les tablettes et l’infonuagique, il sera intéressant de voir si ces techniques viendront modifier les habitudes de réalisation logicielle.

Une chose est certaine à mon avis, l’Agilité semble encore pertinente après une première décennie. Mary Poppendieck semble donc s’être trompée lorsqu’elle annonçait en 2011 que notre industrie se renouvèle à chaque décennie. En regardant de plus près les thèmes mentionnés dans ce billet, on s’aperçoit que ceux-ci sont en place pour continuer à supporter la manifeste Agile.

Mots-Clés :

Références Agile pour les coachs et Scrum Masters

Publié par Philippe Tremblay le mardi 3 décembre 2013 à 12:15

La présence d’un coach ou d’un Scrum Master peut accélérer grandement l’obtention des bénéfices agiles dans une organisation et ses équipes.  Cependant, comme c’est le cas pour tous les rôles, un « titre » (ou un diplôme) n’est pas une formule magique donnant instantanément les connaissances, les habiletés et l’attitude requises pour accomplir de façon performante ce rôle.  Pour pouvoir aider efficacement les organisations et leurs équipes un coach / Scrum Master doit détenir un bagage allant bien au-delà de la connaissance du Guide Scrum et du manifeste agile (qui restent tout de même incontournables).

Nous vous proposons donc une série de références qui permettront de bonifier vos diverses expériences d’accompagnement.  Également, la plupart des références suggérées pour les leaders le sont également pour les coachs.  Surtout lorsque vous agissez à titre de coach organisationnel pour une transition.  Cet article sera mis à jour afin de refléter l’évolution de nos suggestions.

Articles

Livres

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 :

La migration des membres dans les équipes Agile : bon ou mauvais?

Publié par Philippe Tremblay le mardi 24 septembre 2013 à 21:00

L’un des plus grands bénéfices des approches agiles tels Scrum, consiste en la formation d’équipe auto-organisée.  Bien qu’il soit difficile d’évaluer objectivement la différence entre le travail fait individuellement et celui accompli par une équipe, tous ceux ayant vécu au sein d’une équipe saine et « tissée serrée » connaissent le potentiel de développement vers la haute performance.  Avant de poursuivre la discussion, je tiens à préciser qu’une équipe ne consiste pas en un regroupement d’individus travaillant sur un même projet!  Dans la plupart des cas, la formation d’une équipe demande beaucoup d’efforts.  À commencer par un choix judicieux des membres.  Plus précisément, des membres complémentaires et alignés sur des valeurs communes.

Les gains d’une équipe auto-organisée

  • Réduction des délais et transferts
  • Partage de connaissance
  • Désaccord constructif pour trouver de meilleures solutions
  • Communication informelle
  • Appartenance commune aux décisions de design et de code
  • Focus
    • limite le travail en cours – « WIP »
    • changement de contexte
  • Cohésion et complémentarité
  • Intégration de nouveaux membres
  • Responsabilité commune : Architecture, Design, Sécurité et Qualité

Éviter de jouer avec la composition des équipes?

Il y a certainement un coût et un risque à effectuer une recomposition des équipes.  Tout d’abord, bien que le modèle ne soit pas parfait, celui de Tuckman illustre bien les efforts (et le temps) requis pour former de véritables équipes.  Tout mouvement d’adhésion dans les équipes aura assurément un impact sur leurs stades d’évolution.  De plus, ce mouvement risque de réduire la prédictibilité existante de vos équipes.  Car la capacité (vélocité) d’une équipe n’est pas une simple addition de la contribution de chacun des membres.  Malgré ces risques, il y a de bonnes raisons de désirer une recomposition partielle des équipes.  Et de mauvaises aussi…

Mauvaises justifications

  • « J’ai un nouveau projet »
  • Déplacer un membre « problématique » ou rejeté
  • Noyer le poisson: tenter d’annuler le comportement négatif d’un ou plusieurs membres par l’ajout d’un membre « positif »
  • « J’ai besoin de plus de ‘ressources’ sur ce projet » : la planification Agile (hé oui, ça existe) et la composition d’équipes auto-organisées permettent d’adresser ces adaptations.

Et les bonnes…

  • Échanger les expériences.  Brasser les idées.
  • Répartir le potentiel de leadership dans vos équipes
  • Assouplir les barrières du quotidien entre les équipes: Produits différents, proximité, focus, etc.
  • Partage de connaissance dans l’organisation (inter équipes)
  • Stimuler le potentiel de chacun
  • Empathie des contextes: Permets de bien comprendre les contextes particuliers de chaque équipe afin de centraliser des pratiques gagnantes pour tous ou décentraliser certaines autres qui agissent comme un frein à l'auto-organisation et la performance soutenue des équipes

Conclusion

Si vous décidez d’entreprendre une recomposition d’équipe, n’oubliez jamais d’impliquer les membres dans cette idée… avant de prendre la décision!  Et surtout, allez-y avec modération.  Comme toute gestion du changement, vous devrez gérer les risques et accompagner les équipes si vous espérez obtenir les bénéfices potentiels.

Mots-Clés :

Archive