Shaping in a Nutshell

A short introduction for people curious about Shape Up. It covers the key principles from the book in under twenty minutes.
00:00 Why people start questioning their process
02:53 Planning software: Comparison to building a house
04:00 Long plans vs. sprints vs. ~6 week time boxes
05:05 Key Idea #1: Estimate vs. Appetite
08:00 Key Idea #2: Shaping
08:57 Shaping: Defining the scope
10:17 Shaping: Latitude
13:03 Key Idea #3: Team Autonomy
16:22 Next steps
▶︎ For the "Shaping in Real Life" course, go to: feltpresence.com/srl
Get the book: basecamp.com/shapeup
Written and illustrated by Ryan Singer
Filmed, produced, and designed by Katya Singer
© 2022 Ryan Singer

[@mauric440]

You totally got me in the key idea #3 when you mentioned "no daily meetings" XD

[@Seanonyoutube]

Fantastic, Ryan. Looking forward to more of these from you.

[@geoblk3000]

On the "estimate vs appetite" section the response from clients to the question "How much time do we want to spend on this piece of work?" usually is "As fast as you can deliver it and we need it yesterday" so there's a lot of educating and work goes into this area with clients.

[@RVDL]

Thanks, this is incredibly clear. More video's please!

[@MingyarFurtadoMingyar]

Thanks, Ryan!

[@danil-old-web]

Thank you Ryan! Quality video you made there!

[@JeffreyKarl]

This is terrific.

[@alabhyajindal]

Wonderful!

[@raifshareef]

This blows scrum out of the water! I have been looking for ways to improve work culture and remote work for a loooong time. This is a gem. I hope there will be more videos on product management.

[@ReinierLadan]

I agree with you when you look at how organizations implement scrum unfortunately. But when you look at the actual scrum guide, there is so much overlap with Shaping. For example, there are no ‘tasks’ or ‘estimates’ to work with in scrum, organizations implement them themselves. Throwing Shaping into such an organization will have to deal with the same forces that apply tasks and estimates in their current scrum process.

[@joshk2598]

Great summary. Really useful for sharing these concepts with others.

[@feltpresence]

Thanks Josh. Yeah that’s the idea - it’s hard to tell people to go read a whole book. Hopefully a short video like this is more helpful to people who are checking it out for the first time.

[@milanofili4251]

thank you 🙏

[@Kisanindakianal]

Excellent video, qualitatively made, the author is inspired, definitely liked it. A fresh look at Agile, without illusions, false expectations - I think in a certain context it can show itself perfectly. 👍🇺🇦

[@pjtaei8197]

Great video!

[@isterin]

Ryan, amazing video and great clarity. Will help me lots as I disseminate these concepts throughout my company.

[@feltpresence]

Thanks Ilya! Will be so interesting to see how you adapt this at your scale.

[@ronlussari]

I've just started learning this because we are applying in the company I work. At first, it didn't sound good for me. It felt more for projects than products. However, now I see that this mixed with some discovery activities might help to get a better workflow than Scrumban or Scrum for remote teams. Of course, it always depends on the contexts and the adaptations we make to better fit our scenario. Good job!

[@feltpresence]

Thanks Rony. I'd be interested to hear about those adaptations you make. That's something I talk about in the Shaping in Real Life course - the many ways to do it differently while still following the core ideas.

[@pragatisinha]

There are so many gems here!

[@feltpresence]

Thanks!

[@underscoreroa]

Good stuff, Ryan. Plan on updating it to include framing? TIA

[@jonnigani]

Great video. So much knowledge delivered clearly in 17 minutes. I can't believe the concept of appetite is not more pervasive in the software industry. Business appetite is often known upfront ("We have 20 prospects waiting to sign up as soon as we have this feature, we should spend 6 weeks building it") so it makes sense to start with that and let it influence the solution. On the contrary, solution ideas are never a sure thing even with the most thorough research so why start with those and let them drive the estimate. Estimating doesn't actually make a lot of sense in many scenarios.

[@feltpresence]

Thank you! Well said about appetites.

[@vitaliygnatenko4113]

Ryan's work and approach is something that i was looking for for years. He is a game changer. Thanks Ryan! We all appreciate that you actually sharing this and looking for more info

[@dakshi01]

Thanks for doing this; I’ll have something to send to people when they ask “what Shape Up is?”, instead of saying “it’s the process used by folks at Basecamp”. This sure is a level up from the vimeo vids. Loved the high production quality. :)

[@feltpresence]

Thanks Dakshi!

[@archmad]

this is really great, this is honestly what I do my work when I work alone. always focus on mvp and shipping it asap. i do design, ux and programming at the same time so i know how to budget my design when to ship the programming part. but because im now in a bigger org, im just a lowly swe contributor, i cannot command the product team and other the stakeholders. i need to forward this to my boss, hopefully they'll change their mind on running things.

[@feltpresence]

"This is how I do my work when I work alone" - love that.

[@canUdig]

Hi Ryan , do you happen to have a ppt presentation you can share? I’d like to bring this to my engineering team for discussion … great book btw I read it last week

[@transformarecrescer]

Hi Ryan, I was - informal - early adopter just after reading the online book and all my knowledge acquired reading 37 signals books . I applied Shape Up to a data team I led and was amazing. Now Im deeply focused in share it and support more teams with your marvelous work .

[@feltpresence]

Very cool, thanks Julio. It's interesting, I noticed quite a few of the Shape Up early adopters were on data teams.

[@transformarecrescer]

@@feltpresence Nice talk to you. First of all, thanks for help people around the world. Its fits very well in data teams - in my opinion - because shape up focus on strategy and not just about build "things". In BI area (big data, data science, DW) people need to work strategically with information (hmm its should be hehe).

[@transformarecrescer]

​@@feltpresenceRyan, I would like to interview you by video or if possible a written Q&A to share to my brazilians folks. 
You understood that the big problem with methods is to deal with the nature and not about the order. You explained in a well organized elements not about just a method or a way, but the philosophy behinds “the nature of building tech solutions”. For me, Shape up is not just "ordering things " to achieve a goal. Look, when I read about "discovered tasks" I realized : Shape Up explain the nature of our projects. Its is how its work naturally. It is not one more method telling how to order things. You know, there are a lot of methods dealing with “ an order of software development process”. In my opinion you create a strategy to deal with the nature projects that deals with creative process like design/programming software.

[@romerort]

Cool, this is the situation when you are not following Scrum completely, and it looks like you are making mistakes, but eventually, you are following a new hybrid approach that works much better.

[@formyeve]

It's interesting, as a music producer, these concepts carry over really well to collaborations and personal projects, but the one interesting caveat is rough-drafting, or finding the right level of 'latitude'. I feel like it works a little differently with music, in that there's just something about music that makes it set itself in your mind really fast. The more you listen to a specific idea, the more 'shaped' the idea becomes. The more attached you become to it, and the harder it is to hear anything different. In other words, whereas in the context of programming, over-shaping happens the more visual details you apply, in music, over-shaping happens the more you consume an idea, the more times you listen to it, regardless of it's intrinsic level of detail.

[@kanstantsinmalikau7598]

Finally a developer friendly framework!

I really love this approach where managers set how much time developers should spend on a task instead of making hard-to-accurate estimates. It makes things clearer! But, I'm wondering if managers can accurately understand what's achievable in the timeframe they set. Would it help to discuss the timeframe with the developers? I've often found that clear communication from management about their expectations can solve many issues.

[@feltpresence]

Agree - you have to have an understanding of what's technically possible to set expectations for a project.

[@alejandrombc]

Awesome video!, well explained!!. I have a question about appetite, when you say "I want to spend 3 weeks making this X thing" and then generate a solution to couple with that, arent you "estimate" it too?. Like you could easily be wrong on your estimates that "I can do all this things in the 3 week period" but failed in the execution (because you estimate wrongly). Like in your example of going out to dinner. You are estimating that with X amount of money you could get a steak, chicken or fish, but that is a also an estimation you can be wrong about. What happened then?, if your time is fully fixed and you estimate wrongly, that kinds of assemble to "scrum" in some way don't it?. How the framework handle this scenarios?, probably you will need to chop features to fullfil the timebox, but in many scenarios thats not feasable. Sorry if I missunderstood, I really want to understand all the core concepts to start practicing it! 🙌

[@feltpresence]

Thanks Alejandro. Great question. The difference is in the order of things. It's common to first come up with an ideal solution ,then guess how long it will take. When you flip that order around, you start with the time you want to spend, and then you design options to fit inside that time. Both involve estimation. The difference is that in the second case, you take the time box as a creative constraint when you design. Practically, that means in a shaping session you will see different options on the table that make different trade-offs to fit inside of the limited time box. Asking "what could we do in X weeks?" with the expectation that there will be different trade-offs leads to a very different conversation than simply asking "what's the best solution and how long will it take?"

[@cahilltim]

Great presentation! The course sounds great, especially with a focus on companies who may not fit how Basecamp operates or is staffed. Will be brining some concepts from this as we can!

[@feltpresence]

Thanks Tim!

[@viniciuscorrea5104]

Thanks, Ryan! We've used Shape Up in our company for almost 3 years, and one recurrent problem that we had was not having problems shaped enough for engineering to start shipping. We often needed to do more discovery, but since the new 6 week cycle had started, we just shipped what we had so far, but with low confidence on what we were building. So, in that sense, we felt that we were serving the process rather than the opposite. Did you face this issue when refining the framework, and, if so, how to address it? Cheers!

[@feltpresence]

Hi Vinícius. Yes, that's an example of under-shaping. The short answer is to bring a technical person into the shaping sessions, so the shaping isn't just about what to do but also how to technically accomplish it. I get into that in more depth, with specific techniques for what to do in the shaping sessions, in the upcoming course Shaping in Real Life. See the link in the description above.

[@ninabaghdasaryan7872]

Going to try to apply this to a marketing team 👀 wish me luck

[@feltpresence]

Cool! I'm curious how the concepts translate there. Reach out if you have questions.

[@adebolaadeola]

@@feltpresence Me too

[@v2rv]

I love that the designer presenting the huge Figma file is wearing a beret :D

[@annagulstine948]

Great video! I disagree with the mindset that I'm hearing that Shaping doesn't fit with Scrum. Scrum about cycles of inspection and adaptation, not about following inflexible rules and rituals. At its heart it is not about process. I think Scrum and Shaping absolutely can work together.

[@feltpresence]

Yes, when you define it in terms of the spirit and not the rules and rituals, I agree!

[@transformarecrescer]

the magic number seven, plus or minus two.

[@mattlowe9675]

"No stand-ups".....10 words later "they can meet..."