Je veux bien changer, mais je veux être sûr de savoir où je vais mettre les pieds. J’opte donc pour des frameworks documentés pour ne pas dire prescriptifs qui me permettent de me projeter. SAFe est par exemple un framework d’agilité à l’echelle utile pour gérer de la complexité.
Le chemin
L’avantage de type de changement, c’est qu’il est assez cadré et répétitif. Si je pars par exemple sur du Scrum, je sais que je vais devoir parler rôles et responsabilités, longueur de sprints, créer un product backlog… Je peux éventuellement mesurer la maturité des pratiques pour mesurer l’avancement.
les pièges
Changer avec un framework prescriptif est particulièrement utile quand le point de départ n’est pas très fluide. Les rôles et responsabilités clairs permettent de remettre tout le monde dans le mouvement. C’est comme remettre sur la route une voiture embourbée. L’envers du décor, c’est que bien que customisable on part sur framework que l’on plaque sur l’existant. C’est un peu comme SAP dans le monde du logiciel, c’est plus à l’organisation qui le prend de s’adapter que l’inverse.
Transcender
Pour résumer, les frameworks prescriptifs sont bien pour poser un cadre là ou cela manque. Ils sont moins adaptés quand cela est déjà fluide car ils peuvent casser une dynamique existante. Ils peuvent aussi poser un problème sur l’état final qui peut être verrouillé par le framework. Il est intéressant de se donner la capacité à s’extraire d’un framework par défaut pas contextualisé sous peine de plus tard devoir tout casser pour mettre en place le dernier framework en date. C’est par contre un changement assez facile, il n’y qu’à suivre la prescription.
Autres tactiques :
