Concevoir : Un jeu pour découvrir SCRUM...

Une très bonne initiative à mon sens, la formalisation de règles d'un jeu basé sur les célèbres légo qui permet la vulgarisation et l'apprentissage de la méthode SCRUM.
A savoir que les règles sont en cours de traduction et qu'il peut être adapté à d'autres méthodes agile.

http://agileee.org/wp-content/uploads/2011/12/Scrum-Simulation-with-LEGO-Bricks-v2.0.pdf

Communiquer : faut-il parler de PAQ Agile ?

"Si ! si ! je t'assure ! Ils ont osés le PAQ Agile chez OCTO Technology ;)"

La question que je pose est "faut-il estampillé d'Agile le PAQ ?" et plus largement faut-il utiliser l'étiquette Agile pour tout et rien ?

Pour moi la méthodologie n'a pas d'influence sur le PAQ, au pire la partie consacrée aux "Documents applicables et de références" sera "light" ;)

Par contre, je suis tout à fait d'accord qu'il faut mettre en avant dans le contenu du PAQ les points positifs en termes de suivi, validation et assurance qualité portés par la philosophie Agile !

Dans tous les cas allez vite lire ce billet d'Anne-Florence Canton bien rédigé et plein de bon sens.

Manager : Non ! L'Agile n'est pas mort !

Un autre billet bien sympa (et encore un peu polémique) que j'ai pu lire avec attention sur le blog de  

Le fond est là en tout cas ! 
On en discutait encore lors de l'Agile Tour à Nantes, il ne suffit pas de dire "faire de l'Agile" et surtout l'important n'est pas tant la méthode que la philosophie !

Maintenant dire que cette méthode est "morte" car reprise à des fins commerciales je pense que c'est exagéré !
Idem pour le "forfait Agile", je ne pense pas que cela soit utopique. Ce qui est vrai c'est que cela ne peut pas être contractualisé sous cette forme et que la présence d'un cahier des charges n'est pas "Agile thinking" ;)

Si les fondamentaux sont respectés (apport de valeur, soucis de satisfaction client et mise en avant de l'humain, ...), je pense que cette méthode peut apporter beaucoup même sur des forfaits et surtout pour des SSII ;)

Il est sûr qu'il ne faut pas tomber dans le "Scrum Lite", c'est tentant de supprimer tout ce qui rend Scrum parfois "lourd" mais, sans rigueur dans la méthode, le résultat risque d'être désastreux !

Enfin pour être confronté régulièrement à la situation, le terme "Agilité" n'est pas encore suffisamment connu pour qu'il fasse vendre. J'ai plutôt constaté l'effet inverse et ai du adapter mon discours commerciale pour remporter l'adhésion des clients.
Pourtant, au final, la satisfaction est toujours au rendez-vous... pour le client, pour HARDIS et aussi pour le collaborateur !!! 

Et vous... vous vous y mettez quand à l'agilité ?

Concevoir : Les besoins changent tout le temps...

Qui n'a pas déjà entendu cela de la part de ses développeurs ?
Personne car la fluctuation des besoins d'un client fait partie intégrante d'un projet de développement.

Une fois ce constat fait, il y a plusieurs façons de réagir :

• Fataliste : on ne peut rien y faire donc on va se protéger. On réalise la conception et on fait signer le client sur cette base. Ensuite on prévoit les mécanismes pour limiter au maximum les changements : avenants, surfacturation, ...
• Arrangeante : on accepte les moindres demandes du client. C'est vrai cela va lui faire plaisir... dans un premier temps ! Le résultat cependant certainement moins car soit vous livrerez en retard (ce qui implique aussi que vous aurez dépassé les charges : qui paie ?), soit vous livrerez une solution qui ne sera pas d'une qualité irréprochable (vos développeurs auront modifiés à la marge, surchargés à la hâte, non documentés, ...)
• Agile : On se met d'accord sur les attentes fonctionnelles et on ajuste au fur et à mesure les besoins.

Vous allez me dire : "C'est bien sûr l'approche Agile qui paraît la plus pertinente !". Et vous avez, à mon sens, tout à fait raison !

Car les besoins ne peuvent être réellement figés...
Les causes de cette incapacité à définir clairement la cible sont multiples :

• méconnaissances du client des possibilités qui lui sont offertes
• difficulté du fournisseur à estimer le coût de la réalisation
• la valeur ajoutée d'une fonctionnalité n'est réellement quantifiée qu'une fois celle-ci utilisée

Mais alors pourquoi les méthodes Agiles ne sont pas (ou peu) mises en oeuvre ?
Pour de nombreuses raisons :

• elles nécessitent une implication "quasi" quotidienne du client, dans l'idéal le client doit être représenté au sein de l'équipe
• elles impliquent une visibilité limitée sur le coût de la solution : même s'il s'avère que, dans 99% des cas, le coût final est moindre pour le client
• elles provoquent une sensation de non maîtrise du résultat final pour le client : alors que l'on va s'adapter tout au long du projet à ces attentes...

La solution que je préconise actuellement, au sein de Logi-Tech Informatique, et mets en oeuvre chez mes clients, est de prendre appui sur les principes fondateurs de l'agilité (voir le Manifeste Agile) et de ménager dans un premier temps les impacts du changement dans leur structure.
Sans parler d'Agilité, je leur présente les avantages inhérents à ces pratiques, notamment l'adéquation optimale aux besoins, et leur propose de réfléchir ensemble aux "efforts" qui leurs semblent envisageables en interne pour aller dans cette voie.

De cette manière, je définis d'un commun accord les principales métriques (fréquences des réunions fonctionnelles, fréquences de livraison, ...) de mon projet Agile et remporte l'adhésion du client à cette démarche.

Amenez calmement vos clients vers l'Agilité, prouvez leurs ses bienfaits et le cycle en V sera vite oublié !

Manager : SCRUM au quotidien... en vidéo !

Voici une vidéo simple et bien pensée présentant l'application de SCRUM pour la réalisation d'un portail. Le projet a duré 6 mois et débouché sur 2 Portails.

Scrum in the real world, an AGILE movie from Soul' on Vimeo.

Elle présente rapidement l'essentiel :

• les outils
• les étapes
• les visuels

Bref, à regarder et à re-regarder ;)

Manager : Peut-on être Agile chez Logi-Tech Informatique ?

Je dirais : "On peut être Agile mais pas avec n'importe qui !"


Bien que l'Agilité ait plus de 10 ans, elle n'est pas connue de beaucoup d'acteurs surtout en France. Mettre en place une organisation permettant de répondre, par exemple, aux exigences de l'Extreme Programming n'est pas une chose aisée... L'implication nécessaire pour le client n'est pas dans les habitudes de nos comptes...

...et imposer des cycles de quelques semaines provoquerait un chamboulement proche du tsunami dans l'organisation et la façon de travailler de nos clients !


Alors on laisse tomber ? Non, on tempère... La meilleure organisation est celle partagée par tous (client et fournisseur !).
Ce dont je suis persuadé c'est que les principes portés par le manifeste Agile* sont de bons sens et doivent être connus de tous :

•  « Notre plus haute priorité est de satisfaire le client en livrant rapidement et régulièrement des fonctionnalités à grande valeur ajoutée. »
•  « Accueillez positivement les changements de besoins, même tard dans le projet. Les processus Agiles exploitent le changement pour donner un avantage compétitif au client. »
•  « Livrez fréquemment un logiciel opérationnel avec des cycles de quelques semaines à quelques mois et une préférence pour les plus courts. »
• « Les utilisateurs ou leurs représentants et les développeurs doivent travailler ensemble quotidiennement tout au long du projet. »
• « Réalisez les projets avec des personnes motivées. Fournissez-leur l’environnement et le soutien dont ils ont besoin et faites-leur confiance pour atteindre les objectifs fixés. »
• « La méthode la plus simple et la plus efficace pour transmettre de l’information à l'équipe de développement et à l’intérieur de celle-ci est le dialogue en face à face. »
•  « Un logiciel opérationnel est la principale mesure d’avancement. »
• « Les processus Agiles encouragent un rythme de développement soutenable. Ensemble, les commanditaires, les développeurs et les utilisateurs devraient être capables de maintenir indéfiniment un rythme constant. »
•  « Une attention continue à l'excellence technique et à une bonne conception renforce l’Agilité. »
•  « La simplicité – c’est-à-dire l’art de minimiser la quantité de travail inutile – est essentielle. »
•  « Les meilleures architectures, spécifications et conceptions émergent d'équipes autoorganisées. »
•  « À intervalles réguliers, l'équipe réfléchit aux moyens de devenir plus efficace, puis règle et modifie son comportement en conséquence. »

*Le Manifeste Agile est un texte rédigé par 17 experts reconnus pour leurs apports respectifs au développement d'applications informatiques sous la forme de plusieurs méthodes dont les plus connues sont Extreme Programming et Scrum.

Agile Tour 2010 à Nantes

Jeudi dernier (21/10/2010), je me suis rendu avec plusieurs collaborateurs à l'Agile Tour organisé à l'école des Mines par l'Association Agile Nantes.
Ayant juste quelques idées préconçues sur le sujet j'y suis allé en grand curieux...
Est-ce que cette méthode est réellement révolutionnaire ?
Est-ce qu'elle peut apporter à notre organisation ?
Peut-on vraiment mettre en oeuvre ces principes en SSII ?

J'ai eu de nombreuses réponses et surtout une introduction à l'Agilité extrêmement claire et captivante par Mr Regis Medina lui même.

Merci à l'Association AgileNantes, vivement l'année prochaine !