「Shape Up」を 2,024 年 02 月 17 日に読んだ。
目次
メモ
Foreword by Jason Fried
Over the last few years, there’s been a heightened curiosity about how we work at Basecamp.
People often ask us how we get so much done so quickly at such a high level of quality with such a small team.
And how we keep our teams together for years and years.
For one, we’re not into waterfall or agile or scrum.
For two, we don’t line walls with Post-it notes.
For three, 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.
No backlogs, no Kanban, no velocity tracking, none of that.
We have an entirely different approach.
One developed in isolation over nearly 15 years of constant trial and error, taking note, iterating, honing in, and polishing up.
We’ve shaped our own way.
Blog posts, workshops, and occasional conference talks have provided glimpses of our own unique process, but we’ve never laid it bare for all to see.
This book does just that.
Now that our process is fully formed, documented, and ready to go, we’re here to share it with all those curious enough to listen to a new way of doing things.
Explorers, pioneers, those who don’t care what everyone else is doing.
Those who want to work better than the rest.
Don’t think of this as a book.
Think of it as a flashlight.
You and your team have fumbled around in the dark long enough.
Now you’ve got something bright and powerful to help you find a new way.
Acknowledgements
Jason Fried and David Heinemeier Hansson, Basecamp’s founders, planted many of the seeds for this book.
It is informed by their values, Basecamp’s culture, and fifteen years of collaborative trial-and-error.
Introduction
From the first prototypes in July 2003 to launch in February 2004, David only worked ten hours a week.
We knew we wouldn’t get anywhere with those ten hours of programming unless we used them very deliberately.
Our intense focus on “hammering” the scope to fit within a given time budget was born under these constraints.
Principles of Shaping
Wireframes are too concrete
When design leaders go straight to wireframes or high-fidelity mockups, they define too much detail too early.
This leaves designers no room for creativity.
One friend put it this way:
I’ll give a wireframe to my designer, and then I’m saying to her:
“I know you’re looking at this, but that’s not what I want you to design. I want you to re-think it!”
It’s hard to do that when you’re giving them this concrete thing.
Over-specifying the design also leads to estimation errors.
Counterintuitive as it may seem, the more specific the work is, the harder it can be to estimate.
That’s because making the interface just so can require solving hidden complexities and implementation details that weren’t visible in the mockup.
When the scope isn’t variable, the team can’t reconsider a design decision that is turning out to cost more than it’s worth.
Property 1: It’s rough
Work in the shaping stage is rough.
Everyone can tell by looking at it that it’s unfinished.
They can see the open spaces where their contributions will go.
Work that’s too fine, too early commits everyone to the wrong details.
Designers and programmers need room to apply their own judgement and expertise when they roll up their sleeves and discover all the real trade-offs that emerge.
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.
Shaping is primarily design work.
The shaped concept is an interaction design viewed from the user’s perspective.
It defines what the feature does, how it works, and where it fits into existing flows.
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.
Set Boundaries
“Good” is relative
There’s no absolute definition of “the best” solution.
The best is relative to your constraints.
Without a time limit, there’s always a better version.
The ultimate meal might be a ten course dinner.
But when you’re hungry and in a hurry, a hot dog is perfect.
The amount of time we set for our appetite is going to lead us to different solutions.
We could model a whole set of database columns in the fancy version, or just provide a flat textarea in the simple version.
We could redesign the main landing page to accommodate a new feature, or we could push it back to a screen with fewer design constraints.
We can only judge what is a “good” solution in the context of how much time we want to spend and how important it is.
Responding to raw ideas
Our default response to any idea that comes up should be: “Interesting. Maybe some day.”
In other words, a very soft “no” that leaves all our options open.
We don’t put it in a backlog.
We give it space so we can learn whether it’s really important and what it might entail.
It’s too early to say “yes” or “no” on first contact.
Even if we’re excited about it, we shouldn’t make a commitment that we don’t yet understand.
We need to do work on the idea before it’s shaped enough to bet resources on.
If we always say “yes” to incoming requests we’ll end up with a giant pile of work that only grows.
It’s important to keep a cool manner and a bit of a poker face.
We don’t want to shut down an idea that we don’t understand.
New information might come in tomorrow that makes us see it differently.
On the other hand, showing too much enthusiasm right away can set expectations that this thing is going to happen.
We may not be able to commit to it once we’ve put it into context with everything else we want to do.
Risks and Rabbit Holes
Cut back
There may be parts of the solution we got excited about during the sketching phase that aren’t really necessary.
When we designed the To-Do Groups feature, we thought it would be great to color-code groups.
No doubt the page would look more interesting with color-coded group labels, and the feature might be more useful too.
But we decided to flag this as unnecessary and cut it from the core of the project.
We could mention it to the team as a nice-to-have, but everyone should start from the assumption that the feature is valuable without it.
Write the Pitch
Ingredient 5. No Gos
Lastly if there’s anything we’re not doing in this concept, it’s good to mention it here.
In the case of the Payment Form project, the team decided up front that they wouldn’t allow any kind of WYSIWYG editing of the form.
Users would only be able to provide a logo and customize the header text on a separate “customize” page.
WYSIWYG might be better in some peoples’ eyes, but given the appetite it was important to mark this as a no-go.
Bets, Not Backlogs
Important ideas come back
It’s easy to overvalue ideas.
The truth is, ideas are cheap.
They come up all the time and accumulate into big piles.
Really important ideas will come back to you.
When’s the last time you forgot a really great, inspiring idea?
And if it’s not that interesting—maybe a bug that customers are running into from time to time—it’ll come back to your attention when a customer complains again or a new customer hits it.
If you hear it once and never again, maybe it wasn’t really a problem.
And if you keep hearing about it, you’ll be motivated to shape a solution and pitch betting time on it in the next cycle.
The Betting Table
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.
This led us to try longer cycles.
We wanted a cycle that would be long enough to finish a whole project, start to end.
At the same time, cycles need to be short enough to see the end from the beginning.
People need to feel the deadline looming in order to make trade-offs.
If the deadline is too distant and abstract at the start, teams will naturally wander and use time inefficiently until the deadline starts to get closer and feel real.
After years of experimentation we arrived at six weeks.
Six weeks is long enough to finish something meaningful and still short enough to see the end from the beginning.
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.
That said, nobody likes bugs.
We still want ways to deal with them.
Three strategies have worked for us.
Use cool-down.
Ask any programmer if there are things they wish they could go back and fix and they’ll have a list to show you.
The cool-down period between cycles gives them time to do exactly that.
Six weeks is not long to wait for the majority of bugs, and two weeks every six weeks actually adds up to a lot of time for fixing them.
Bring it to the betting table.
If a bug is too big to fix during cool-down, it can compete for resources at the betting table.
Suppose a back-end process is slowing the app down and a programmer wants to change it from a synchronous step to an asynchronous job.
The programmer can make the case for fixing it and shape the solution in a pitch.
Then instead of interrupting other work, the people at the betting table can make a deliberate decision.
Time should always be used strategically.
There’s a huge difference between delaying other work to fix a bug versus deciding up front that the bug is worth the time to fix.
Schedule a bug smash.
Once a year—usually around the holidays—we’ll dedicate a whole cycle to fixing bugs.
We call it a “bug smash.”
The holidays are a good time for this because it’s hard to get a normal project done when people are traveling or taking time off.
The team can self-organize to pick off the most important bugs and solve long-standing issues in the front-end or back-end.
Get One Piece Done
Beautiful alignment, colors, and typography don’t matter on the first pass.
Visual styling is important in the end product, not in the early stages.
The biggest uncertainties are about whether it will work, whether it will make sense, and how hard it will be to implement.
After the elements are wired up, they can be rearranged, restyled, and repainted to improve the work that’s already done.
First make it work, then make it beautiful.
About the Author
Ryan Singer has worked on all levels of the software stack, from UI design to back-end programming to strategy.