[Shape Up] Organisez votre équipe de dév avec cette méthode efficace - Etape 1 - Shaping 2/5

Bonjour, on se retrouve pour cette seconde vidéo sur ShapeUp. Et donc on a vu dans la vidéo précédente une petite introduction. Donc si je résume, on a vu un petit peu les difficultés qu'on avait avec des méthodes traditionnelles. On a brièvement présenté le cycle de 6 semaines. Et puis ensuite on a introduit le concept de shaping, qu'est-ce que ça voulait dire. Et ensuite quelques avantages sur cette méthode ShapeUp, sur la responsabilité et sur un risque contrôlé. C'était l'introduction et donc là dans cette première partie de Shaping, on va rentrer plus en profondeur sur cette première étape, première étape sur trois, qui est le Shaping. Alors je mets cette image là puisque en fait ça résume assez bien la méthode Shapup, c'est directement, ça vient du livre. Et donc on va rentrer plus en détail dans les différentes phases. Et donc là on est dans la première phase, la phase Shape qui est en haut. modélise différemment en fait la phase de shaping c'est ce qui va nous faire passer d'une idée brute une illumination à quelque chose d'un peu plus formel c'est pas encore très structuré ce qui est structuré c'est ce qu'on a tout à droite là où on a compartimenté, validé des choses mais disons qu'on va passer d'un zigzag à une patate et cette patatisation c'est ce qu'on appelle le shaping Comme on l'a vu dans l'introduction, le but de cette étape, c'est que ce ne soit pas trop concret pour laisser de la place à l'équipe qui va construire, et pas non plus trop abstrait, parce que sinon l'équipe ne va pas savoir quoi construire. Pour ça, on va voir cinq parties, les principes fondamentaux, ensuite la manière dont on va fixer des limites, comment trouver les éléments, certains risques et rabbit holes, des trous de lapin. en anglais et ensuite un concept qui est le pitch. Alors les principes du shaping. Donc ce qu'on a vu tout à l'heure, enfin l'introduction, c'était de trouver le bon niveau d'attraction et typiquement ce qu'ils disent dans le livre c'est que les wireframes déjà c'est beaucoup trop concret. Il n'y a plus de place pour la créativité pour le designer et le développeur. Mais le problème c'est que les mots sont aussi trop abstraits. Un exemple qui... qui est introduit assez rapidement dans le livre, c'est de construire une vue d'un calendrier. Le problème, c'est qu'un calendrier, c'est énorme, ça veut dire plein de choses. Et donc, si on met juste ça, on ne va pas savoir qu'est-ce qu'on met et qu'est-ce qu'on enlève. Donc, c'est la première étude de cas qui est présentée. Là, j'ai listé quelques exemples de qu'est-ce qu'un calendrier. On peut ajouter... mettre des événements, on peut les bouger, on peut mettre des vues par mois, par semaine, par jour, on peut mettre des couleurs selon les catégories, etc. Évidemment, selon le mobile, selon le bureau, c'est pas la même chose. Donc ça, c'est compliqué. Ce qu'ils proposent comme démarche, c'est déjà d'aller voir les utilisateurs et de comprendre ce qu'ils veulent. Pourquoi ils veulent un calendrier ? Qu'est-ce qu'ils entendent par calendrier et quels besoins ils cherchent à remplir avec ça ? Et finalement, en faisant cette... ce product discovery, cette analyse des besoins, il se rend compte dans cet exemple-là, qu'en fait, ce que veut le client, c'est savoir quand est-ce qu'il a des événements dans les deux mois à venir. Donc la solution qu'il a retenue, c'est finalement d'avoir une vue d'un calendrier avec seulement un point sur les jours où il y a un événement, pas plus ni moins. Et ensuite, on va le voir avec les esquisses, les dessins, il y a beaucoup de choses. qui ne sont pas précisées justement pour qu'il y ait de la place pour le designer après. Là à gauche typiquement c'est le sketch, le concept de la vue calendrier de deux mois et à chaque fois qu'il y a un point, c'est à dire qu'il y a un événement et en fait le détail de l'événement il est sous le calendrier. Donc c'est suffisamment clair pour comprendre ce qu'on doit mettre ou pas et après ça laisse suffisamment de place à... l'équipe qui va l'implémenter. A droite on a ce qui finalement a été livré à la fin du cycle donc on voit qu'il y a plein de choses qui n'ont pas été forcément précisées et ça a été à l'équipe de faire des choix sur tous ces éléments là. Il y a trois propriétés qui définissent entre guillemets un bon shaping. Le premier c'est que c'est rude grosso modo c'est que tout le monde peut dire que c'est pas fini, qu'il manque des choses. Et ça c'est important, je l'ai déjà dit, mais voilà, le but c'est qu'on laisse de la place. Deuxième élément très important, c'est que c'est résolu. On a détaillé tout le chemin et il n'y a pas de doute. On comprend le début et on comprend le voyage jusqu'à la fin. Il peut toujours avoir des surprises, mais on comprend la valeur ajoutée qui est apportée par cette fonctionnalité. Troisième qui est très très important, c'est que c'est cadré. On va ajouter dans... dans ce qu'on appelle le pitch, c'est le résultat de l'étape de shaping, ce qu'on ne doit pas faire et où est-ce qu'on doit s'arrêter, qu'est-ce qui est compris, qu'est-ce qui n'est pas compris. Il y a un concept très important, c'est l'appétit. Et en fait, ça va à l'inverse des méthodes traditionnelles où on va définir des tickets en fonction d'un objectif concret de fonctionnalité. Là, l'idée, c'est qu'on se fixe... 6 semaines, un appétit de 6 semaines, et en 6 semaines, qu'est-ce qu'on peut faire ? Est-ce que c'est possible en 6 semaines ? C'est vraiment ça la spécificité de la méthode, c'est que c'est cadré, et le périmètre est invariable dans le temps. On y reviendra après, ne vous inquiétez pas, je sens que moi-même je ne suis pas forcément très clair, mais c'est des concepts qui vont revenir au fur et à mesure du livre, et donc au fur et à mesure des vidéos. Alors qui s'occupe de cette partie du shaping ? En fait, la partie shaping, c'est vraiment un ensemble entre le business, entre le design, entre la technique. Et donc, ce n'est pas forcément très évident. Donc, ce que recommande le livre, c'est qu'il faut que ce soit quelqu'un qui a une sensibilité par rapport au design, évidemment par rapport au produit, mais aussi qu'il soit... techniquement littérés, donc qui puissent assez facilement dire c'est possible, c'est pas possible ou c'est complexe. Et donc après on peut toujours l'adapter mais c'est vraiment le conseil qui guide. Et le dernier point c'est que le shaping c'est quelque chose d'assez stratégique, donc il faut que les sujets qui soient HEP, ils aillent dans le sens de la stratégie de l'entreprise. On ne va pas passer six semaines à shaper un sujet, donc on est quasiment sûr. qui ne va pas être poussé. La méthode, le livre, ne parle pas précisément de comment les sujets arrivent et dans les personnes que j'ai interrogées qui implémentent cette méthode, souvent il y a une sorte de pré-sélection, de framing. Dans un article que j'ai lu, le framing c'est comment on fait accoucher les idées qui vont être shapées. On va voir maintenant les quatre étapes importantes pour le shaping qui sont donc mettre des frontières, sortir les éléments grossiers, adresser les risques et créer le pitch. Le premier donc c'est mettre les frontières. Ce qu'il faut savoir c'est qu'une équipe dans Shapeup, en tout cas peut-être que c'est implémenté par Basecamp, c'est en général deux ou trois personnes, un designer et un ou deux développeurs. C'est toujours des petites équipes. pour que justement les gens restent très concentrés et j'imagine aussi que c'est pour diminuer le besoin de synchronisation avec des équipes où les gens sont beaucoup plus nombreux. Deuxième point c'est la taille en fait des sujets. Il y a deux tailles qui sont définies. Il y a le big batch, c'est ce qu'il y a à la fin là, c'est le travail classique de six semaines, un sujet pendant un big batch, mais il y a également des sujets plus petits qui ne rentrent pas dans six semaines et donc là en fait ils vont définir une ou deux semaines. et ils vont mettre plusieurs sujets, dits small batch, ensemble, pour que ça forme un ensemble de six semaines. C'est tout à fait possible. Ça, c'est ce que je disais tout à l'heure. Donc là, ça va être beaucoup plus simple. Le problème des estimations, c'est qu'on commence à voir avec des features, des propriétés, avec un design, et on finit avec un nombre. L'appétit, c'est l'inverse, justement. C'est qu'on démarre avec le nombre, six semaines, et ensuite, on fait un design qui correspond à ces six semaines. Cette contrainte, ça fait partie justement du process et ça va forcer en fait beaucoup plus facilement l'équipe à se mettre des contraintes, à faire des choix et à prendre ses responsabilités. Un exemple que je trouve très parlant, c'est justement dans le livre, il explique les contraintes par rapport à l'écriture de ce livre-là. Il dit qu'il peut toujours ajouter des choses, des chapitres, plus d'exemples, etc. Sauf qu'il a une deadline. pour faire ce livre et donc ça le force à faire des décisions. Et grosso modo, s'il ne lui reste qu'une semaine avant de publier ce livre, qu'est-ce qu'il fait ? Est-ce qu'il corrige des fautes d'orthographe ou est-ce qu'il ajoute un nouveau chapitre ? Donc du coup, il y a toujours cette tension entre le temps et la qualité. Et comme il ne veut pas publier un livre avec beaucoup d'erreurs, il fait la concession de se concentrer sur les erreurs. Ça, je pense que vous l'avez... tous vécu ce genre d'exemple quand vous étiez étudiant, vous avez retardé plus tard possible la rédaction d'un DM, d'un devoir à la maison ou d'une révision et vous y prenez la dernière minute parce que vous savez que le lendemain, c'est la hard deadline et vous ne pourrez pas y échapper. Donc vous vous forcez dans un temps défini à faire le travail. Donc cette tension, cette pression, c'est très important. une des phrases qui dit c'est que sans cette pression on ne fait pas de compromis parce qu'on peut toujours corriger, on peut toujours améliorer, toujours rajouter des choses. Le bien c'est relatif et ce qu'il dit c'est qu'en fait par rapport à un pitch et une feature il n'y a pas de meilleure solution. Une image que j'aime bien c'est en fait quand vous avez faim à un HowDog c'est parfait. Là c'est un peu le même état d'esprit qu'il faut avoir quand on design un pitch et quand on veut développer sur la méthode ShapeUp. Le problème, enfin le problème, ce qui va arriver c'est que du coup on va nous dire, on va nous balancer plein d'idées. Ah, il faudrait qu'on fasse sujet A, sujet B, sujet 3. Ce qu'il dit c'est que c'est important de jamais fermer la porte complètement. Il faut toujours dire, c'est ce qu'il met au début là sur la première ligne, intéressant peut-être un jour. Donc on ne ferme pas la porte, mais on ne s'engage pas non plus sur un oui ferme. Donc c'est un non, on va dire, doux. qui garde la porte ouverte. Un autre sujet qui m'a surpris, c'est qu'en fait, il n'y a pas de backlog de toutes ces idées. En tout cas, il n'y a pas de backlog au niveau le plus haut. Il y a un backlog, il y a la liberté que l'équipe fait ce qu'elle veut pour s'organiser, mais il n'y a pas ce backlog d'idées, puisqu'en fait, une grosse priorité, c'est de se concentrer sur ce qui est important maintenant. Qu'est-ce qui est important maintenant ? Et potentiellement, ce qui va arriver dans 6 semaines ou dans 12 semaines, ce sera plus important. Donc pourquoi s'embêter avec un backlog ? Et grosso modo, ce n'est pas la peine. Un autre point, c'est que quand les idées, quelquefois, il est un peu trop tôt de dire oui ou non, et donc il faut travailler sur l'idée, il faut prendre le temps, potentiellement organiser des sessions sur ça. Donc voilà un peu l'attitude à avoir quand vous recevez plein d'idées et que vous voulez appliquer la MT2ShapUp. Donc là, grosso modo, on a... le périmètre qui est en place, donc on va être prêt pour shaper. Trouver les éléments. Comment on trouve les éléments pour écrire un pitch ? Alors il recommande d'être seul ou à très petit comité avec quelqu'un où il n'y a pas besoin d'explicité, où il n'y a pas besoin de parler pour se comprendre. Et le but c'est que cette phase-là soit suffisamment concrète pour faire des projets et de ne pas s'engoutir dans les détails. Donc il faut vraiment être sur la même longueur d'onde pour avancer. Plusieurs techniques qu'ils utilisent, c'est le breadboarding, on va le voir juste après, et également la technique du marqueur, du gros marqueur, ce qu'on a vu tout à l'heure par exemple avec le calendrier, on avait finalement une esquisse grossière. Le breadboarding, je ne sais pas comment on appelle ça en français, mais ce n'est pas grave. Grosso modo c'est ce qu'on a à gauche, ça vient de l'électronique, où on a cette planche qui s'appelle un breadboard. on vient brancher tous les éléments électroniques. Ce n'est pas beau, mais ça permet de vérifier que ça marche, que la lumière s'allume. Donc c'est très différent du produit final, industrialisé, qui va avoir une belle boîte, un beau packaging, etc. Donc là, le but dans la phase de Shaping, c'est qu'on fasse quelque chose qui est à gauche. On vient brancher les éléments ensemble pour voir si ça marche. Et ensuite, ça sera l'équipe de Build qui s'occupera de livrer quelque chose comme on a à droite. Ce qui est important dans un shape, c'est de... d'afficher les choses essentielles, les écrans, les différentes transitions, les actions que l'utilisateur peut faire et toutes ces connexions entre tous les éléments. Un exemple qui est mentionné dans le livre, c'est l'autopay. Vous avez un site où vous vendez quelque chose et vous voulez mettre l'autopayement actif. Et la question c'est à quel endroit on le met ? Est-ce qu'on met sur la première facture ? Ce n'est pas forcément évident. Donc il y a un premier brouillon qui est fait au marqueur en disant que l'autopay, il est au niveau de la facture. On clique sur Turn Auto Pay, on arrive sur la configuration de l'autopay et ensuite on peut confirmer. Le problème c'est qu'avec le message d'avant, on n'a pas payé la facture. On a activé l'autopay mais on n'a pas payé la facture. Donc du coup, où est-ce qu'on met ? Est-ce qu'on met là ? Et on voit que grosso modo, c'est un travail itératif. On va venir modifier très facilement les différents éléments. Finalement, on paye avant, on change, on paye l'invoice et auto-pay in future, ça devient un paramètre de cette configuration, etc. Donc c'est ce travail itératif. Et à la fin, finalement, ce qu'on va mettre dans le pitch final du shaping, c'est la dernière phase qu'on a retenue. Le gros marqueur, c'est ce qu'on a mis tout à l'heure sur le calendrier. Là, c'est un autre exemple. de reconfiguration d'une to-do list. Et le but, la contrainte du marqueur épais, c'est justement de ne pas mettre trop de détails, de se forcer à rester du haut niveau et laisser la place au designer pour le reste. C'est très important de laisser la place, je le dis depuis tout à l'heure, mais c'est pour éviter les problèmes de compréhension. Avec le A, mais tu l'avais dessiné en haut à gauche, alors je pensais qu'il fallait le mettre en haut à gauche, mais non, en haut à gauche, c'était par exemple, tu peux le mettre à droite. Donc il y a tous ces non-dits qui ne sont pas forcément évidents. Donc trouver le bon niveau d'abstraction c'est vraiment quelque chose de fondamental et les gros marqueurs peuvent aider à ça. Alors les risques. Idéalement, quand on design une feature, donc là si on design quelque chose qui va prendre 6 semaines, la probabilité que ça tombe pile poil, elle est comme ça. Donc on voit qu'il y a quand même très forte chance que ça tombe à 6 semaines et très peu avant ou après. Le problème c'est que Dans la réalité, et vous l'avez sûrement vécu, c'est qu'en général, il y a des probabilités, que ça n'arrive plus de temps, on l'avait estimé, mais quelquefois, il y a toujours un petit truc à corriger, et puis un petit truc, on amène un autre, et puis un autre, et puis un autre, et puis un autre, etc. Et on glisse facilement de 6 semaines à 12 semaines, voire à 18 semaines. Et ça, c'est absolument ce qu'on veut éviter. Et c'est pour ça que la phase de shaping, elle est très très importante pour prendre le temps. d'analyser en slow motion en fait toute la feature. Et c'est peut-être la différence la plus grosse, en tout cas moi je vois comme ça, c'est que les tickets que j'ai à formaliser en général selon d'autres méthodes, j'ai pas le temps d'entrer en détail parce qu'il y a beaucoup de tickets à mettre en place, les tickets ça va occuper 2-3 jours, donc j'ai pas le temps. Là le fait qu'on va rester très haut niveau et qu'on va avoir 6 semaines pour créer finalement ce pitch, ça permet de passer en revue la feature. Donc, est-ce qu'il faut découvrir des nouvelles techniques qu'on n'a jamais faites avant ou est-ce qu'on va utiliser finalement des briques existantes ? Est-ce qu'on fait des hypothèses en particulier ? Grosso modo, on va se poser un maximum de questions pour que l'équipe n'ait pas à se les poser et qu'elle se concentre sur du travail effectif. Et donc le but, c'est d'enlever toutes les inconnues pour éviter cette fameuse... probabilité que ça glisse. On va essayer de tout enlever pour que ça tombe pile poil. Dans cette phase de shaping, il y a un concept aussi où on va dire clairement qu'est ce qui n'est pas inclus dedans. Les gens et vous voyez sûrement de qui je veux parler dans vos équipes, veulent faire leur mieux donc ils veulent absolument couvrir tous les cas et pour eux ça va être nécessaire. Il est hors de question de donner quelque chose qui n'est pas fini à un client. Le problème c'est que ça peut desservir le projet s'il y a trop de retard. Donc il y a un concept qu'on reverra aussi plus tard, c'est le scope hammering. Donc on prend vraiment un marteau et on vient taper sur le périmètre et on vient dire les cas qui ne vont pas être supportés. On le vient de dire de manière explicite pour pas qu'ils n'ambiguillent. Et on n'hésite pas à indiquer des choses comme des nice to have et pas des must have. Typiquement sur la to do list tout à l'heure, dans le livre, ils disent que coloriser les groupes ça peut être intéressant. Bon, coloriser les groupes, on va le mettre dans nice to have. Si on a le temps, on le mettra. Si on n'a pas le temps, on ne le mettra pas. Donc, c'est important d'avoir cette distinction entre le must-have et le nice-to-have. Pendant la phase de shaping, le but, ce n'est pas qu'une personne fasse tout seul dans son coin. Cette personne, elle va aller dialoguer avec tous les experts disponibles et surtout aller voir les experts en termes de technique. La question qu'ils m'ont posée, c'est est-ce que c'est possible ? Parce que forcément, les développeurs vous diront que tout est possible. C'est juste une question de budget et de temps. La question, c'est plutôt... Est-ce que c'est possible en six semaines ? Et en posant cette question, le but c'est d'aller justement chercher des trous à lapins ou des time bombs pour voir s'il n'y a pas quelque chose que vous avez supposé facile et qui en fait va retarder vachement l'équipe. Donc c'est très important cette phase, le shaper n'est pas du tout en isolation. Une fois que vous avez finalement fait tout ça, maintenant c'est le moment de décrire le pitch. Donc le but c'est de décrire un pitch. que l'on va présenter à la phase suivante, on va le présenter que c'est un pari. Enfin, concept, c'est pas... Enfin, il n'y a pas d'estimation, c'est vraiment le concept. On fait un pari sur cette feature et si ça marche, on sera très content. Si ça marche pas, on aura perdu que 6 semaines. Premier ingrédient de ce pitch, c'est le problème. Évidemment, c'est classique. Pourquoi on fait ça ? Deuxième ingrédient, c'est combien de temps on veut passer dessus. Est-ce qu'on fait un big batch de 6 semaines ou est-ce que c'est une ou deux semaines ? Et en fait, l'appétit va forcément contraindre la solution. Ensuite, description de la solution. Donc, comme on l'a dit, avec des fat-markers, avec du breadboarding, n'importe quoi. Quatrième ingrédient, les risques identifiés. Et cinquième ingrédient, ce qu'on ne va pas faire, ce qui n'est pas inclus dans la solution. Une fois que vous avez ça, vous avez votre pitch. Et on est tout bon, la phase de shaping est terminée. Donc là, on a un élément à inclure dans le pitch. ce qui est retenu pour la fonctionnalité d'Autopay. On peut aller plus loin, on peut récupérer des captures d'écran, on peut même aller encore plus loin et essayer de mettre un gros bloc assez flou sur le formulaire, on vient mettre plus en détail. Donc ça, ça dépend du niveau de détail que vous voulez accorder. Ce qui est sûr, c'est de mettre que des mots, c'est pas forcément idéal parce que l'abstraction des mots va prêter à confusion, à interprétation. Le but c'est quand même d'illustrer un maximum les propos du pitch. Et donc eux ce qu'ils font dans Basecamp, juste pour information, c'est qu'ils ont un canal dédié, ils envoient le pitch, parce qu'ils travaillent beaucoup de manière asynchrone, ils ne font pas de rayons là-dessus, et ensuite ils demandent aux gens de commenter. Et c'est important, la subtilité c'est qu'ils ne disent pas pour dire si c'est bien ou pas, parce que finalement ce n'est pas à l'ensemble de l'équipe de dire si c'est un bon pitch ou pas, c'est l'étape qu'on va voir juste après. lors de la betting table. Le but c'est juste de dire on a pensé à ça, est-ce que vous voyez des choses qu'on n'aurait pas vues, est-ce que vous pouvez être complété avec des informations que vous avez. Et ensuite donc là il y a un exemple d'un pitch qu'ils font donc très rapidement, vous pourrez faire pause pour voir le détail ou tout simplement le retrouver dans le livre. A gauche ils disent voilà ça fait 13 ans qu'on fait les to do list comme ça, le problème c'est qu'il y a ça et ça qui va pas. on met des diviseurs artificiellement, etc. Donc du coup, ce qu'on vous propose, c'est d'imaginer un truc comme ça. Et puis dans ce cas-là, ça fait ça. Dans ce cas-là, ça fait ça. Il y a même un moment, voilà, ici, sur la partie droite au milieu, il y a encore des questions ouvertes pour vraiment insister sur le fait que pour nous, on a suffisamment cadré, et ensuite le reste, c'est comme... Comme ça vous plaît, il n'y a pas de prérequis là-dessus. Voilà pour l'exemple de pitch. Et donc voilà, ça conclut cette première partie de shaping. Finalement assez dense, je suis passé très rapidement, mais vous verrez que dans les autres vidéos, on reviendra dessus et ça va passer tout seul. Donc si je résume, on a vu d'abord les principes du shaping. Il faut trouver le bon niveau d'abstraction, il faut que ce soit rude, il faut que ce soit résolu et il faut que ce soit cadarille. L'importance de mettre un bon périmètre. et notamment avec le concept de Fixed Time et Variable Scope. Donc vous définissez du temps et ensuite on essaie de faire rentrer la solution dedans. Troisième partie, c'était de trouver les éléments, donc comment on essaie de démarrer l'écriture de ce pitch là. Quatrième point très important, c'est de passer du temps à se dire où sont les risques, où sont les petits détails qui vont peut-être déstabiliser les clips. et surtout déclarer ce qui n'est pas inclus dans le périmètre, et enfin consulter des experts. Et une fois qu'on a fait tout ça, on peut démarrer à l'écriture d'un pitch, un pitch assez classique, problème, appétit pour dire, on va passer deux semaines et on fera ça avec ça, description en slow motion de la solution, les risques, et ensuite les no-go. Et une fois que vous avez ça, là vous avez votre pitch qui est prêt pour la prochaine étape. Donc la prochaine étape... c'est la partie du pari, donc autour de la betting table, et c'est ce qu'on verra lors de la prochaine vidéo. A bientôt !

📺 Dans cette vidéo, nous continuons notre découverte d'un livre génial sur l'organisation d'une équipe de Dév : Shape Up, Stop Running in Circles and Ship Work that Matters de Ryan Singer (Basecamp). 


🏋️ Dans cette vidéo, on a abordé (entre autres) :
- l'étape Shaping
- trouver le bon niveau d'abstraction
- passer la solution en slow motion
- bien dire ce que la solution NE fait PAS
...


Sur le livre : 
Site officiel : https://basecamp.com/books/shapeup


Maxime Pawlak
Curious CTO
https://twitter.com/maxime_Pawlak
https://www.twitch.tv/maxime_patate
https://maximepawlak.medium.com

Abonnez-vous à ma newsletter afin de retrouver toutes mes meilleurs lectures et découvertes ! C'est très intéressant et c'est toutes les semaines : https://maveille.substack.com/

00:00 Bonjour
01:26 Part 1 - Shaping
02:03 Set Boundaries
12:49 Find the Elements
16:26 Risks and Rabbit Holes 
20:17 Write the Pitch
23:32 Recap - Shaping