Si la gestion de projet vous intéresse, dans cette vidéo de 5 minutes, vous trouverez :
… et pour tordre le cou à certaines idées reçues 
Une façon de dire , que Eric Ries à juste remarketer un concept existant.
Ce n’est pas le but de la vidéo, Eric Ries est cité pour introduire le concept de MVP.
Car pour faire de l’agile, il faut bien partir d’un existant: un MVP par ex.
Les méthodes agiles ne sont que du Lean, c’est à dire de l’amélioration continue (il n’y a pas de fin défini… tant qu’il est possible d’améliorer, on améliore) ce qui s’oppose à la nature même d’un projet (et la notion de temporalité: un début et une fin explicite).
Ceci implique de passer par une méthode prédictive (cascade par ex.) à un moment ou un autre (au moins dans la 1ère itération de son produit ou service… le fameux MVP).
La vidéo démontre aussi que le fonctionnement des méthodes dites prédictives est itératif (voir agile dans un cadre de planification par vagues/rolling waves planning) et qu’il n’est en aucun cas question de suivre un plan coute que coute… contrairement à certaines idées reçues.
Edit:
La question de l’organisation d’équipe n’est pas abordé, cela nécessiterait une vidéo.
Scrum n’a rien inventé:
Les « tasks force » organisés dans des « war rooms » intègrent bien le client de la phase de planification jusqu’à la livraison dans des structures autonomes et auto-organisées (désolé pour les anglicismes) .
Et contrairement à une autre idée reçue, le chef de projet n’est pas le chef tout puissant et omniscient… c’est même contraire à l’éthique des référentiels tels que PMI (cf. Appendix) ou IPMA (cf. compétences comportementales).
Et je fini juste avec ceci:
Scrum n’est pas une méthodologie en gestion de projet, c’est un cadre organisationnel.
Pour le dev, par ex., on l’associe toujours à une méthodo projet type XP
Ok je m’y connais largement moins que vous en terme d’agile et de gestion de projet .
Je m’y connais largement moins j’ai lu deux livres Dunod pour la rédaction de mon mémoire de fin d’études.
« Les méthodes agiles ne sont que du Lean, c’est à dire de l’amélioration continue (il n’y a pas de fin défini… tant qu’il est possible d’améliorer, on améliore) ce qui s’oppose à la nature même d’un projet (et la notion de temporalité: un début et une fin explicite). »
Hum, quand j’étais développeur en Scrum mon ressenti était que grâce au découpage en petites tâches( post it ) tu n’as pas l’impression de faire de l’amélioration continue , mais tu as plus l’impression de finir des tâches l’une après l’autre.
Le gros projet devient une suite de tâches (de mini projet) que l’on peut terminer. (et évidement améliorer par la suite, mais à l’instant T ou tu fais ta tâche tu l’as fait comme spécifié et pas plus et pas moins. ).
J’ai juste pour intention d’apporter quelques précisions (pas de méprise, je ne cherche pas la polémique)…
Le découpage d’un projet en tâches n’est pas nouveau et n’est pas du fait de Scrum ou d’une autre méthode en gestion de projet.
Ca date du moyen âge avec les constructions monumentales (pas de trace écrite pour les périodes précédentes… à ma connaissance).
La normalisation dans tout type d’industrie, quant à elle, date de 1962 avec l’introduction du WBS par la NASA.
Depuis les années 60, tous les projets passent par ce découpage en tâches… lorsqu’on suit les règles de l’art.
Quelle que soit la taille de projet ou quelle que soit la méthode utilisée, on découpe toujours un projet en tâches (et non en mini-projet).
Et le post-it est utilisé partout et par tous 
Tout comme Scrum: on doit répondre à une spec, ni plus ni moins.
D’ailleurs (mais c’est valable pour n’importe quel projet), seul le maitre d’ouvrage (le client) peut modifier une spec ou, en tout état de cause, valider une modif de spec… jamais le maitre d’oeuvre (celui qui réalise).
Je crois que vos discussions soulignent un point important. L’agile n’est pas dans la méthode, ça je ne le crois pas. Une méthode est par définition rigide, puisqu’elle met un cadre. L’agilité doit surtout venir de l’humain selon moi. Et le management doit permettre à l’humaine de s’exprimer. Et seulement dans ce cadre on peut remettre en question la méthodologie, quelle qu’elle soit et on a de l’agile, parce qu’on s’adapte bien à l’humain. Le plus gros capital de l’entreprise.
Ensuite, Eric Ries a juste formalisé une nouvelle manière de voire l’entrepreneuriat, je ne vois donc pas le rapport avec la vidéo. Je trouve que l’auteur va trop vite et se concentre trop sur une méthodologie, avec un seul angle. Et telle qu’il a décrit le scrum, cette méthodologie n’est pas agile. D’ailleurs pour l’avoir vu appliquée dans une entreprise, je ne vois pas son agilité (la méthodologie en elle même, ce qui rapppelle mon premier paragraphe).
Je trouve à ce titre la vidéo de mauvaise qualité dans son rapport à l’agile.
L’agilité n’est pas le chaos, un cadre est donc nécessaire.
Et plus de personnes sont amenées à collaborer, plus il est nécessaire de mettre en place un cadre (ex. les règles de savoir vivre sont un cadre, nécessaires pour vivre en communauté).
Mais, en gestion de projet, agile signifie : Itératif, incrémental et adaptatif… et non flexible.
Ici il n’est nulle question de management RH mais de management de processus.
Le pendant RH est une question qui n’est pas abordé car trop de facteurs entre en ligne de compte pour ne pas y passer des heures (culture de l’entreprise ou managériale, profil des équipes, CP ou scrum master, du type de client, etc. etc.).
Eric Ries a été cité dans la vidéo car le terme MVP concerne bien un produit ou service et non l’entreprise.
D’ailleurs, tout le chapitre (ou partie de chapitre) consacré au MVP décrit bien la construction d’un produit/service en mode itératif, incrémental et adaptatif: une méthode agile tout simplement.
Tel que décrit dans la vidéo, le Scrum est bien agile : itératif (les sprints), incrémental (ajout de backlogs à chaque sprint) et adaptatif (en fonction des retours utilisateurs).
Pour la petite histoire :
Je suis l’auteur de la vidéo qui est à l’origine à destination de personnes ayant déjà une bonne connaissance en gestion de projet (agile et prédictif): pour une communauté crée autour d’un blog sur la thématique.
La partie Scrum est passé rapidement pour la raison suivante : le référentiel ne fait qu’une quarantaine de pages alors que les référentiels sur les méthodes prédictives font généralement plus de 200 pages (voir 700 pour certains).
Il s’agissait de respecter un certain équilibre sans entrer dans le détail puisque les référentiels sont téléchargeables sur le blog et expliqués depuis plus de 3 ans.