Mutatis mutandis, une réflexion sur le WebCamp de Québec

Le 19 mai prochain, environ 400 professionnels de tous acabits de l’industrie du Web se réuniront dans une conférence participative de type BarCamp, ce sera donc une belle occasion pour tous de discuter.

 

L’objectif de ce genre de conférence est souvent partagé sur un domaine donné. Dans le cas qui nous intéresse, ils échangeront sur le Web. Mais si, aujourd’hui nous amorcions ensemble une réflexion le WebCamp, n’on pas pour le changer, mais juste pour poser un nouveau regard.

 

Un regarde de ce qui devrait être changé. C’est là l’essence de cette expression latine.

« En change ce qui doit être changé, et d’apprendre la différence de ce qu’il ne l’est pas ». Le changement c’est bien, pourtant il ne faut le faire sans réflexion à prime à bord.

 

Le Web arrivera bientôt à son âge adulte. Longtemps, il a été un monde réservé aux Geeks tant pour son utilisation que son exploitation. Progressivement, il s’est démocratisé à tous les niveaux. Il passa du programmeur jusqu’à l’artiste pour se rendre jusqu’à l’utilisateur.

 

La science de jadis devient un art ! Les techniques inaccessibles qu’aux professionnels devient facilement utilisable par nos utilisateurs.  Donc, aujourd’hui, demain, et pourquoi pas le 19 mai prochain. Nous devons apporter une réflexion sur ce qu’il serait intéressant pour l’aider à devenir grand.

 

De venir en grand, en mettant en place des outils, des stratégies de développement et différentes actions pour enfin  qu’on puisse dirent :  « Adulte, tu es maintenant ! » au sujet du Web. Et je crois que c’est une belle occasion, ce WebCamp  de Québec.

 

Avec les années plusieurs outils ont été mise à la disposition de toute personne qui s’intéressait aux technologies Internet. Du simple « vi » (éditeur en mode ligne d’Unix) pour écrire le HTML jusqu’au CMS le plus sophistiqué par exemple WordPress ou Drupal.

 

Des langages de programmation pour les types de programmeurs, avec Framework pour faire à peu près tout ce qu’on voudrait faire dans ce merveilleux monde du Web. En passant de l’open source jusqu’aux distributions commerciales.

 

Je ne crois pas qu’il y a un meilleur langage qu’une autre, il n’y a qu’un meilleur pour combler le besoin dans l’environnement technologique et organisationnel qu’il doit être livré.

 

Avec l’ensemble des outils qui sont mis à notre disposition, nous devons passer du travail de l’artisan à un travail plus professionnel. Cependant, il plus que le temps de mettre en place des stratégies, surtout des stratégies de développements.

 

Des stratégies qui ramèneront les principaux intéressés à leur place respective. Bien sûr, l’utilisateur final, c’est lui qui utilisera ce que nous allons construire. Sans oublie, les différents membres de l’équipe ou des équipes qui construiront le site Web ou l’application et bien sur le client qui payera le projet.

 

Bien sûr les méthodologies Agiles font partie de ces stratégies sans pour autant en être la seule. Le choix d’une stratégie doit être basé le partage. Le partage entre les individus, le partage d’information de données, le partage entre les organisations. L’échange et la communication doivent être au cœur même de cette stratégie.

 

Il faut aussi profiter des acquis qui se sont faits aux files des années. Aujourd’hui, nous ne devons pas toujours réinventer la roue. Plusieurs des choses, des bonnes et des mauvaises. Mais, il faut prendre le temps de valider leur utilisation. En prenant conscience que nous ne sommes plus seules. Que peut-être quelqu’un à déjà résolu le même problème que nous avons. Ou encore, que notre solution pourrait aussi servir à quelqu’un d’autre.

 

De l’open source aux formats ouverts, en passant architectures orientées services (incluant les environnements « clouds computing ») jusqu’aux différents réseaux sociaux. 

 

Plus d’un changement cogne à nos portes, nous ne pouvons pas (ou plus) faire la sourde oreille. Les gouvernements, les grandes entreprises comme la petite doivent prendre le temps d’évaluer toutes les solutions. Même les solutions qu’il n’y pas si longtemps, ne semblaient pas acceptable.

 

N’oublions pas, le Web n’est plus seulement dans nos ordinateurs bien assis à nos bureaux (au travail ou à la maison). Aujourd’hui, avec un ordinateur portable et un accès WIFI on peut avoir accès presque partout. Et ce n’est plus seulement l’ordinateur qui nous donne accès ce merveilleux monde !

 

Du petit téléphone intelligent, en passant les tablettes PC  ou le fameux IPAD. Et même, la télévision qui servira bientôt comme terminal  pour naviguer sur Internet. En plus, programme télévisé qui sont webdiffusé.

La TÉLÉVISION qui s’annonce de se présenter dans le WEB et bien sûr le présenter aussi ! Nous n’avons qu’à penser ToutTv.com démontré ce point.

 

Mais, il ne faut pas oublier notre ami Google que presque chaque jour, repousse les limites. Une vraie « vague » d’évolution que nous ne sommes pas les seules à utiliser.  Il n’est pas loin, le jour où un client va nous demander une application comme Google Earth. Car, lui aussi l’utilise maintenant.

 

Je ne sais pas ce comment demain sera fait. Mais, une chose est sûre ! Ce sera au moins Web. Donc, c’est important de tenir des activités comme le WebCamp et d’y apporter une réflexion sur le changement en cours.

Au plaisir de discuter avec vous au WebCamp.  

L’intégralité de l’équipe de développements.

L’un des principes à la base de SCRUM, est l’intégralité de l’équipe de développements pour la durée du cycle (l’itération).

Mais, pour plusieurs organisations qui sont habituées d’avoir une mobilité des ressources en cas d’urgence. Cette impossibilité de bouger des individus durant la période du cycle pourrait être problématique. Beaucoup d’organisation ajuste leurs équipes selon les besoins du moment, surtout selon les urgences de l’organisation.

Donc, demander à de telle organisation de respecter l’intégralité de l’équipe durant le cycle de développement. Ce n’est pas une chose facile.

Je travaille comme consultant en informatique depuis plusieurs années, dans différentes organisations du Québec (province de Québec). Et il m’est arrivé de voir ou d’entendre parler des équipes qui évoluaient selon le besoin et les urgences de l’organisation.
« L’expression on sait comme l’équipe est construite, au moment la regarde. La seconde d’après, elle peut changer. »

Ce n’est pas mal en soi, mais toutes décisions organisationnelles à des conséquences positives et négatives. Comme on dit, je ne veux pas faire un procès à ces organisations. Mais, si elles veulent faire le passage à Agile. Ils devront effectuer une bonne réflexion sur les impacts que cela aura sur leur gestion des ressources et des impacts organisationnels.

N’oublions pas que l’engagement est individuel, mais aussi en d’équipe. Donc, si nous brisons cette équipe, l’engagement ne risque de plus tenir. En agile, les individus qui composent l’équipe ne sont pas juste un numéro remplaçable. Mais, une personne importante au sein du projet et que les autres membres compte sur ces efforts pour mener à bien le projet, ou le cycle. Une équipe SCRUM qui s’engage sur la livraison d’une série de taches. Elle fait sur la base de la confiance que chacun à envers les autres.

Donc, lorsqu’on me parle, qu’on me demande de briser cette intégralité. Je demande toujours. Si tu t’engages à livrer quelque chose avec une personne, et le lendemain, je la changerais. Est-ce que cela affecterait ta capacité à livrer, mais surtout la confiance de le faire ?

Je n’ai jamais eu personne qui n’avait pas d’impact sur son travail ou sa vision du projet. Par conséquent, j’accompagne toujours mes clients afin qu’ils comprennent et acceptent les inconvénients et les avantages, avant de lancer dans un premier projet Agile.

Et de notre coté, nous devons prendre aussi conscience que pour certaine organisation, souvent pour les petites, c’est difficile voir impossible de respecter cette intégrité de l’équipe.

En conclusion, il n’a pas de solutions parfaites pour gérer cette intégralité. Il faut juste trouver votre solution à vous. Tout en cherchant, à viser l’intégralité complète de l’équipe de développement.

Mes petites résolutions Agiles pour l’an 2010.

Quelle belle tradition que sont les résolutions du Nouvel An. J’ai eu donc l’idée de vous partager aujourd’hui quelque une de mes résolutions pour ce Nouvel An. Mais, surtout un pour une année que j’espère où les méthodologies agiles prendront encore plus la place qui lui revient.

La première, nous (Moi, mon organisation, vous, tout le monde) à parler avec le plus de justesse possible des méthodologies Agiles. Quand nous voulons être une référence, il faut toujours vérifier ses affirmations et les baser sur la vérité, une vérité vérifiable.

La deuxième, dépassé plus que la simple formation. Travailler avec les gens pour les accompagner à s’accaparer les méthodologies. Je crois que pour les méthodologies Agiles, prend la place qu’elles méritent. Les gens doivent s’accaparer un peu comme leur langue maternelle.

La troisième, accompagner les gens ainsi que leur organisation, dans leurs choix et leurs transitions vers les méthodologies Agiles. Si vous le ne savez pas encore, choisir d’effectuer ce virage n’est pas une chose facile. Donc, les gens ont besoin de notre aide, mais surtout de notre accompagnement.

La quatrième, continué, continué à expliquer, mais surtout à ÉCOUTER les gens qui s’intéresse aux méthodologies agiles. Comme dit le bon vieux proverbe, on a deux (2) oreilles et une bouche. Donc, on doit écouter deux (2) fois plus !

Et une petite dernière, essayez juste un instant de penser différemment, de pensée Agile.

En terminant, permettez-moi de nous souhaiter à tous une bonne et heureuse année, mais surtout très Agile.

Comment choisir son Coach Agile ?

Je sais avec titre comme celui-là, beaucoup d’entre vous, vous attendez que je vais vous fournir une recette de cuisine ou encore une fiche à remplir pour aider à bien choisir votre Coach Agile. C’est bien mal me connaître. Je ne crois tout simplement pas aux procédures définies. Encore plus dans les différents processus de sélections des ressources humaines.

Je vais plutôt vous aider à apporter une réflexion sur besoin spécifique d’un Coach Agile.

À la base, les coachs agiles proviennent de différents profils. Souvent, ils proviennent de 2 grands profilés. La gestion de projets bien, mais aussi des architectes intégrateurs.

Il faut prendre le temps d’évaluer vos besoins. Par exemple, si vous avez un problème de gestion de projets. Cherchez-en un, qui a été chargé de projet.

Il faut aussi qu’il ait joué les différents rôles dans une équipe Agile. Il doit comprendre ce que chacun des rôles on fait. S’il n’a jamais été programmeur, comment, il pourra expliquer au programmeur l’impacte sur leur travail.

Tout comme un chargé de projets devra avoir géré des projets dans un contexte agile ainsi hors des méthodologies agiles. Comme dit si bien, l’expression anglaise « a Jack work trail ». Plus, il aura occupé différents postes aux files de sa carrière, plus il sera en mesure d’expliquer les impacts dans le passage aux méthodologies agiles.

La formation apporte beaucoup, mais elle ne remplacera jamais, l’expérience terrain. Tout comme, une certification Scrum Master ou autre certification du genre, à laquelle ne s’ajoute aucune expérience pratique, ne sont pas plus performant que si vous commander un livre chez Amazone.

Un vieux proverbe disait : « Il y a des choses qui s’apprennent. Mais, qui ne se montre pas ! » C’est le cas, du coaching agile. Les meilleures formations, certifications, ne remplaceront jamais l’expérience.

N’oubliez pas, que les méthodologies agiles, sont basées des approches de gestions et de bonnes pratiques. Donc, pas de règles rigides qu’on applique sans réfléchir. Par exemple, le Guide vert, donnent beaucoup d’exemples comment faire les choses, on peut s’y référer pour résoudre nos problèmes. Cette approche n’est pas prônée en Agile.

Il est vrai aussi de dire que les méthodologies agiles possèdent beaucoup de documentations (livres, site web, blogue (comme le mien)). Mais, le rôle principal du Coach Agile, n’est pas d’appliquer les règles écrites. C’est d’apporter la lumière des interlignes, des problèmes que vous vivrez durant le projet.

Je ne crois pas non plus au « GOUROU AGILE » qui arrive avec livre de recettes agiles. Comment on peut appliquer une recette magique, avec une équipe, une organisation, une technologie, etc. Applique une recette comme celles-là, va en l’en compte même des principes d’agiles. Chaque individus, organisation, projets sont différents les uns des autres. Donc, comment pourraient ton avoir un tel livre de recettes.

S.V.P., n’applique une fiche des sélections pour recruter votre Coach Agile. C’est un non-sens à mes yeux. Rappelez-vous du principe numéro 1 du manifeste Agile : « L’interaction avec les personnes que les processus et les outils ».

Rencontrez les ressources, discutées avec eux de leur vision et de leur philosophie. N’oubliez pas, cette personne aura un impact important dans votre organisation. Laisseriez-vous, votre concierge prendre la direction de votre compagnie sans vérifier ces compétences ? Le meilleur sera toujours celui avec qui vous pourrez vous assoir pour discuter du ou des problèmes. L'humain a la place #1 en agile. Donc, il faut que la communication passe entre vous et votre Coach Agile.

En terminant, trouver un Coach Agile qui vous conviendra, ce n’est pas un processus facile. Il n’y pas de mauvais Coach Agile. Il y a un qui vous convient mieux que d’autres. Aussi, pourquoi pas, au lieu d’une seule personne, de faire intervenir une équipe avec diversifié et spécialité pour vous accompagner dans ce virage important pour votre organisation. Chacun des membres de cette équipe pourrait vous apporter une lumière sur différents axes.

Comme toujours, soyez Agile dans votre réflexion et votre démarche.

Agile, de Haut jusqu’en bas, et Droite à Gauche.

Beaucoup d’organisation qui se lance dans les méthodologies Agiles, oublie un facteur important dans leur adaptation de ces nouvelles approches.

Beaucoup d’organisations qui démarrent un petit projet pilotent en Agile dans une équipe de développement. Oublie souvent, trop souvent, l’impact que cela peut avoir sur leur organisation.

Tout passage Agile, même au sein d’une petite équipe de développement aura un impact sur l’organisation tout entier.

Traditionnellement, les équipes de développement étaient dynamiques. C'est-à-dire qu’à tout moment, et souvent selon besoin momentané de l’organisation, être totalement réorganisés ou restructurés. Aux files du besoin ou des changements de l’organisation, les membres de l’équipe peuvent changer ou être remplacés durant la vie du projet. Mais, l’une des règles importantes en Agile, c’est justement l’intégrité de l’équipe. Normalement, il est très souhaitable que l’équipe reste intègre du début jusqu’à la du projet.

Donc, cela a un impacte direct sur la gestion des ressources disponibles. Chaque membre s’engage en tant qu’individu et aussi à titre de membres de l’équipe à livrer une série de composantes. Donc, s’il manque une ou plusieurs personnes dans l'équipe, l’engagement ne peut plus tenir !

Le second impact, est la disponibilité de la personne qui joue le rôle de product owner (méthodologie Scrum). Cette personne est aussi importante que tous autres membres de l’équipe. Il n’est jamais facile de libérer cette personne à cause de son expertise et sa connaissance du domaine d’affaires de l’entreprise.

Mais pour acquérir cette expertise, ça veut dire aussi qu’il occupe une place importante au sein de l’organisation. Donc, il occupe une fonction qui peut-être difficile à redistribuer ou à replacer.

Le dernier problème qu’il est difficile de réaliser avant sa mise en place. C’est la livraison fréquence et surtout beaucoup plus rapide de morceaux d’applications fonctionnelles. C’est bien beau sur le papier, mais en pratique, il apprendre à le gérer ces livraisons fréquentes. Avoir une application à tester tous les 6 à 12 mois, les organisations sont habituées. Mais, en avoir a testé, tous les 2, 4 ou 6 semaines, ce n’est pas la même chose.

Comme vous le voyez, se lancer dans un processus de mise en place des méthodes Agiles, impacte bien de haut et bas, et de droite à gauche l’organisation.

Bien entendu, l’impact pourra varier d’une organisation à une autre, mais l’expérience m’a démontré qu’elle dépassera l’équipe qui l’implémentera dans son projet de développement. Mais, une chose est sûre, il y aura un impact plus grand que seulement que dans l’équipe de développement.

Je sais vous aller dire que je prêche pour ma paroisse. Mais, je vous recommande de vous joindre une personne d’expériences, une personne qui a tant de l’expertise technique en méthodologie Agile. Mais, qui a aussi de l’expérience en contexte organisationnel. Autrement dit-on bon mélange entre l’expertise organisationnelle (monde des affaires) et l’expertise en implémentation des approches Agiles.

En terminant, rappelez-vous que vous faisiez des affaires avant l’implémentation des méthodologies Agiles et que vous devriez en faire encore après !