What do you think?
Rate this book
Shape Up: Stop Running in Circles and Ship Work that Matters
This is an online web book about how Basecamp does their work.
"This book is a guide to how we do product development at Basecamp. It’s also a toolbox full of techniques that you can apply in your own way to your own process.
Whether you’re a founder, CTO, product manager, designer, or developer, you’re probably here because of some common challenges that all software companies have to face."
"This book is a guide to how we do product development at Basecamp. It’s also a toolbox full of techniques that you can apply in your own way to your own process.
Whether you’re a founder, CTO, product manager, designer, or developer, you’re probably here because of some common challenges that all software companies have to face."
133 pages, ebook
First published June 1, 2019
350 people are currently reading
5967 people want to read
About the author
Ryan Singer
6 books42 followersLibrarian Note: There is more than one author in the Goodreads database with this name.
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 30 of 315 reviews
August 12, 2020
I was originally recommended this book by a friend who made a note on how Basecamp is describing their software development process - that is not waterfall, agile or scrum - and how it works really well for them.
Intrigued by this thought, I immediately picked up the book to understand how another company can have such success without utilising the prevalent agile principles that are ubiquitous in most tech companies today.
The book was a very short and easy read (finished it in a day). This was great because I was able to get the insights that I wanted quickly. However, it is also a key reason why I rated the book as I have (3/5) - it is predominantly based on anecdotal evidence. I would have much preferred a fully developed set of ideas for the book to rank higher. That said, the book was successful in talking about how Basecamp works in a very accessible manner.
Now - was Basecamp’s claim true? That they have come up with a unique software development methodology pure of the buzz of waterfall, agile and scrum? I don’t think so. After reading what they described, I think they described the principles and mindset behind agile frameworks with greater clarity and detail than many things I’ve read. However, they used their own terminology to describe them.
Let me go through some examples that the book claims is unique about their in-house processes:
- six weeks cycle, followed by cool-down
Although it is not common practice, nothing stops a team to define their sprints for a period of 6 weeks to get the benefits that the book is talking about. That said, it was great to read the thinking that went behind this standardisation of cycle time. It gives a team enough runway to own and commit to a deliverable at the end.
- shaping, before we commit to a project
I don’t see any different than “refinement” or “grooming” of work. The idea is the same - before starting any work, spending upfront time trying to remove uncertainty from the project, considering risk, and increasing confidence in the understanding of the work
- fixed time, variable scope
That’s exactly the purpose of defining a “sprint” period. An artificial time constraint, that requires a team to commit to delivering a piece of work within that time, that is of value.
The book rightly calls out some of the benefits of having such a commitment or “deadline” - it makes teams conscious of the scope that they are taking in, and pushes them to consider cutting down scope to meet the fixed time that they have.
- hammering scope
An amplified imperative in the organisation for not just cutting scope, but aggressively doing so. Because delivering value is a non-negotiable tenant that they have.
- no backlogs
Whilst they don’t have “backlog items” in the traditional sense, Basecamp has pitches. Detailed one pagers that talk about the work that should be done just before the commencement of cycle.
Is that any different than how a scrum team operates? In my opinion, no! A good scrum will have a backlog that is constantly refined with great level of detail as the work gets closer to be taken into a cycle. Part of the detail includes assumptions and background information on why this work item is important at a point of time. A good scrum team will always review these assumptions and confirm if the case they are making still holds before pulling them in.
- betting instead of planing
Whilst traditionally scrum planning is more about a team discussing how they should tackle refined and accepted work, all work items is accepted as bets. Work items are nothing more but assumptions that if certain effort is made today, that a specific value will be achieved as a result.
Again, using the “betting” terminology is a great reminder of anyone or any team governing a backlog to remember that every backlog item needs to be valuable and have a payout.
The other benefit that comes with this terminology, is that you would naturally want to see a bet through. So when a work item is picked up in a cycle or a sprint, the team has the right to not be interrupted during their executions of it, and has the responsibility of committing to this bet at all costs.
—
Processes aside, there are two things that I really liked that I wanted to call out. One is a tool, and the latter is a tactic.
Tactic - QA in a team is a level-up
Similar to teams that I have worked with, Basecamp were largely made up of teams that are made up of developers that collectively own quality. However, as they grew in size and saw that small edge cases are starting to slip through as bugs to customers, they’ve had to consider adding an extra QA step to reduce the load of support.
What they also called out, is that this QA role was there to complement the existing system. They left quality to be owned by development teams, however, they assisted them by focusing exclusively on testing edge cases.
Tool - The “hill”
One of the powerful points that Basecamp makes in the book, is how work estimates does not show uncertainty. The example they give is that of two 4 hours tasks; the first you’ve done ten times in the past, and the second, you’ve never done before.
To solve this problem, they came up with a “hill” visualisation (think of a bell curve) that they’ve asked their teams to mark different pieces of work on at different stages. The uphill phase of the bell curve is full of uncertainty, unknowns and problem solving. The downhill phase is marked by certainty, confidence and knowing what to do.
This visualisation is great self reflection to the team, as they could employ different methods when they articulate to themselves what their confidence of the work is. It is also a valuable data point to management who can proactively lean in with support before an issue lingers and stalls.
—
This was a very refreshing read that I would highly recommend development teams and engineering managers to read. Particularly those who are feeling that they are working with teams who are simply doing the agile motions with little thought to the actual agile mindset.
Whilst I would have like Basecamp to acknowledge the large commonality that their ideas have with established mainstream ideas, I do see one benefit with their use of different terminology. And that is putting a spotlight on the specific agile principles that are important to them.
This read has made me consider rebranding some of the practices that I would love my teams to focus on, by giving them a fresh look that would strike curiosity and change.
Intrigued by this thought, I immediately picked up the book to understand how another company can have such success without utilising the prevalent agile principles that are ubiquitous in most tech companies today.
The book was a very short and easy read (finished it in a day). This was great because I was able to get the insights that I wanted quickly. However, it is also a key reason why I rated the book as I have (3/5) - it is predominantly based on anecdotal evidence. I would have much preferred a fully developed set of ideas for the book to rank higher. That said, the book was successful in talking about how Basecamp works in a very accessible manner.
Now - was Basecamp’s claim true? That they have come up with a unique software development methodology pure of the buzz of waterfall, agile and scrum? I don’t think so. After reading what they described, I think they described the principles and mindset behind agile frameworks with greater clarity and detail than many things I’ve read. However, they used their own terminology to describe them.
Let me go through some examples that the book claims is unique about their in-house processes:
- six weeks cycle, followed by cool-down
Although it is not common practice, nothing stops a team to define their sprints for a period of 6 weeks to get the benefits that the book is talking about. That said, it was great to read the thinking that went behind this standardisation of cycle time. It gives a team enough runway to own and commit to a deliverable at the end.
- shaping, before we commit to a project
I don’t see any different than “refinement” or “grooming” of work. The idea is the same - before starting any work, spending upfront time trying to remove uncertainty from the project, considering risk, and increasing confidence in the understanding of the work
- fixed time, variable scope
That’s exactly the purpose of defining a “sprint” period. An artificial time constraint, that requires a team to commit to delivering a piece of work within that time, that is of value.
The book rightly calls out some of the benefits of having such a commitment or “deadline” - it makes teams conscious of the scope that they are taking in, and pushes them to consider cutting down scope to meet the fixed time that they have.
- hammering scope
An amplified imperative in the organisation for not just cutting scope, but aggressively doing so. Because delivering value is a non-negotiable tenant that they have.
- no backlogs
Whilst they don’t have “backlog items” in the traditional sense, Basecamp has pitches. Detailed one pagers that talk about the work that should be done just before the commencement of cycle.
Is that any different than how a scrum team operates? In my opinion, no! A good scrum will have a backlog that is constantly refined with great level of detail as the work gets closer to be taken into a cycle. Part of the detail includes assumptions and background information on why this work item is important at a point of time. A good scrum team will always review these assumptions and confirm if the case they are making still holds before pulling them in.
- betting instead of planing
Whilst traditionally scrum planning is more about a team discussing how they should tackle refined and accepted work, all work items is accepted as bets. Work items are nothing more but assumptions that if certain effort is made today, that a specific value will be achieved as a result.
Again, using the “betting” terminology is a great reminder of anyone or any team governing a backlog to remember that every backlog item needs to be valuable and have a payout.
The other benefit that comes with this terminology, is that you would naturally want to see a bet through. So when a work item is picked up in a cycle or a sprint, the team has the right to not be interrupted during their executions of it, and has the responsibility of committing to this bet at all costs.
—
Processes aside, there are two things that I really liked that I wanted to call out. One is a tool, and the latter is a tactic.
Tactic - QA in a team is a level-up
Similar to teams that I have worked with, Basecamp were largely made up of teams that are made up of developers that collectively own quality. However, as they grew in size and saw that small edge cases are starting to slip through as bugs to customers, they’ve had to consider adding an extra QA step to reduce the load of support.
What they also called out, is that this QA role was there to complement the existing system. They left quality to be owned by development teams, however, they assisted them by focusing exclusively on testing edge cases.
Tool - The “hill”
One of the powerful points that Basecamp makes in the book, is how work estimates does not show uncertainty. The example they give is that of two 4 hours tasks; the first you’ve done ten times in the past, and the second, you’ve never done before.
To solve this problem, they came up with a “hill” visualisation (think of a bell curve) that they’ve asked their teams to mark different pieces of work on at different stages. The uphill phase of the bell curve is full of uncertainty, unknowns and problem solving. The downhill phase is marked by certainty, confidence and knowing what to do.
This visualisation is great self reflection to the team, as they could employ different methods when they articulate to themselves what their confidence of the work is. It is also a valuable data point to management who can proactively lean in with support before an issue lingers and stalls.
—
This was a very refreshing read that I would highly recommend development teams and engineering managers to read. Particularly those who are feeling that they are working with teams who are simply doing the agile motions with little thought to the actual agile mindset.
Whilst I would have like Basecamp to acknowledge the large commonality that their ideas have with established mainstream ideas, I do see one benefit with their use of different terminology. And that is putting a spotlight on the specific agile principles that are important to them.
This read has made me consider rebranding some of the practices that I would love my teams to focus on, by giving them a fresh look that would strike curiosity and change.
April 11, 2021
In the intro of “Thinking, Fast and Slow” Kahneman describes his book as an attempt to enrich the vocabulary of "watercooler conversation”. By giving people more precise language to work with, he hopes to enable more succinct and intelligent conversations. “Oh, that sounds like you’re falling prey to the availability heuristic” carries much more meaning than saying “Don’t you think you might be overestimating this, because you maybe read about it in the newspapers recently?”. In the days after reading a non-fiction book, I will sometimes catch myself using new words (or old words with new meanings) in conversations with friends or co-workers. A simplified, but useful heuristic: The more new words I use, the better (or more interesting) the book.
Shape Up is one of those books with a lot of useful new words (in this case for talking about product delivery). It is thought-provoking and easy to read. My favorite new vocabulary includes: shaping, appetite, breadboarding, scopes and uphill and downhill phases of work.
While Singer never points it out himself, he (and the other people at Basecamp) seem to be acutely aware of the power of precise language. Here is a quote straight from the foreword: “We don’t do daily stand ups, design sprints, development sprints, or anything remotely tied to a metaphor that includes being tired and worn out at the end.” For a random other example, read the section about “The meaning of a bet” (which has payouts, is a commitment and has a cap on the downside) and you’ll see what I mean.
While we’re at it here are two more (in this case absolutely random, but lovely) quotes:
“Estimates start with a design and end with a number. Appetite starts with a number and ends with a design”
“Beware the simple question: Is this possible? In software everything is possible, but nothing is free.”
Shape Up is one of those books with a lot of useful new words (in this case for talking about product delivery). It is thought-provoking and easy to read. My favorite new vocabulary includes: shaping, appetite, breadboarding, scopes and uphill and downhill phases of work.
While Singer never points it out himself, he (and the other people at Basecamp) seem to be acutely aware of the power of precise language. Here is a quote straight from the foreword: “We don’t do daily stand ups, design sprints, development sprints, or anything remotely tied to a metaphor that includes being tired and worn out at the end.” For a random other example, read the section about “The meaning of a bet” (which has payouts, is a commitment and has a cap on the downside) and you’ll see what I mean.
While we’re at it here are two more (in this case absolutely random, but lovely) quotes:
“Estimates start with a design and end with a number. Appetite starts with a number and ends with a design”
“Beware the simple question: Is this possible? In software everything is possible, but nothing is free.”
July 20, 2019
Contains a lot of good, sane advice on how to structure software development efforts and gave me quite a few ideas that I would like to try out at some point (hill diagrams for status reporting, their form of triaging, bets, their cadence, etc).
Thoroughly enjoyed it. A typical Basecamp book
Thoroughly enjoyed it. A typical Basecamp book
September 29, 2019
The book explains with very good details the process of Product Development in Basecamp.
And, IMO, it is one of the best implementations of Agile practices I ever read/seem. While most of the Scrum practices in companies become a "rush to deliver" methodology. What is presented by Ryan Singer is much more focused in delivering value and focusing in communication.
A few interest points is the cycle length, which is pretty long. – normally people stay in one week and half or two, and checking process. But besides all that, the main take aways are, divided by shaping and executing:
Shaping:
- Hammer your tasks to have the right level of abstractions, not leaving big rabbit holes, but being open enough to let design and developers work.
- Break your project to fit the cycles, not the cycles to fit your projects/tasks.
- Work with projects! (No tasks backlogs, no Business Point and Implementation points) One project with one final goal. The operation will break it.
Executing:
- Divide the whole project into scopes (small visible and concrete parte of the implementation)
- Start from the most uncertainty part and build around it.
- Work vertically to deliver something concrete and actionable. (Build the core and then refine it)
- Give status update a few days after the cycle has began and do it asynchronous!
I love the idea of working on one big project instead of having lots of small (and normally, unrelated tasks). This gives much more a sense of goal and direction.
And, IMO, it is one of the best implementations of Agile practices I ever read/seem. While most of the Scrum practices in companies become a "rush to deliver" methodology. What is presented by Ryan Singer is much more focused in delivering value and focusing in communication.
A few interest points is the cycle length, which is pretty long. – normally people stay in one week and half or two, and checking process. But besides all that, the main take aways are, divided by shaping and executing:
Shaping:
- Hammer your tasks to have the right level of abstractions, not leaving big rabbit holes, but being open enough to let design and developers work.
- Break your project to fit the cycles, not the cycles to fit your projects/tasks.
- Work with projects! (No tasks backlogs, no Business Point and Implementation points) One project with one final goal. The operation will break it.
Executing:
- Divide the whole project into scopes (small visible and concrete parte of the implementation)
- Start from the most uncertainty part and build around it.
- Work vertically to deliver something concrete and actionable. (Build the core and then refine it)
- Give status update a few days after the cycle has began and do it asynchronous!
I love the idea of working on one big project instead of having lots of small (and normally, unrelated tasks). This gives much more a sense of goal and direction.
August 10, 2019
In a world of software development, where we follow agile ceremonies (daily standups, retrospectives, backlogs) this is a very fresh take on what it means to be truly agile, pragmatic a ship early work that really matters.
August 1, 2019
Ryan Singer is a God. Probably the best book I have read on managing a project. The ideas of taking bets, scoping and plotting scopes in hills were amazing. Please read this if you work in tech :)
May 1, 2020
Очень интересная концепция шейпинга - между раздачей общих указаний по которым непонятно что конкретно делать и расписыванием задач детально, что сильно ограничивает возможности исполнителей. Правильный уровень детализации задач - полезная компетенция для менеджера
September 14, 2021
Read this one for work. The concept is interesting: work with fixed time and variable scope; no backlogs; a single meeting for prioritization and resource allocation. I can see the appeal, though I also see some downsides/risks and how the process may not work as well outside of small companies.
The e-book is pretty short and easy to read. The author did a good job of getting his point across concisely, with concrete examples and illustrations.
The e-book is pretty short and easy to read. The author did a good job of getting his point across concisely, with concrete examples and illustrations.
November 3, 2019
Not only did I enjoy reading this book, it gave me a better understanding of what I really want from a good work-related book.
First of all, it’s short and concise - 130 pages is very easy to commit to and I finished it in a short time for someone who reads 5-10 books in parallel. It also tells be that the authors respect my time, there is no fluff padding to the core ideas.
The book is free and not printed yet, maybe that is why it is unapologetically specific to Basecamp’s way of doing things and doesn’t smell of gospel. This is how we do things at Basecamp after trying many different approaches, maybe you will find some of our findings useful. Despite such humility I have found a lot of courage in the book - it effectively says “Many standardised methods of the modern Agile industry (not to be confused with what agile methodology started as) just don’t work” - 2 week cycles are too short, backlogs are cemeteries of ideas etc.
Scaling this approach to really big teams and implementing them in organisations far behind the modern ways of building software might not be feasible but that’s the beauty of the book - it doesn’t suggest it is. It just showcases how Basecamp does things and offers others to learn something from it. For free.
The book is very much like a good conference workshop in writing. I would really want to see more authors follow this example. Picking up so many useful methods from so little text is the best investment of time I’ve done I a while.
First of all, it’s short and concise - 130 pages is very easy to commit to and I finished it in a short time for someone who reads 5-10 books in parallel. It also tells be that the authors respect my time, there is no fluff padding to the core ideas.
The book is free and not printed yet, maybe that is why it is unapologetically specific to Basecamp’s way of doing things and doesn’t smell of gospel. This is how we do things at Basecamp after trying many different approaches, maybe you will find some of our findings useful. Despite such humility I have found a lot of courage in the book - it effectively says “Many standardised methods of the modern Agile industry (not to be confused with what agile methodology started as) just don’t work” - 2 week cycles are too short, backlogs are cemeteries of ideas etc.
Scaling this approach to really big teams and implementing them in organisations far behind the modern ways of building software might not be feasible but that’s the beauty of the book - it doesn’t suggest it is. It just showcases how Basecamp does things and offers others to learn something from it. For free.
The book is very much like a good conference workshop in writing. I would really want to see more authors follow this example. Picking up so many useful methods from so little text is the best investment of time I’ve done I a while.
March 16, 2021
Many great insights here.
Especially on the hill charts and the idea that a shaped project should not be too abstract, either too concrete.
However, there is a ton of questionable issues here the main ones for me are:
- Abolishing the backlog while suggesting a terrible huge to-do list that does not inform the status of a task.
- Separating the discovery process from the development team. It is like having two teams (one high profile senior team, that shapes, and a junior team, that builds) and that does not make sense at all. The discovery process happens throughout the process and the more we separate teams on that subject the less context the building team will have. Of course, you should not keep bringing a high level of uncertainty to the building team, but protecting them against uncertainty behind closed doors is not wise at all. Those that build have HUGE insights for the discovery process.
- The book messes up on explaining who are the stakeholders at the betting table, it implies that the team is not a stakeholder.
- The book doesn't mention if the Product Owner exists and if she works with the Building or the Shaping team.
- Maybe with a very very experienced team, that has worked together for a long time, the strategies of the book might work.
- The general tone of the book is truth-monopolist and not an experience report.
Still, there are some good insights. o/
Especially on the hill charts and the idea that a shaped project should not be too abstract, either too concrete.
However, there is a ton of questionable issues here the main ones for me are:
- Abolishing the backlog while suggesting a terrible huge to-do list that does not inform the status of a task.
- Separating the discovery process from the development team. It is like having two teams (one high profile senior team, that shapes, and a junior team, that builds) and that does not make sense at all. The discovery process happens throughout the process and the more we separate teams on that subject the less context the building team will have. Of course, you should not keep bringing a high level of uncertainty to the building team, but protecting them against uncertainty behind closed doors is not wise at all. Those that build have HUGE insights for the discovery process.
- The book messes up on explaining who are the stakeholders at the betting table, it implies that the team is not a stakeholder.
- The book doesn't mention if the Product Owner exists and if she works with the Building or the Shaping team.
- Maybe with a very very experienced team, that has worked together for a long time, the strategies of the book might work.
- The general tone of the book is truth-monopolist and not an experience report.
Still, there are some good insights. o/
September 2, 2019
Awesome book. It shows that to be agile you can start with some good defaults but eventually you have to shift to what's best for your team/company. This book is not revolutionary though. Evolutionary? Yes. They get some of known agile practices from other methods, change their name, size or order and arrange in a way that work for them. For example, they use a 6-week "sprint" but call it a Cycle. In general the names they chose are better names than the ones that existed before.
The more important part of this book is how they take something that normally happen after and bring back to the beginning of the process. It even gives the book its name. Shaping the work to be done is basically what Grooming should be but broken down in 3 iterative parts, one more concrete than the other. And at the beginning of the process instead of happening after some Priorization (or even Planning). The `betting table` is also a better name for Priorization. It is explicit about its intent and gives a better feeling in case success is not reached.
I hope people read this book and think about their own process instead of blindly copying it. We've seen what happened when everyone tried to copy Spotify's model. If you don't have the team and company structure as they have you'll probably have a hard time adopting these ideas. In a hierarchical and departmentalised world this won't work.
The more important part of this book is how they take something that normally happen after and bring back to the beginning of the process. It even gives the book its name. Shaping the work to be done is basically what Grooming should be but broken down in 3 iterative parts, one more concrete than the other. And at the beginning of the process instead of happening after some Priorization (or even Planning). The `betting table` is also a better name for Priorization. It is explicit about its intent and gives a better feeling in case success is not reached.
I hope people read this book and think about their own process instead of blindly copying it. We've seen what happened when everyone tried to copy Spotify's model. If you don't have the team and company structure as they have you'll probably have a hard time adopting these ideas. In a hierarchical and departmentalised world this won't work.
July 11, 2019
This book is two things - it lays out the way the people at Basecamp, the company, work and serves as a detailed manual to Basecamp, the product. It cohesively describes how all the features of the software are supposed to be used, how they fit together, as well as the reasoning behind each of them. There are concrete examples for every concept explained. Many of ideas are examined at different angles depending on the context of the current chapter. The book has nice visual design with well-annotaed diagrams, as well as minimalistic funny cartoons here and there.
I cannot attest to how effective the methodology laid-out really is, but I'm willing to give it an honest try.
This book is definitely something worth reading by anyone, interested in work organization and software project management.
I cannot attest to how effective the methodology laid-out really is, but I'm willing to give it an honest try.
This book is definitely something worth reading by anyone, interested in work organization and software project management.
March 26, 2021
Like other Basecamp's books, I enjoyed reading this one as well.
The book describes Basecamp's process of product development.
It deals with how to take raw ideas and shape them into something that the team can take ownership of, pitching and betting, 6-week sprints, cool-down, standard team sizes, estimations vs appetite, how to define scope - and ways to hammer it down, making the progress and risks more visible, and practical tips of how to introduce and adjust some of these methods into your organization.
Some of the things you might already be doing intuitively and the book does a very good job in putting it into a model, describe the reasoning behind it, and place it together into a system.
While other concepts were new and inspiring, and encourage me to rethink how we do things and experiment.
The book describes Basecamp's process of product development.
It deals with how to take raw ideas and shape them into something that the team can take ownership of, pitching and betting, 6-week sprints, cool-down, standard team sizes, estimations vs appetite, how to define scope - and ways to hammer it down, making the progress and risks more visible, and practical tips of how to introduce and adjust some of these methods into your organization.
Some of the things you might already be doing intuitively and the book does a very good job in putting it into a model, describe the reasoning behind it, and place it together into a system.
While other concepts were new and inspiring, and encourage me to rethink how we do things and experiment.
November 24, 2020
Having a system to run your business or build products is priceless.
Shape up describes how the people at Basecamp/37signals do it, and I must say, it speaks to me.
I've tried structuring my projects with the 12 week year, but that timespan is too long to keep my focus. Also 2 week sprints are too short to do anything meaningful.
Shape up fits right in the middle: 6 weeks
Feels about right!
One big thing is to also not plan a roadmap, just decide what is most meaningful for the next 6 weeks. And that doesn't have to mean that feature you planned at the start of the year.
I currently don't have a team, but when I do again, I'm going to implement this system.
Shape up describes how the people at Basecamp/37signals do it, and I must say, it speaks to me.
I've tried structuring my projects with the 12 week year, but that timespan is too long to keep my focus. Also 2 week sprints are too short to do anything meaningful.
Shape up fits right in the middle: 6 weeks
Feels about right!
One big thing is to also not plan a roadmap, just decide what is most meaningful for the next 6 weeks. And that doesn't have to mean that feature you planned at the start of the year.
I currently don't have a team, but when I do again, I'm going to implement this system.
January 12, 2020
Shape Up is a short but worthwhile read when it comes to critically assess your own software development processes. I don’t fully agree with all the points made, but would consider most of them true, helpful and valuable based on my personal experience.
If you have read other books from the Basecamp family, you might find the ideas redundant. But the advices given are mostly very actionable and can be applied (with various efforts).
It should help you in terms of prioritising and scoping work as well as prevent you from ending up in endless optimisation or bottomless backlogs.
If you have read other books from the Basecamp family, you might find the ideas redundant. But the advices given are mostly very actionable and can be applied (with various efforts).
It should help you in terms of prioritising and scoping work as well as prevent you from ending up in endless optimisation or bottomless backlogs.
May 18, 2021
Skim read it... 2.5 stars.
I wasn't fond of the tone of this book honestly. And the approach to bugs was odd to me. I was also curious to know how user testing fits into this methodology, but it didn't appear to be covered that I could see.
I wasn't fond of the tone of this book honestly. And the approach to bugs was odd to me. I was also curious to know how user testing fits into this methodology, but it didn't appear to be covered that I could see.
March 21, 2021
These are the types of books that I absolutely love reading. If I were to pick, I'd definitely want every technical book to be written the way Ryan Singer wrote this one. Straight to the point, no bullshit stories and poetic references, Case Studies that actually matter and short, so that you don't feel overwhelmed by the size of the content. It really was a pleasure to read.
On the system itself, I think it can be a life-changer to many companies and while sometimes you can't just implement it fully, you can learn a lot from it. The concepts are simple, battle-tested, actually developed for years, and just poured onto the paper in a well-shaped form. Some of the ideas are actually so good and universal, that you could even use it for your personal goal-planning & execution, which I'm going to try out.
Thank you Ryan for this great read!
On the system itself, I think it can be a life-changer to many companies and while sometimes you can't just implement it fully, you can learn a lot from it. The concepts are simple, battle-tested, actually developed for years, and just poured onto the paper in a well-shaped form. Some of the ideas are actually so good and universal, that you could even use it for your personal goal-planning & execution, which I'm going to try out.
Thank you Ryan for this great read!
October 27, 2020
A must read book for those who are working in Product Developoment. This is the kind of clarity you should have if you are building a product!
Big thanks to Ryan Singer for writing Shorthand for UI Designing back in 2009 - it's something I am following since then and has helped me a lot!
Big thanks to Ryan Singer for writing Shorthand for UI Designing back in 2009 - it's something I am following since then and has helped me a lot!
August 25, 2025
This book is written in a great language, like “We do things like this,” and “Here is why we think it’s right,” and “Here is how you can adapt it,” but it doesn’t say that it’s the only correct way of working.
Things are explained clearly, with enough level of detail and real examples.
I really recommend reading this book, even if you didn’t plan to switch to the Shape Up approach.
Things are explained clearly, with enough level of detail and real examples.
I really recommend reading this book, even if you didn’t plan to switch to the Shape Up approach.
August 25, 2021
Download the book here for free: https://basecamp.com/shapeup/shape-up...
Basecamp introduces us to their workflow that is neither Waterfall, Kanban or Scrum in this freely downloadable e-book for people working in software development. Here's my summary.
1. Six-week cycles.
Six weeks is long enough to build something meaningful start-to-finish and short enough that everyone can feel the deadline looming from the start, so they use the time wisely.
Our decisions are based on moving the product forward in the next six weeks, not micromanaging time. We don’t count hours or question how individual days are spent. We don’t have daily meetings. We don’t rethink our roadmap every two weeks.
2. Shaping the work
A small senior group works in parallel to the cycle teams. They define the key elements of a solution before we consider a project ready to bet on.
Instead of asking how much time it will take to do some work, we ask: How much time do we want to spend? How much is this idea worth? This is the task of shaping: narrowing down the problem and designing the outline of a solution that fits within the constraints of our appetite.
3. Making teams responsible
Third, we give full responsibility to a small integrated team of designers and programmers. They define their own tasks, make adjustments to the scope, and work together to build vertical slices of the product one at a time. This is completely different from other methodologies, where managers chop up the work and programmers act like ticket-takers.
Together, these concepts form a virtuous circle. When teams are more autonomous, senior people can spend less time managing them. With less time spent on management, senior people can shape up better projects. When projects are better shaped, teams have clearer boundaries and so can work more autonomously.
4. Targeting risk
This book is about the risk of getting stuck, the risk of getting bogged down with last quarter’s work, wasting time on unexpected problems, and not being free to do what you want to do tomorrow.
Shaping
Property 1: It’s rough
Everyone can tell by looking at it that it’s unfinished. They can see the open spaces where their contributions will go.
Property 2: It’s solved
The work isn’t specified down to individual tasks, but the overall solution is spelled out.
Property 3: It’s bounded
Lastly, shaped work indicates what not to do. There’s a specific appetite — the amount of time the team is allowed to spend on the project. Completing the project within that fixed amount of time requires limiting the scope and leaving specific things out.
Who shapes
Shaping is creative and integrative. It requires combining interface ideas with technical possibilities with business priorities. To do that you’ll need to either embody these skills as a generalist or collaborate with one or two other people.
You don’t need to be a programmer to shape, but you need to be technically literate. You should be able to judge what’s possible, what’s easy and what’s hard. Knowledge about how the system works will help you see opportunities or obstacles for implementing your idea.
It’s also strategic work. Setting the appetite and coming up with a solution requires you to be critical about the problem. What are we trying to solve? Why does it matter? What counts as success? Which customers are affected? What is the cost of doing this instead of something else?
We have two separate tracks: one for shaping, one for building. During any six week cycle, the teams are building work that’s been previously shaped and the shapers are working on what the teams might potentially build in a future cycle.
Steps to shaping
1. Set boundaries. First we figure out how much time the raw idea is worth and how to define the problem.
An appetite is completely different from an estimate. Estimates start with a design and end with a number. Appetites start with a number and end with a design. We use the appetite as a creative constraint on the design process.
When we have all three things — a raw idea, an appetite, and a narrow problem definition — we’re ready to move to the next step and define the elements of a solution.
2. Rough out the elements. The output of this step is an idea that solves the problem within the appetite but without all the fine details worked out.
First, we need to have the right people—or nobody—in the room. Either we’re working alone or with a trusted partner who can keep pace with us.
Second, we need to avoid the wrong level of detail in the drawings and sketches.
2A Breadboarding
We borrow a concept from electrical engineering to help us design at the right level of abstraction. A breadboard is an electrical engineering prototype that has all the components and wiring of a real device but no industrial design.
There are three basic things we’ll draw:
2A-1. Places: These are things you can navigate to, like screens, dialogs, or menus that pop up.
2A-2.Affordances: These are things the user can act on, like buttons and fields. We consider interface copy to be an affordance, too. Reading it is an act that gives the user information for subsequent actions.
2A-3. Connection lines: These show how the affordances take the user from place to place.
2B Fat marker sketches
It may seem a little silly to call fat marker sketches a technique or a tool. The reason for calling them out is we too easily skip ahead to the wrong level of fidelity. Giving this rough early stage a name and using a specific tool for it helps us to segment our own creative process and make sure we aren’t jumping ahead to detail a specific idea when we haven’t surveyed the field enough.
3. Address risks and rabbit holes. We amend the solution, cut things out of it, or specify details at certain tricky spots to prevent the team from getting stuck or wasting time.
* Does this require new technical work we’ve never done before?
* Are we making assumptions about how the parts fit together?
* Are we assuming a design solution exists that we couldn’t come up with ourselves?
* Is there a hard decision we should settle in advance so it doesn’t trip up the team?
4. Write the pitch. The pitch summarizes the problem, constraints, solution, rabbit holes, and limitations. The pitch goes to the betting table for consideration. If the project gets chosen, the pitch can be re-used at kick-off to explain the project to the team.
There are five ingredients that we always want to include in a pitch:
4-1. Problem — The raw idea, a use case, or something we’ve seen that motivates us to work on this. It’s critical to always present both a problem and a solution together. It sounds like an obvious point but it’s surprising how often teams, our own included, jump to a solution with the assumption that it’s obvious why it’s a good idea to build this thing.
4-2. Appetite — How much time we want to spend and how that constrains the solution
4-3. Solution — The core elements we came up with, presented in a form that’s easy for people to immediately understand
4-4. Rabbit holes — Details about the solution worth calling out to avoid problems
4-5. No-gos — Anything specifically excluded from the concept: functionality or use cases we intentionally aren’t covering to fit the appetite or make the problem tractable
We prefer asynchronous communication by default and escalate to real-time only when necessary. This gives everyone the maximum amount of time under their own control for doing real work. That means the first step for presenting a pitch is posting the write-up with all the ingredients above somewhere that stakeholders can read it on their own time.
Beware the simple question: “Is this possible?” In software, everything is possible but nothing is free. We want to find out if it’s possible within the appetite we’re shaping for. Instead of asking “is it possible to do X?” ask “is X possible in 6-weeks?” That’s a very different question.
No backlogs
Backlogs are a big weight we don’t need to carry. Dozens and eventually hundreds of tasks pile up that we all know we’ll never have time for. The growing pile gives us a feeling like we’re always behind even though we’re not. Just because somebody thought some idea was important a quarter ago doesn’t mean we need to keep looking at it again and again.
Backlogs are big time wasters too. The time spent constantly reviewing, grooming and organizing old ideas prevents everyone from moving forward on the timely projects that really matter right now.
A few potential bets
So what do we do instead? Before each six-week cycle, we hold a betting table where stakeholders decide what to do in the next cycle.
Nothing else is on the table. There’s no giant list of ideas to review. There’s no time spent grooming a backlog of old ideas. There are just a few well-shaped, risk-reduced options to review. The pitches are potential bets.
With just a few options and a six-week long cycle, these meetings are infrequent, short, and intensely productive.
Anyone who wants to advocate for it again simply tracks it independently — their own way — and then lobbies for it six weeks later. Everyone can still track pitches, bugs, requests, or things they want to do independently without a central backlog. This way the conversation is always fresh. Anything brought back is brought back with a context, by a person, with a purpose. Everything is relevant, timely, and of the moment.
Six-week cycles
Some companies use two-week cycles (aka “sprints”). We learned that two weeks is too short to get anything meaningful done. Worse than that, two-week cycles are extremely costly due to the planning overhead. The amount of work you get out of two weeks isn’t worth the collective hours around the table to “sprint plan” or the opportunity cost of breaking everyone’s momentum to re-group.
Cool-down
If we were to run six-week cycles back to back, there wouldn’t be any time to breathe and think about what’s next. The end of a cycle is the worst time to meet and plan because everybody is too busy finishing projects and making last-minute decisions in order to ship on time.
Therefore, after each six-week cycle, we schedule two weeks for cool-down. This is a period with no scheduled work where we can breathe, meet as needed, and consider what to do next.
During cool-down, programmers and designers on project teams are free to work on whatever they want. After working hard to ship their six-week projects, they enjoy having time that’s under their control. They use it to fix bugs, explore new ideas, or try out new technical possibilities.
Cleanup mode
In the final phase before launching the new product, we throw all structure out the window. We call this cleanup mode. It’s a free-for-all.
Cleanup shouldn’t last longer than two cycles.
1. There’s no shaping. Leadership stands at the helm throughout the cycle, calling attention to what’s important and cutting away distractions.
2. There aren’t clear team boundaries. Everyone jumps in to help however they can.
3. Work is “shipped” (merged to the main codebase) continuously in as small bites as possible.
We don’t start by assigning tasks to anyone. Nobody plays the role of the “taskmaster” or the “architect” who splits the project up into pieces for other people to execute.
Every piece of work has two phases. First there’s the uphill phase of figuring out what our approach is and what we’re going to do. Then, once we can see all the work involved, there’s the downhill phase of execution.
Basecamp introduces us to their workflow that is neither Waterfall, Kanban or Scrum in this freely downloadable e-book for people working in software development. Here's my summary.
1. Six-week cycles.
Six weeks is long enough to build something meaningful start-to-finish and short enough that everyone can feel the deadline looming from the start, so they use the time wisely.
Our decisions are based on moving the product forward in the next six weeks, not micromanaging time. We don’t count hours or question how individual days are spent. We don’t have daily meetings. We don’t rethink our roadmap every two weeks.
2. Shaping the work
A small senior group works in parallel to the cycle teams. They define the key elements of a solution before we consider a project ready to bet on.
Instead of asking how much time it will take to do some work, we ask: How much time do we want to spend? How much is this idea worth? This is the task of shaping: narrowing down the problem and designing the outline of a solution that fits within the constraints of our appetite.
3. Making teams responsible
Third, we give full responsibility to a small integrated team of designers and programmers. They define their own tasks, make adjustments to the scope, and work together to build vertical slices of the product one at a time. This is completely different from other methodologies, where managers chop up the work and programmers act like ticket-takers.
Together, these concepts form a virtuous circle. When teams are more autonomous, senior people can spend less time managing them. With less time spent on management, senior people can shape up better projects. When projects are better shaped, teams have clearer boundaries and so can work more autonomously.
4. Targeting risk
This book is about the risk of getting stuck, the risk of getting bogged down with last quarter’s work, wasting time on unexpected problems, and not being free to do what you want to do tomorrow.
Shaping
Property 1: It’s rough
Everyone can tell by looking at it that it’s unfinished. They can see the open spaces where their contributions will go.
Property 2: It’s solved
The work isn’t specified down to individual tasks, but the overall solution is spelled out.
Property 3: It’s bounded
Lastly, shaped work indicates what not to do. There’s a specific appetite — the amount of time the team is allowed to spend on the project. Completing the project within that fixed amount of time requires limiting the scope and leaving specific things out.
Who shapes
Shaping is creative and integrative. It requires combining interface ideas with technical possibilities with business priorities. To do that you’ll need to either embody these skills as a generalist or collaborate with one or two other people.
You don’t need to be a programmer to shape, but you need to be technically literate. You should be able to judge what’s possible, what’s easy and what’s hard. Knowledge about how the system works will help you see opportunities or obstacles for implementing your idea.
It’s also strategic work. Setting the appetite and coming up with a solution requires you to be critical about the problem. What are we trying to solve? Why does it matter? What counts as success? Which customers are affected? What is the cost of doing this instead of something else?
We have two separate tracks: one for shaping, one for building. During any six week cycle, the teams are building work that’s been previously shaped and the shapers are working on what the teams might potentially build in a future cycle.
Steps to shaping
1. Set boundaries. First we figure out how much time the raw idea is worth and how to define the problem.
An appetite is completely different from an estimate. Estimates start with a design and end with a number. Appetites start with a number and end with a design. We use the appetite as a creative constraint on the design process.
When we have all three things — a raw idea, an appetite, and a narrow problem definition — we’re ready to move to the next step and define the elements of a solution.
2. Rough out the elements. The output of this step is an idea that solves the problem within the appetite but without all the fine details worked out.
First, we need to have the right people—or nobody—in the room. Either we’re working alone or with a trusted partner who can keep pace with us.
Second, we need to avoid the wrong level of detail in the drawings and sketches.
2A Breadboarding
We borrow a concept from electrical engineering to help us design at the right level of abstraction. A breadboard is an electrical engineering prototype that has all the components and wiring of a real device but no industrial design.
There are three basic things we’ll draw:
2A-1. Places: These are things you can navigate to, like screens, dialogs, or menus that pop up.
2A-2.Affordances: These are things the user can act on, like buttons and fields. We consider interface copy to be an affordance, too. Reading it is an act that gives the user information for subsequent actions.
2A-3. Connection lines: These show how the affordances take the user from place to place.
2B Fat marker sketches
It may seem a little silly to call fat marker sketches a technique or a tool. The reason for calling them out is we too easily skip ahead to the wrong level of fidelity. Giving this rough early stage a name and using a specific tool for it helps us to segment our own creative process and make sure we aren’t jumping ahead to detail a specific idea when we haven’t surveyed the field enough.
3. Address risks and rabbit holes. We amend the solution, cut things out of it, or specify details at certain tricky spots to prevent the team from getting stuck or wasting time.
* Does this require new technical work we’ve never done before?
* Are we making assumptions about how the parts fit together?
* Are we assuming a design solution exists that we couldn’t come up with ourselves?
* Is there a hard decision we should settle in advance so it doesn’t trip up the team?
4. Write the pitch. The pitch summarizes the problem, constraints, solution, rabbit holes, and limitations. The pitch goes to the betting table for consideration. If the project gets chosen, the pitch can be re-used at kick-off to explain the project to the team.
There are five ingredients that we always want to include in a pitch:
4-1. Problem — The raw idea, a use case, or something we’ve seen that motivates us to work on this. It’s critical to always present both a problem and a solution together. It sounds like an obvious point but it’s surprising how often teams, our own included, jump to a solution with the assumption that it’s obvious why it’s a good idea to build this thing.
4-2. Appetite — How much time we want to spend and how that constrains the solution
4-3. Solution — The core elements we came up with, presented in a form that’s easy for people to immediately understand
4-4. Rabbit holes — Details about the solution worth calling out to avoid problems
4-5. No-gos — Anything specifically excluded from the concept: functionality or use cases we intentionally aren’t covering to fit the appetite or make the problem tractable
We prefer asynchronous communication by default and escalate to real-time only when necessary. This gives everyone the maximum amount of time under their own control for doing real work. That means the first step for presenting a pitch is posting the write-up with all the ingredients above somewhere that stakeholders can read it on their own time.
Beware the simple question: “Is this possible?” In software, everything is possible but nothing is free. We want to find out if it’s possible within the appetite we’re shaping for. Instead of asking “is it possible to do X?” ask “is X possible in 6-weeks?” That’s a very different question.
No backlogs
Backlogs are a big weight we don’t need to carry. Dozens and eventually hundreds of tasks pile up that we all know we’ll never have time for. The growing pile gives us a feeling like we’re always behind even though we’re not. Just because somebody thought some idea was important a quarter ago doesn’t mean we need to keep looking at it again and again.
Backlogs are big time wasters too. The time spent constantly reviewing, grooming and organizing old ideas prevents everyone from moving forward on the timely projects that really matter right now.
A few potential bets
So what do we do instead? Before each six-week cycle, we hold a betting table where stakeholders decide what to do in the next cycle.
Nothing else is on the table. There’s no giant list of ideas to review. There’s no time spent grooming a backlog of old ideas. There are just a few well-shaped, risk-reduced options to review. The pitches are potential bets.
With just a few options and a six-week long cycle, these meetings are infrequent, short, and intensely productive.
Anyone who wants to advocate for it again simply tracks it independently — their own way — and then lobbies for it six weeks later. Everyone can still track pitches, bugs, requests, or things they want to do independently without a central backlog. This way the conversation is always fresh. Anything brought back is brought back with a context, by a person, with a purpose. Everything is relevant, timely, and of the moment.
Six-week cycles
Some companies use two-week cycles (aka “sprints”). We learned that two weeks is too short to get anything meaningful done. Worse than that, two-week cycles are extremely costly due to the planning overhead. The amount of work you get out of two weeks isn’t worth the collective hours around the table to “sprint plan” or the opportunity cost of breaking everyone’s momentum to re-group.
Cool-down
If we were to run six-week cycles back to back, there wouldn’t be any time to breathe and think about what’s next. The end of a cycle is the worst time to meet and plan because everybody is too busy finishing projects and making last-minute decisions in order to ship on time.
Therefore, after each six-week cycle, we schedule two weeks for cool-down. This is a period with no scheduled work where we can breathe, meet as needed, and consider what to do next.
During cool-down, programmers and designers on project teams are free to work on whatever they want. After working hard to ship their six-week projects, they enjoy having time that’s under their control. They use it to fix bugs, explore new ideas, or try out new technical possibilities.
Cleanup mode
In the final phase before launching the new product, we throw all structure out the window. We call this cleanup mode. It’s a free-for-all.
Cleanup shouldn’t last longer than two cycles.
1. There’s no shaping. Leadership stands at the helm throughout the cycle, calling attention to what’s important and cutting away distractions.
2. There aren’t clear team boundaries. Everyone jumps in to help however they can.
3. Work is “shipped” (merged to the main codebase) continuously in as small bites as possible.
We don’t start by assigning tasks to anyone. Nobody plays the role of the “taskmaster” or the “architect” who splits the project up into pieces for other people to execute.
Every piece of work has two phases. First there’s the uphill phase of figuring out what our approach is and what we’re going to do. Then, once we can see all the work involved, there’s the downhill phase of execution.
August 5, 2021
Very insightful to learn how a no-100% agile work setup would be able to work in product development.
Read
May 13, 2021This book is interesting, but even so I failed trying to read it/procasinated a lot.
I think the better way to read it is as a reference book. Parts of this book are relevant to my current job, and so bit by bit I completed it.
Anytime I needed an answer this book can give, I ended up reading it + this approach was extremely helpful + interesting.
I think the better way to read it is as a reference book. Parts of this book are relevant to my current job, and so bit by bit I completed it.
Anytime I needed an answer this book can give, I ended up reading it + this approach was extremely helpful + interesting.
August 6, 2019
Another great book by the people of Basecamp.
The Shape Up method:
- Shaped versus unshaped work
- Designing at the right level of abstraction
- Setting appetites instead of estimates
- Concepting with breadboards and fat marker sketches
- Making deliberate commitments—bets— instead of feeding the machine
- Choosing the right cycle length (six weeks)
- A cool-down period between cycles
- Breaking projects apart into scopes
- Downhill versus uphill work and communicating about unknowns
- Scope hammering to separate must-haves from nice-to-haves
The Shape Up method:
- Shaped versus unshaped work
- Designing at the right level of abstraction
- Setting appetites instead of estimates
- Concepting with breadboards and fat marker sketches
- Making deliberate commitments—bets— instead of feeding the machine
- Choosing the right cycle length (six weeks)
- A cool-down period between cycles
- Breaking projects apart into scopes
- Downhill versus uphill work and communicating about unknowns
- Scope hammering to separate must-haves from nice-to-haves
December 26, 2024
1. “不做工作，做结果”：本书提出的核心思想之一是，从任务驱动向目标驱动转变。作者强调，团队和组织不应只是完成一项项的工作，而要聚焦于“结果”——即解决实际问题和创造实际价值。这种方法通过减少不必要的会议、报告和决策流程，强调精简、直接和高效的工作方式。
2. 高效的周期性管理：书中提出了四阶段工作周期（设计、开发、冷却、反思）的模式，强调团队在高强度工作后需要一个冷却和反思期。这与常规项目管理方法中的“持续迭代”不同，冷却阶段的引入意在确保长期生产力，并防止团队倦怠。
3. “形状（Shape）”设计：与传统的“需求定义”或“功能清单”相比，作者倡导先“塑造”（shape）问题，而非匆忙开始开发。这一“塑形”过程的目的是确保团队在开始工作之前，已经明确了核心问题和解决方案的大体框架，并避免陷入无尽的功能细化。
4. 自我驱动的团队文化：本书强调了团队成员自主性的重要性。通过增强自主权和自我驱动力，团队能够减少依赖外部压力，持续保持高效和创新。这种文化的核心在于赋权和自我管理，团队成员可以在没有过多外部干扰的情况下做出决策和推进工作。
5. 高质量交付与迭代优化：在交付后，持续的迭代和优化被视为成功的关键。通过利用反馈循环和数据驱动决策，团队可以根据实际需求和市场变化不断调整和改进产品和服务，确保项目交付后的长期适应性和成功。
启示：
1. 聚焦目标而非任务：工作不应仅仅围绕“完成任务”而展开，而应聚焦于解决实际问题并创造有价值的结果。团队需要减少冗余的工作流程，注重效率和直接影响。
2. 设计阶段的重要性：在启动项目之前，充分的“塑形”工作比直接进入开发更加重要。团队应确保理解问题的本质和核心目标，而不是仅仅依赖于客户的需求清单。这样可以避免开发过程中对功能细节的过度追求，保证团队专注于高效解决核心问题。
3. 自我驱动的工作环境：通过提供适当的自主权，团队成员能够在没有外部干扰的情况下发挥最大潜力。建立一个自我驱动的团队文化，能够激发团队成员的内在动机，提高长期的生产力和创新能力。
4. 冷却和反思阶段的必要性：设定周期性冷却和反思阶段，使团队可以从高强度的工作中恢复并进行调整，避免倦怠，保持长期的工作效率。反思不仅能帮助团队识别问题，还能为下一个工作周期提供有价值的见解。
5. 持续优化和数据驱动决策：项目的交付后，持续优化和根据实际反馈调整策略是至关重要的。通过收集用户反馈和分析数据，团队能够保持产品和服务的竞争力，并确保团队的长远发展。
《Shape Up》提出了一种全新的项目管理方法，强调高效的工作周期、团队自主性以及持续的优化迭代。这种方法挑战了传统的需求分析、任务驱动型工���方式，倡导更加灵活和结果导向的工作模式。通过合理安排工作周期、优化交付流程，并提供团队更多的自主权，这本书为如何在复杂的工作环境中高效交付提供了具有启发性的解决方案。
然而，这种方法也存在一定的挑战，尤其是在如何平衡自由度与控制、长期目标与短期任务之间的关系。对于不同团队和行业的适用性需要进一步探讨和验证。
2. 高效的周期性管理：书中提出了四阶段工作周期（设计、开发、冷却、反思）的模式，强调团队在高强度工作后需要一个冷却和反思期。这与常规项目管理方法中的“持续迭代”不同，冷却阶段的引入意在确保长期生产力，并防止团队倦怠。
3. “形状（Shape）”设计：与传统的“需求定义”或“功能清单”相比，作者倡导先“塑造”（shape）问题，而非匆忙开始开发。这一“塑形”过程的目的是确保团队在开始工作之前，已经明确了核心问题和解决方案的大体框架，并避免陷入无尽的功能细化。
4. 自我驱动的团队文化：本书强调了团队成员自主性的重要性。通过增强自主权和自我驱动力，团队能够减少依赖外部压力，持续保持高效和创新。这种文化的核心在于赋权和自我管理，团队成员可以在没有过多外部干扰的情况下做出决策和推进工作。
5. 高质量交付与迭代优化：在交付后，持续的迭代和优化被视为成功的关键。通过利用反馈循环和数据驱动决策，团队可以根据实际需求和市场变化不断调整和改进产品和服务，确保项目交付后的长期适应性和成功。
启示：
1. 聚焦目标而非任务：工作不应仅仅围绕“完成任务”而展开，而应聚焦于解决实际问题并创造有价值的结果。团队需要减少冗余的工作流程，注重效率和直接影响。
2. 设计阶段的重要性：在启动项目之前，充分的“塑形”工作比直接进入开发更加重要。团队应确保理解问题的本质和核心目标，而不是仅仅依赖于客户的需求清单。这样可以避免开发过程中对功能细节的过度追求，保证团队专注于高效解决核心问题。
3. 自我驱动的工作环境：通过提供适当的自主权，团队成员能够在没有外部干扰的情况下发挥最大潜力。建立一个自我驱动的团队文化，能够激发团队成员的内在动机，提高长期的生产力和创新能力。
4. 冷却和反思阶段的必要性：设定周期性冷却和反思阶段，使团队可以从高强度的工作中恢复并进行调整，避免倦怠，保持长期的工作效率。反思不仅能帮助团队识别问题，还能为下一个工作周期提供有价值的见解。
5. 持续优化和数据驱动决策：项目的交付后，持续优化和根据实际反馈调整策略是至关重要的。通过收集用户反馈和分析数据，团队能够保持产品和服务的竞争力，并确保团队的长远发展。
《Shape Up》提出了一种全新的项目管理方法，强调高效的工作周期、团队自主性以及持续的优化迭代。这种方法挑战了传统的需求分析、任务驱动型工���方式，倡导更加灵活和结果导向的工作模式。通过合理安排工作周期、优化交付流程，并提供团队更多的自主权，这本书为如何在复杂的工作环境中高效交付提供了具有启发性的解决方案。
然而，这种方法也存在一定的挑战，尤其是在如何平衡自由度与控制、长期目标与短期任务之间的关系。对于不同团队和行业的适用性需要进一步探讨和验证。
November 17, 2020
This was amazing. Finally I read a book about product development that is NO bullshit, firmly grounded in the firms actual practices based on trial and error, and is based on the most important aspect of development - shipping the work.
Key takeaways for me here were:
- Detailed and case study based approach to designing with abstraction (fat markers / breadboarding). Very clearly articulated the how and why ‘shaping’ in this way early on will be beneficial later.
- Separating work into scopes, and getting work done ‘vertically’ instead of ‘horizontally’. This is surprisingly similar to Stanislavsky’s ‘chunking’ approach to breaking down text.
The idea here being to clearly separate a job into achievable chunks, and get the chunks done on the design and code end at the same time, so the project is always running on momentum.
A lot of lessons in this book that make so much sense, but I had to be told.
Just about to start my first 6 week cycle on a new project - will report back!
Yahoo
Key takeaways for me here were:
- Detailed and case study based approach to designing with abstraction (fat markers / breadboarding). Very clearly articulated the how and why ‘shaping’ in this way early on will be beneficial later.
- Separating work into scopes, and getting work done ‘vertically’ instead of ‘horizontally’. This is surprisingly similar to Stanislavsky’s ‘chunking’ approach to breaking down text.
The idea here being to clearly separate a job into achievable chunks, and get the chunks done on the design and code end at the same time, so the project is always running on momentum.
A lot of lessons in this book that make so much sense, but I had to be told.
Just about to start my first 6 week cycle on a new project - will report back!
Yahoo
April 8, 2021
Totally not worth reading in XXI century.
This book looks like a proposal of a transition phase between a "waterfall" and an "agile". Maybe it could be valuable ~20 years ago but not today:
6 weeks cycles - because this was picked as a reasonable time a valuable thing can be done. 1-2 weeks is too less because of the meetings overhead. But instead a Basecamp proposes 2 weeks "cool down" for e.g. to fix bugs. 1 day meeting in 2 weeks sprint is bad but 2 weeks after 6 weeks of development is ok?
"Shaping" is just a tutorial "how to do grooming".
No backlog to prevent rethinking the same ideas all over again? In a pull systems like Kanban, this never happens as items are pulled when needed. Tasks need to be ready for development and there is no risk to groom the same task many times.
QA comes in the end of a cycle?
All of the above are against Continuous Integration and Continuous Delivery principles This brings risk in many areas: for a company to be out of the market, it lowers the responsiveness of the product to a market changes, customer demands, fixing bugs etc.
And remember - You need an iPad! It's mentioned in the book many times. It looks like the only tablet device to draw sketches is obviously an iPad! This book is not for me then - I don't have an iPad.
This book looks like a proposal of a transition phase between a "waterfall" and an "agile". Maybe it could be valuable ~20 years ago but not today:
6 weeks cycles - because this was picked as a reasonable time a valuable thing can be done. 1-2 weeks is too less because of the meetings overhead. But instead a Basecamp proposes 2 weeks "cool down" for e.g. to fix bugs. 1 day meeting in 2 weeks sprint is bad but 2 weeks after 6 weeks of development is ok?
"Shaping" is just a tutorial "how to do grooming".
No backlog to prevent rethinking the same ideas all over again? In a pull systems like Kanban, this never happens as items are pulled when needed. Tasks need to be ready for development and there is no risk to groom the same task many times.
QA comes in the end of a cycle?
All of the above are against Continuous Integration and Continuous Delivery principles This brings risk in many areas: for a company to be out of the market, it lowers the responsiveness of the product to a market changes, customer demands, fixing bugs etc.
And remember - You need an iPad! It's mentioned in the book many times. It looks like the only tablet device to draw sketches is obviously an iPad! This book is not for me then - I don't have an iPad.
This entire review has been hidden because of spoilers.
February 6, 2020
I'm a big fan of Basecamp and whatever they want to write. I love the work they've done to think clearly and edit fully. This book is ideal for managers of software teams and (like Rework) is remarkably short and simply written. You can easily fly through it in a week, and get a lot of valuable ideas out of it.
For me some of the key takeaways were about
- the two parallel tracks of shaping (managers) and doing (dev teams)
- shaped work means a rough solution with clear scope boundaries
- use 6 week cycles and 2 week cool downs
- get your hands off the team and give them space to do the work
- 6 weeks means 6 weeks. If you don't ship, you quit the work (although I suspect this doesn't work as well with spec work like ours...)
- for teams! Start in the middle. Solve the riskiest part first and demo it to gain momentum
- you shouldn't work on raw ideas. This forces teams to do both the shaping and the working. Respond to all raw ideas (yes, including feedback from customers) with "hm, that's interesting."
For me some of the key takeaways were about
- the two parallel tracks of shaping (managers) and doing (dev teams)
- shaped work means a rough solution with clear scope boundaries
- use 6 week cycles and 2 week cool downs
- get your hands off the team and give them space to do the work
- 6 weeks means 6 weeks. If you don't ship, you quit the work (although I suspect this doesn't work as well with spec work like ours...)
- for teams! Start in the middle. Solve the riskiest part first and demo it to gain momentum
- you shouldn't work on raw ideas. This forces teams to do both the shaping and the working. Respond to all raw ideas (yes, including feedback from customers) with "hm, that's interesting."
March 16, 2024
Shape Up" by Ryan Singer came highly recommended by a colleague, sparking my curiosity with its promise of a novel approach to product development. The book stands out for its readability and the clarity of its illustrative content, making complex methodologies accessible to its readers. Despite its ease of understanding, "Shape Up" introduces a curious dynamic, positioning its methodology in contrast to traditional Agile practices. Singer seems to repurpose the agile philosophy under new terminology, presenting Basecamp's work style as a groundbreaking alternative. This perspective felt somewhat peculiar, considering Agile's inherent adaptability.
Nonetheless, "Shape Up" presents compelling arguments for smaller, VC-independent companies. Singer champions small teams and sustainable work styles, advocating for well-defined project scopes that avoid being overly prescriptive. The book's emphasis on "fat marker sketches" as a starting point for projects is particularly commendable, merging clarity with creative freedom effectively.
However, despite its practical advice and innovative strategies for team management, "Shape Up" may not be the first book I'd recommend to those eager to master software team leadership. Its strengths lie in offering a practical guide for smaller teams seeking a balanced approach to project management, albeit in a manner that closely echoes Agile's foundational principles. Best suited for leaders and members of small to mid-sized companies, "Shape Up" provides valuable insights into creating a sustainable, responsibility-empowered team environment, even if it does so by rebranding familiar concepts under a new name.
Nonetheless, "Shape Up" presents compelling arguments for smaller, VC-independent companies. Singer champions small teams and sustainable work styles, advocating for well-defined project scopes that avoid being overly prescriptive. The book's emphasis on "fat marker sketches" as a starting point for projects is particularly commendable, merging clarity with creative freedom effectively.
However, despite its practical advice and innovative strategies for team management, "Shape Up" may not be the first book I'd recommend to those eager to master software team leadership. Its strengths lie in offering a practical guide for smaller teams seeking a balanced approach to project management, albeit in a manner that closely echoes Agile's foundational principles. Best suited for leaders and members of small to mid-sized companies, "Shape Up" provides valuable insights into creating a sustainable, responsibility-empowered team environment, even if it does so by rebranding familiar concepts under a new name.
February 10, 2021
It was the perfect time to pick this up since we are in the process of improving our processes and see what works best for us.
There were a lot of learnings/concepts that I could scale down to our shorter release cycle and much smaller team. Though I did not completely agree with all the solutions mentioned in the book, it did a good job at pointing out the problems and gave me anchor points around which I can shape my own solutions.
The concept of hill charts felt very out of place to be honest. I feel it is too much work for the team to constantly map and update their progress on this completely new representation format. Also their concept of getting all the scopes/tasks uphill contradicts with their suggestions of building vertical slices one at a time. Maybe this whole section was just included to try and sell basecamp to the readers 🤷♂️
Overall it did not feel like a waste of time and there were definitely many important takeaways for me.
There were a lot of learnings/concepts that I could scale down to our shorter release cycle and much smaller team. Though I did not completely agree with all the solutions mentioned in the book, it did a good job at pointing out the problems and gave me anchor points around which I can shape my own solutions.
The concept of hill charts felt very out of place to be honest. I feel it is too much work for the team to constantly map and update their progress on this completely new representation format. Also their concept of getting all the scopes/tasks uphill contradicts with their suggestions of building vertical slices one at a time. Maybe this whole section was just included to try and sell basecamp to the readers 🤷♂️
Overall it did not feel like a waste of time and there were definitely many important takeaways for me.
September 2, 2023
A refreshing read in times where Scrum and Agile™ is still dominating the landscape, often at the cost of sucking most individual contributors involved free from any excitement or motivation left. Always great in theory. Never really works in practice.
Shape Up describes an alternative way of planning and shipping software. The best alternative for everyone? Probably not. But at least an alternative, helping us break free from the Agile™ demon, and consider alternative ways of doing things.
One of the most valuable reads anyone involved in software development and technical leadership can read in 2023. It'll give you inspiration and practical ideas to consider rather than following a script you have slowly come to despise. Hand it out to your manager and colleagues for bonus points.
Shape Up describes an alternative way of planning and shipping software. The best alternative for everyone? Probably not. But at least an alternative, helping us break free from the Agile™ demon, and consider alternative ways of doing things.
One of the most valuable reads anyone involved in software development and technical leadership can read in 2023. It'll give you inspiration and practical ideas to consider rather than following a script you have slowly come to despise. Hand it out to your manager and colleagues for bonus points.
Displaying 1 - 30 of 315 reviews