J'avais en "terminale C" un prof d'histoire extraordinaire.
J'ai oublié son nom. Il était royaliste. C'était dans les années 70. Il nous parlait - déjà ! -du groupe Bilderberg. Davos à côté c'est la main droite du prestidigitateur qui vous amuse pendant que la main gauche fait le tour.
Autant que je me souvienne, le XXème siècle était au programme.

Vers la 2ème guerre mondiale

Ce prof nous avait expliqué la situation qui devait conduire à la 2ème guerre mondiale en quelques secondes. Il maniait l'art du signe.

• Côté allemand, le bruit des usines d'armement.
  
• En France, "Tout va très bien Madame la Marquise, tout va très bien...".
  

Tout va très bien... jusqu'à la 2ème guerre mondiale.

Le problème du déni

Le déni...

Aux origines

L'un des dénis porte sur l'intention originelle. L'agilité... avant l'agilité.
Au départ (avant 2001), c'est une user story, une développeur story.

En tant que Développeur
Je peux créer et maintenir des logiciels
afin d'offrir ainsi un produit qui a un intérêt pour l'Utilisateur
... et au passage prendre mon pied à le faire ! Agile, tout va très bien...

Un autre déni : la situation réelle des personnes dans les équipes, agiles ou pas. Une question simple : avons-nous le temps de bien faire ce que nous avons à faire ? Vous voyez c'est très simple comme question.

Agile, un golem ?

(Illustration : Philippe Semeria)
Parfois, je me demande si nous n'avons pas créé un monstre.
Entre cette intention originelle, trois + un rôles agiles, et la réalité actuelle, n'y a-t-il pas un hiatus ?
La tentation est grande d'abandonner le mot "agile". Le sens (ou la direction, la voie si vous préférez) étant désormais cette lucre-agilité ou agile canada dry que certains dénoncent.
...
Et bien... Non !
Si l'agilité est aujourd'hui une vielle idée (11 ans déjà !) elle reste une belle idée qui mériterait évidemment un peu de cosmétique : flux tiré (sous jacent à XPv2 en 2004), devops...

Auto-organisation

La voie commence là où nous sommes. Elle fonctionne à tous les niveaux. La méthode est l'action. Le temps, maintenant. Dan Millman

Les bonnes nouvelles Auto organisation à l'échelle

• Groupes locaux "agiles"
• Craftsman et autres groupes de Développeurs

L'agilité s'installe et les organisations se prennent l'agilité dans le PIF (Paysage Informatique Français).

De nombreux groupes s'organisent à l'échelle locale.

• Villes
• Régions...
• ... Nation ?

Non seulement les groupes locaux sont actifs, mais des collaborations voient le jour entre plusieurs villes.

Développeurs

De plus en plus, via les confs agiles, les "code retreats" et autres dojos, je rencontre des Développeurs qui parlent et vivent le développement comme un véritable métier, simplement. Une certaine fierté teintée d'humilité est en train de naitre. Nous voila 12 ans après aux sources de l'agilité.

Comment participer, être réaliste : quelle capacité réelle de changement dans les organisations, quelle prise de conscience des parties prenantes (Développeurs, Utilisateurs pour l'essentiel) et de leur pouvoir ?
Et être utopique : envisager ce qui n'a pas encore été fait.

Vous l'avez peut-être remarqué, les méthodes et leur intention originelle, leur spécificité s'efface peu à peu dans l'ombre portée de la pensée unique agileCscrum et scrumCagile, agileEtscrumCpareil.
Scrum, coquille vide, phagocyte tout ce qui passe : scrum developpeur, scrumban...

Il faut bien dire qu'au quotidien, nous bénéficions d'une boite à outil, un framework agile constitué des dizaines de principes et pratiques issues de différentes sources.

Il reste que les méthodes ont chacune leur spécificité et la "pensée unique" gomme cette diversité, ce qui est un gaspillage.

Une différence d'intention

L'intention est capitale : c'est elle qui, explicite ou non, donne forme aux pratiques.

• L'intention de Scrum est la réalisation de systèmes complexes (voir intro du scrum guide)
• L'intention de l'Extreme Programming est le changement social (voir XPE2E)
• L'intention de Lean/Kanban est l'amélioration d'un process existant et - voir premier principe de Deming - donner du travail.

Vous voyez que les intentions sont sensiblement différentes.

Une différence d'approche

Certaines approches supposent une marche significative : Scrum ou XP, itératives, imposent de nouveaux rôles, un itératif court. Parfois c'est une marche bien (trop) haute.

Attention au scrum-gachis

D'où parfois un gâchis : quand le scrummaster est appelé "chef", quand les tests et la qualité sont sacrifiés sur l'autel du lucre, nous sommes loin d'une approche véritablement agile (voir les 12 principes agiles).

Améliorer l'existant

Lean&Kanban partent de l'existant pour l'améliorer. Parions que, à terme, nous retrouvons quelque chose proche Scrum ou XP. Mais le rythme et la stratégie de changement sont radicalement différents.

Process unifié agile

Voila un produit hybride qui, comme scrum, peut aussi être agile. Il constitue un "moyen" terme entre

• améliorer l'existant
• mettre en place une approche itérative structurée

qui peut être une solution pertinente selon le contexte.

Selon le contexte...

Voila bien la clé, le contexte. La capacité à changer, plus ou moins rapidement.

Que préférez-vous : réussir un changement progressif (Lean Kanban, AUP) ou rater un changement plus radical ?

Ne gommez pas les méthodes, la diversité des approches est une richesse. Et tout comme des pratiques agiles peuvent compenser des inconvénients d'une approche CMMI ou ITIL, de même le framework constitué des différentes pratiques peut être une aide dans la mise en oeuvre d'une approche, essentiellement choisie en fonction de son intention et de ses impacts en termes de changements qui seront plus ou moins acceptés, possibles, rejetés.

Voici le calendrier des formations "inter" premier semestre 2012.
Formations Premier semestre 2012

Lors de l'Agile Tour 2011 nous (@claudeaubry) avions présenté le "Club des Utilisateurs".
Tout de suite les premiers retours faisaient apparaitre une confusion :

• Utilisateur au sens "je fais de l'agile, quel que soit mon rôle"
• Utilisateur au sens "représenté par un Product Owner, Client, Product Manager..."

C'est cette seconde acceptation qui était notre intention originelle.

Pourquoi Product Owners

Le terme aujourd'hui standard de fait étant "Product Owner", utilisons-le pour nommer ce club.

• Product Owner
• Testeur fonctionnel
• Utilisateur
• Acheteur de logiciel "agile"
• ...

Pourquoi un club ?

Voici ce qu'en disait Claude sur le site sigmat.fr

Ce club - commission de l'association indépendante SigmaT - a pour but de réunir toute personne engagée en agilité côté Utilisateur et ou Manager. Pourquoi ? Pour échanger des expériences, travailler ensemble à des sujets concrets tels que "contrat agile", "SSII et agilité" ou "rôle du Client".

Importance de la solidarité

Les méthodes agiles ont créé de nouveaux métiers

• Agile Utilisateur
• Agile Développeur
• Agile Manager.

Je crois fermement que la solidarité entre acteurs du même rôle peut aider à mieux forger une identité et ainsi pouvoir participer pleinement à une équipe agile. Cela demande une certaine assertivité.