En apparence, la programmation agile et la gestion de portefeuille ne sont pas si semblables. Si vous regardez plus profondément, vous trouverez des parallèles intéressants.
J'ai découvert l'Extreme Programming et le Manifeste Agile il y a sept ou huit ans lorsque j'ai eu le plaisir de lire le livre de Kent Beck, Extreme Programming Explained , et par un heureux hasard, j'ai pu travailler avec lui. Je suis rapidement devenu un grand fan de Kent et de l'Extreme Programming et je l'ai utilisé sur chaque projet depuis lors. L'Extreme Programming, que je considère comme un synonyme des méthodes Agile à toutes fins utiles, s'articule autour de quatre principes : Communication, Simplicité, Retour d'information, et Courage. Exprimé en quatre mots seulement, cela ressemble à de l'obscurantisme à la mode. Mais si vous avez déjà dirigé un projet logiciel en difficulté, vous comprenez comment le Courage s'applique, et si vous ne comprenez pas la valeur de la Simplicité, vous n'avez jamais dirigé un projet logiciel réussi. La communication et le retour d'information sont, et ont toujours été, la clé du retour d'information, du leadership et du bonheur des clients.
Ce qui pourrait être considéré comme le revers de la médaille - lorsque j'ai lu Taming Change with Portfolio Management coécrit par Pat Durbin, PDG de Planview, j'ai vu que les deux systèmes s'attaquent réellement à des problèmes d'échelles différentes à partir des mêmes principes de base.
L'une des déclarations les plus frappantes dans Apprivoiser le changement est une déclaration très agile - l'exhortation à ne pas essayer de planifier trop loin dans le futur, ou à un niveau de détail trop fin. L'échelle de temps recommandée par Durbin est de 6 mois à 18 mois, ce qui est clairement très différent des 1-2 semaines pour un Sprint en Extreme Programming. Je pense toutefois qu'elle représente une réalité : les grandes organisations ne peuvent pas (encore) être planifiées à l'échelle hebdomadaire. Néanmoins, l'organisation qui devient constamment plus agile en améliorant constamment sa capacité à modifier ses plans et à planifier sur une échelle de temps plus réduite finira par réussir face à des concurrents moins agiles. Notez que la planification agile ne signifie pas une planification détaillée, mais juste la bonne quantité de planification.
Permettez-moi maintenant d'établir quelques analogies entre les deux systèmes. Le temps m'empêche de donner une définition complète de ces termes, mais si vous les étudiez dans Apprivoiser le changement et dans les ouvrages sur les méthodes agiles, je pense que vous conviendrez que l'analogie entre les deux systèmes est frappante :
Gestion de portefeuilles | Méthodes Agiles |
---|---|
Horizon de planification | Sprint |
Projet | Histoire |
Responsable de la gestion du portefeuille | Scrummaster |
Personnel exécutif | Product Owner |
Transparence organisationnelle | Communication personnelle |
Statut du projet | Commentaires des clients |
Planview ou système de gestion de portefeuille | Grands tableaux visibles collés au mur |
Il est clair pour moi que les fondateurs des deux systèmes partageaient des principes similaires, et ont construit des systèmes fonctionnels à partir de ceux-ci :
- L'honnêteté et la transparence conduisent à une bonne prise de décision.
- Les métriques et les métriques abstraites nous aident à rester honnêtes.
- Les rouages de l'organisation sont précieux dans la mesure où ils aident une entreprise à s'adapter au changement, et constituent un obstacle dans la mesure où ils ne le font pas.