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."
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.
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.”
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).
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.
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.
Очень интересная концепция шейпинга - между раздачей общих указаний по которым непонятно что конкретно делать и расписыванием задач детально, что сильно ограничивает возможности исполнителей. Правильный уровень детализации задач - полезная компетенция для менеджера
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.
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.
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.
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.
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.
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 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.
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 :)
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.
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.
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.
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.
This 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.
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
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
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 entire review has been hidden because of spoilers.
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."
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.
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.
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.
This puts together a lot of ideas you probably have when building a project. Some things may sound obvious, but here you can see them well organized and in action. I'm not sure if the same process will work for other kind of projects/companies, some times feels very coupled to bootcamp (they even use their product in the examples), but I guess is expected.
Three and a half stars maybe? The general framework of taking an idea from “raw idea” to “shaped idea” to “pitch” to committed work was useful and interesting, as was the discussion of how best to articulate a project at sufficient granularity while leaving room for designers and devs to do their jobs.