La division du temps en phases de la gestion de projet est source de problèmes, essayons une nouvelle philosophie du travail avec l'agilité.
Nous allons voir par quoi peuvent être substitués les trois principes venant de la division du temps selon le taylorisme : une méthode séquentielle, la planification de projet et le micro-management.
La division du travail du modèle tayloriste entraîne de nombreux problèmes qui peuvent être éliminés avec l'auto-organisation.
Dans la déconstruction de la gestion de projet, le premier volet concerne la division du travail.
Les 3 principes retenus de la division du travail selon Adam Smith et ses successeurs sont : un processus standardisé, de la hiérarchie et du contrôle.
Ajoutée à la division du travail et à celle du temps, l'individualisation du travail est à l'opposé de ce que propose l'agilité pour une équipe.
Après la division du travail et celle du temps, la partie déconstruction du travail de la Fresque de l’agilité aborde l’individualisation, qui est en quelque sorte une division des personnes.
Ajoutée à la division du travail, la division du temps rallonge le délai avant mise en service et met la pression sur les gens.
Adam Smith a inventé la division du travail. Frederick Taylor l’a complétée en divisant le temps de production en une suite de tâches élémentaires, répétées et chronométrées.
Le taylorisme a eu une influence considérable sur l’organisation du travail dans l’industrie. On en retrouve des traces, voire plus, dans des types de travaux pour lesquels il n’a pourtant pas été conçu, comme ceux de la connaissance et des services.
La division du travail est néfaste aux salariés ; elle nuit aussi aux usagers
Aux débuts de l’agilité, j’essayais de convaincre que la division du travail n’était pas du tout une bonne idée pour le développement de logiciel, qu’elle nuisait aux coéquipiers et à l’organisation.
Maintenant, en tant que cycliste dans ma ville, je constate que la division du travail est toujours appliquée, y compris dans les collectivités locales, et qu’elle nuit aussi aux usagers.
Dans son article initial de 1996, Ken Schwaber parlait volontiers de processus et de méthodologie. Plus tard Scrum a été souvent qualifié de méthode (agile).
Cette difficulté à classer Scrum a continué un certain temps.
Suite de la préface de Kanban pour l’IT, le livre de Laurent Morisseau, deuxième édition.
Cette deuxième partie évoque les approches processus pour montrer en quoi Kanban est différent.
Représentation de processus Il y a une quinzaine d’années, je m’intéressais de près aux notations, langages, modèles et méta-modèles (UML, SPEM, BPMN) pour représenter les processus.
On retrouve dans Kanban les mêmes notions de rôle, activité et élément de travail, mais avec une approche bien différente :