Shaping in a Nutshell
HTML-код
- Опубликовано: 19 окт 2024
- 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.co...
Get the book: basecamp.com/sh...
Written and illustrated by Ryan Singer
Filmed, produced, and designed by Katya Singer
© 2022 Ryan Singer
Its so true that distinction between Estimates and Appetites. I love that. It changes the energy of the conversation.
You totally got me in the key idea #3 when you mentioned "no daily meetings" XD
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.
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.
Thanks, this is incredibly clear. More video's please!
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.
Thank you! Well said about appetites.
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.
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. :)
Thanks Dakshi!
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!
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.
There are so many gems here!
Thanks!
Thanks, Ryan!
We do a lot of these things and got there by first principles. I totally feel our company should formally adopt this methodology.
Great summary. Really useful for sharing these concepts with others.
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.
Ryan, amazing video and great clarity. Will help me lots as I disseminate these concepts throughout my company.
Thanks Ilya! Will be so interesting to see how you adapt this at your scale.
Fantastic, Ryan. Looking forward to more of these from you.
This is terrific.
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.
"This is how I do my work when I work alone" - love that.
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. 👍🇺🇦
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 .
Very cool, thanks Julio. It's interesting, I noticed quite a few of the Shape Up early adopters were on data teams.
@@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).
@@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.
Thank you Ryan! Quality video you made there!
thank you 🙏
Wonderful!
Good stuff, Ryan. Plan on updating it to include framing? TIA
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
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! 🙌
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?"
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!
Thanks Tim!
Finally a developer friendly framework!
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.
How can I attend continuous integration, refactor code, document things if everything needs to be planned in a 6 week cycle? I would know how to handle it, but it's management who decides.
Great video!
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.
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
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.
Agree - you have to have an understanding of what's technically possible to set expectations for a project.
Going to try to apply this to a marketing team 👀 wish me luck
Cool! I'm curious how the concepts translate there. Reach out if you have questions.
@@feltpresence Me too
I love that the designer presenting the huge Figma file is wearing a beret :D
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!
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.
If the teams are formed anew for each cycle, how are they supposed to be able to figure out how to work as a team in just six weeks? Even if they figure it out by the end of the cycle, management is just going to press the reset button when the next cycle starts.
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.
Yes, when you define it in terms of the spirit and not the rules and rituals, I agree!
6:50 Sorry, but how is this not estimation? You still need to analyze and estimate what work can be done before the 6-week deadline.
Siorry, but before blaming other methods one should be familiar with: "Kanban board" is just a tool, not a method. Kanban itself helps you to find the method thats works for you and your team. And you event might end up with things that look like this idea. Which is totally fine if it works for you. But like Scrum: Its no silver bullet for each and everyone
the magic number seven, plus or minus two.
"No stand-ups".....10 words later "they can meet..."