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.

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 :

L'inventaire, c'est du gaspillage

Publié par Louis-Philippe Carignan le lundi 13 janvier 2014 à 16:18

« In manufacturing, inventory is waste. »

Première phrase à la page 24
« Implementing Lean Software Development »
Mary et Tom Poppendick

Un peu plus bas dans cette page, les auteurs transposent ce concept en développement logiciel.

« The inventory of software development is partially done work. » 

Ok. Facile. En Agile/Lean, l’une des façons de minimiser le gaspillage est de compléter ce que l’on a commencé. Plus loin, aux pages 74 et 75 du même livre, les auteurs énumèrent ce qu’est le travail incomplet :

  • Documentation/requis qui n’est pas codé
  • Code désynchronisé
  • Code non testé
  • Code non documenté
  • Code non déployé

Pour moi, je transpose encore davantage ce concept dans ma liste de tâches professionnelles (ma todo liste). Je tiens donc ma liste de choses à faire très courte. Tout comme on ne veut pas avoir une longue liste de requis auquel on ne réussira jamais à faire au grand complet, je ne garderai jamais une longue liste de choses à faire puisque je sais très bien que je ne réussirai jamais à tout faire et que, d’ailleurs, de nouvelles tâches s’ajouteront à ma liste.

Ceci étant dit, j’étais quand même curieux d’avoir une deuxième opinion sur la question pour voir si ma réflexion était la bonne. Après tout, si je prône les valeurs Agile/Lean, je préfère prêcher par l'exemple.

Personal Kanban

Jim Benson a lancé le site personalkanban.com en 2009 où il explique comment il a transféré les principes industriels du Kanban pour visualiser et contrôler son travail personnel.

Dans son billet « Building your first personal Kanban », Jim explique comment monter son système Kanban :

  • Établir sa carte de valeur (value-stream)
  • Établir son backlog
  • Établir la limite du travail en cours (TEC)
  • Commencer à tirer sur les items du backlog

Puisque ma liste de tâches professionnelles s’exécute sous ce même principe, je lui ai donc écrit sur Twitter pour avoir son opinion à propos de la taille du backlog que l'on monte à l'étape 2.

Voici donc les réponses qu’il m’a données :

Conversation Jim Benson 

J’ai aimé ses réponses.  Lorsqu’il mentionne dans sa réponse du haut qu’un gros backlog est un signe que j’ai plus de « Work In Progress (WIP) » que je ne le croyais, c’est un signe de réviser ma limite WIP. Si ma limite WIP est très élevée, je me retrouve avec beaucoup de travail incomplet. Et puisque du travail incomplet est du gaspillage, je dois m’efforcer d’identifier ce qui ne sera jamais fait et m'en débarasser. 

Plus particulièrement, les questions suivantes dans la conversation Twitter m’ont aidé à identifier la taille du backlog :

  • What is your personal kanban goal?
  • What work is valuable there?

Dans le cas de la première question, l’objectif de mon Kanban professionnel est de réaliser les tâches avec le plus de valeur en premier.

Pour répondre à sa deuxième question, je valorise seulement le travail auquel je crois pouvoir m’attaquer rapidement (disons moins de 2 semaines). Le travail que je ne crois pas réaliser dans ce laps de temps est périssable. Quelque chose de nouveau sera plus important. 

Et votre liste de tâches professionnels?

Et qu'en est-il de votre liste de tâches? Si vous faîtes la promotion des valeurs Agile/Lean dans votre milieu de travail, est-ce que l'organisation de votre travail professionnel est elle aussi Lean?  

 

Mots-Clés :

Quote of the day

Publié par Louis-Philippe Carignan le lundi 16 décembre 2013 à 07:55

A picture taken during my travels in New Zealand. And you, how will your co-workers and customers remember you?

Quote Of The Day

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 :

Agile Coach Competency Framework

Publié par Louis-Philippe Carignan le mercredi 3 juillet 2013 à 17:00

Lors d’une formation que j’ai suivi au Agile Coaching Institute (ACI), on nous a présenté le « Agile Coach Competency Framework » qui rassemble les différentes compétences qu’un coach Agile doit développer en lui. 

Pour bien le visualiser, les formateurs ont dessiné sur le tapis de la salle ce « framework ». Les images suivantes montre ce dessin :

 Frameworkup

 Frameworkdown

Je trouve ce "framework" extrêmement puissant. Premièrement, il définit clairement les champs de compétences d'un coach Agile, quelque chose qui était mal défini dans l'Agilité. Deuxièmement, ils guident les coachs pour qu'ils puissent identifier leurs points d'amélioration dans ce "framework". Et troisièmement, il informe les clients qui désirent engager un coach Agile. Ils seront maintenant mieux informés de ce que peut apporter un coach Agile lors d'une adoption Agile. 

Voyons voir en surface chaque volet de cette étoile :

Agile-Lean Practitioner

Ce volet est habituellement la porte d’entrée pour les gens qui s’intéressent à l’Agilité. Ils ont lu des livres, participés à des formations ou des évènements Agile qui ont contribué à leurs connaissances Agile. Ils ont senti des bénéfices à cette approche et continuent maintenant à creuser le sujet.

Teaching/Mentoring

Tel que défini par le ACI, un mentor est une personne qui fait bénéficier ses clients de son expérience. En mentorant quelqu’un, il leur partage son expérience et ses conseils. Ce volet est donc consacré à l’enseignement et donc, les compétences que le coach doit développer pour bien partager ses connaissances à ses clients.

Technical/Business/Transformation Mastery

Les fondateurs du ACI ont remarqué avec le temps que les coachs Agile sont originaires de trois endroits différents. Certaines personnes ont un passé technique, c’est-à-dire qu’ils étaient des chefs d’équipe, des architectes ou simplement des gens compétent techniquement parlant. Avec le temps, ces gens sont devenus des coachs Agile.

Il y a aussi des coachs qui arrivent du volet Affaires. Dans une ancienne vie, ils étaient des gestionnaires de produit où la valeur d’affaires était importante pour eux. Ils visaient le plus petit produit à livrer (Minimum Viable Product). Ils ont reconnu en l’Agilité une autre façon d’atteindre cet objectif qu’ils tenaient si cher dans leur ancienne vie.

Finalement, il y a des gens qui ont un passé où ils ont agit comme agent de transformation pour une organisation. Ces gens étaient des catalystes pour le changement en développement organisationnel.

Professional coaching/Facilitator

Ce dernier volet est le plus intéressant à mon avis puisqu’il est nouveau dans tout ce qui existe dans l’Agilité. Si on révise les classiques de Schwaber, Sutherland ou Cohn par exemple, on restait très flou sur le rôle de facilitateur et très peu précis sur ce qu’était un coach.

Grâce au ACI, on définit ce qu’est un facilitateur et les compétences qui lui sont requises. La même chose est vraie pour le coaching professionnel. Un facilitateur est une personne neutre qui tient le processus en place et qui aide les gens impliqués dans leurs recherches de solution. Schwaber affirmait souvent qu’un Scrum Master est comme un berger qui guide son troupeau. Les compétences du facilitateur identifiées dans le framework vont beaucoup plus loin et cela permettra aux coachs Agile de cibler leurs points d’amélioration dans leur travail. Puisque Michael Spayd, l'un des fondateurs du ACI, est un Certified Facilitator Practitioner (CFP), on comprend comment il vient enrichir ce volet dans l'Agilité. À mon avis, notre profession ne fait que gagner avec cette expérience extérieure qui s'intéresse à notre univers.

Le coaching, qui est un partenariat créatif entre un client et son coach, est la dernière facette que Lyssa apporte à l'Agilité En incluant des coachs professionnels dans le ACI, elle viendra bonifier ses cours. Une fois que la mécanique Scrum est en place, que reste-t-il à faire dans l'Agilité? Une partie de la réponse est dans le coaching professionnel et le ACI est en train de bien déterminer ce que peut apporter ce volet à notre profession.  

Conclusion

On retrouvera une courte définition de ces compétences ici dans une ancienne tentative de définir le Agile Coach Competency Framework. Lors de la présentation pendant le cours, on sentait vraiment dans la salle que la nouvelle figure était beaucoup plus représentative de ce qu’un coach est. Tous les participants étaient d’accord que le volet Agile-Lean Practitioner fut leur porte d’entrée dans l’Agilité. Ensuite, chaque personne savait si elle avait un passé technique, Affaires ou transformationnel.

Après plus de 10 ans en Agilité, il est intéressant de voir qu'il n'y aura peut-être pas une prochaine mode mais plutôt un approfondissement de l'Agilité pour qu'un jour, elle soit bien en place dans toutes les équipes de notre profession.

Mots-Clés :

Archive