Accéder au contenu principal

Stoos network gathering

Disclaimer : This a summary in French of the articles diffused by Jurgen Appelo in his blog after the Stoos Network Gathering. You can see them here.

Le but du rassemblement Stoos était une réflexion autour du management pour tenter de parvenir à un consensus sur la façon d'accélérer sa transformation.

Jurgen Appelo explique dans son blog que beaucoup d'informations ont été collectées avant l'événement par l'intermédiaire de différents blogs mais peu d'information ont filtré durant l'événement pour deux raisons principales :
  • certains des participants avaient des accords de non-divulgation avec leurs organisations et / ou clients
  • certains des participants n'étaient pas à l'aise sur le fait de diffuser leurs opinions
Au final seul les participants pouvaient diffuser librement leurs opinions personnelles.
A cela, c'est rajouté le Wifi de mauvaise qualité et le fait que les discussions étaient si intéressante qu'ils n'ont simplement pas pris le temps de les tweeter :)

Intervenants et Persona
Qui est le client ? Quel est l'audience visée ? Qui sont les intervenants dans la transformation de l'organisation ?
Au final la liste des intervenants est longue (au total 16) mais les plus importants semblent être le middle management, l'enseignement et les startups. Une idée est d'aussi de catégoriser les intervenants car n'importe quelle méthode pour effectuer un changement dépend du besoin de l'intervenant. Certains demandent confiance et transparence, d'autres plus le retour sur investissement. L’idée est donc de développer des persona et d'y associer des user stories (à l'instar des méthodes de l'expérience utilisateur ou du design thinking).

L'idée principale.
Le rassemblement à Stoos a pour principal objectif de découvrir une fondation commune qui puisse réconcilier les différentes méthodes de management (The Toyota Way, the 14 Points for Management, Radical Management, Management 3.0, Wiki-Management, Beyond Budgeting, Tribal Leadership, Servant Leadership, Elastic Leadership, the Declaration of Interdependence).
Y a-t-il un axiome de management ? Y a-t-il un message de base qui implique plus ou moins tout ce que pensent ces méthodes de management ?
Un axe émergent est que les organisations les mieux managés privilégient des réseaux de création de valeur plus que l'organisation classique de type hiérarchique. Cependant il y a beaucoup d'exemples de bon fonctionnement des hiérarchies au sein des réseaux.
Les mots clés du message sont les individus, l'apprentissage et la diversité. Le cœur du message pourrait donc être des réseaux de création de valeur et d'apprentissage d'individus variés.

D'autres principes important viennent se greffer à ce message :
  • La confiance est nécessaire pour créer de la valeur dans un réseau de personnes
  • L'amélioration continue est directement attachée au réseau d'apprentissage
  • La durabilité signifie la création de valeur pour certaines intervenants
  • L'auto-organisation est évidemment la meilleure approche dans un réseau
  • Les boucles de rétroaction sont requises pour l'apprentissage

Nom et identité.
La question du rassemblement a aussi été de savoir comment la suite du mouvement et des rassemblements s'appelleraient et son identité. Il n'y a pas eu de noms qui sont ressortis et les parties de l'identité qui ont émergées ont été incorporées à au communiqué. Comme quoi la question reste complexe :)

Critique de l'événement.
Jurgen revient aussi sur les critiques autour de l'organisation de l'événement dans son article :
  • demander des données avant l'événement
  • n'avoir qu'une diversité de participants et peut être ne pas inviter assez de participants
  • ne pas avoir livré des résultats stupéfiants
Les retours négatifs sont, d'après lui, compréhensibles mais il faut comprendre que le problème est complexe et ce n'est qu'un premier pas.

But et résultats
Le but du rassemblement était d'atteindre une compréhension du problème, un accord sur le futur souhaité et au moins quelques suggestions pour atteindre ce résultat le plus rapidement.
L'étude du problème a abouti à la mind-map visible ici : http://www.stoosnetwork.org/what-is-the-problem/
Le futur désiré a été défini de cette façon : "Les organisations peuvent devenir des réseaux d'apprentissage d'individus créant de valeur, et le rôle des dirigeants devrait inclure la gérance de la vie plutôt que la gestion de la machine".
Cet objectif est difficilement mesurable mais le manifeste Agile ne l'est pas plus.

La vraie question est comment y arriver rapidement ? Beaucoup de discussions ne concernaient pas le problème ou le but mais comment accélérer le changement.
Voila quelques idées qui en sont ressorties :
  • aucun mouvement de changement ne pourra se faire sans la confiance entre ces membres.
  • il faut catalyser et connecter les initiatives d'autres groupes
  • il faut inclure le plus de personnes possibles (d'où la présence du groupe LinkedIn)
  • il faut créer une véritable identité et un nom

Quelle est la suite ?
jurgen propose les étapes suivantes :
  • mieux déterminer les persona représentant les différents intervenants
  • consolider l'influence des personnes qui essayent déjà de provoquer le changement
  • identifier les stratégies pour associer les agents du changement aux intervenants
  • se réunir régulièrement
  • écrire à propos de ce rassemblement (ce que je fais ainsi que Pablo Perno ;) )
  • nommer ce mouvement
Mon humble avis.
Je n'ai pu suivre réellement l'événement mais je suis extrèmement intéressé par ce qui va en ressortir.Je manque de l'expérience pour réellement participer au débat mais je suis content que les idées du Design Thinking, de l'expérience utilisateur ou encore du lean se retrouvent encore propulsée sur le devant de la scène et cela encore mon attrait et ma conviction que celles-ci représentent un réel axe de travail et de développement !


D'autres articles autour du Stoos network :

Commentaires

Posts les plus consultés de ce blog

Summary of 'Clean Architecture' by Robert C. Martin

Summary of 'Clean Architecture' by Robert C. Martin
Uncle Bob, the well known author of Clean Code, is coming back to us with a new book called Clean Architecture which wants to take a larger view on how to create software.

Even if Clean Code is one of the major book around OOP and code design (mainly by presenting the SOLID principles), I was not totally impressed by the book.

Clean Architecture leaves me with the same feeling, even if it’s pushing the development world to do better, has some good stories and present robust principles to build software.

The book is build around 34 chapters organised in chapters.
Programming paradigm After some introduction, there is an overview of three paradigm of programming:

structured programming which imposes discipline on direct transfer of controlobject oriented programming which imposes discipline on indirect transfer of controlfunctional programming which imposes discipline upon assignment

Uncle Bob tells us that each of these paradi…

Le développeur incompétent est un mythe

Sous ce titre complètement arbitraire et très clairement provocateur, je vais passer un contre pied aux derniers articles que j'ai lus sur le métier de développeur.
Par exemple :
http://patricelamarche.net/2011/05/24/lincomptence-des-dveloppeurs/ 
http://blogs.codes-sources.com/tja/archive/2011/10/04/etre-un-bon-d-veloppeur-c-est-aussi-une-question-d-attitude-personnelle.aspx 
Ça tombe bien c'est juste avant la soirée du Paris JUG sur le métier de développeur ! Et comme on se plaint que les présentateurs ne sont pas de vrais (?) développeurs, je vais en profiter pour donner mon avis.

Alors voila, d'après ces articles, un bon développeur connait ses fondamentaux.
Ok soit mais quelle est cette liste de fondamentaux ? 
Chez certains, c'est les maths et l'algorithmie pure, d'autres c'est C++ par coeur et savoir retourner une chaine de caractère en moins de 3 instructions et une seule allocation mémoire, d'autres c'est Java JEE, ses 100 jsr et frameworks in…

Behaviour Driven Development at Zenika

I have assisted to the Zenika's conference about Behaviour Driven Development given by Mauro Talevi from Agilesque.

The presentation was mainly decomposed in 3 parts : Introduction to BDD, Presentation of JBehave (the API used to do BDD in java) and return on experience about a real project.

Introduction to BDD.

BDD brings together Test Driven Development and Domain Driven Design by
- describing behaviour is a better form of testing
- describing needs from from point of view of it's stakeholder

BDD relies on the use of a specific language to help communication between the business, developers, testers, analysts and managers. It improves presentation.
Behaviours are described by scenarios with a why ? the value, a who ? the actor and the what ? the feature.
BDD introduce a grammar of steps GIVEN a context, WHEN there is an event, THEN produce an outcome AND do other steps.
BDD offers step parametrisation, aliases for changing language or tabularisation for changing parameters for a give…