Basecamp 3 sucks11/28/2023 In that case, draw a boundary between the part of the app that has a settled architecture and the new area that’s unsettled. Sometimes you need to do build a feature totally unlike anything you’ve done before or with unfamiliar technology. This split between R&D and production mode is also useful for existing products. But we didn’t commit to any specific work further than six weeks ahead. We knew it would take multiple cycles to build BC3 - maybe a year’s worth or more. We still only made commitments one cycle at a time. Those features weren’t anywhere near complete enough to ship, but the stubbed versions gave him confidence that the architecture would accommodate all the functionality we hoped to build later. Extremely bare bones versions of the message board, comments, and to-do features validated the architecture. In the case of Basecamp 3, David (co-founder and CTO) started by doing R&D work to define the access model and how data of many different kinds would belong to one project versus another. Instead of building things half-way like in R&D mode, the team is expected to build a fully working version and deploy it by the end of the cycle. We don’t know if we’ll like a new feature or if we’ll include it in the final cut of the product, but we can define our appetite for it, shape it, bet time on it, and give it to a team. All the detailed Shape Up methods apply at this point. What’s different is now the architecture is settled and the ground is firm, so we can make surer bets. There are still lots of unknowns and unbuilt features in production mode. Once they do, we can shift to production mode. It can take the skunkworks team a few cycles of work before they get to this point. It’s easier to see where new features will go and what they will be built upon. With the key pieces of the architecture in place, constraints now exist for future work. There are lots of deep judgement calls to make and no existing code or interface constraints to guide their efforts.Įventually the R&D team gets to a point where they’re willing to “pour concrete” on the fundamentals. That’s why the team needs to be small and senior. They’ll shape an approach, spike it out, learn something, and try something else. The R&D team integrates shaping and building in a blurry mix within the time box we’ve allocated. But for a new product, you need to get through this experimental phase to arrive at the basic design. That would be very unhealthy in production work. It’s common to pursue one approach for a couple weeks, realize it’s not working, scrap everything, and then try something else. (The Pragmatic Programmers call this “firing tracer bullets.”) Instead of building features to completion, they build just enough to verify that the product hangs together and the architecture accommodates the functionality we’ll need. An experienced designer/programmer team will pair together skunkworks style to work out the basics of the overall architecture and some key interface elements. Instead of shaping and betting on a specific feature idea, we bet a block of time (a six-week cycle) on exploratory work with an extremely rough list of potential features. We call them “R&D mode” and “production mode.” There are two phases of work when you start a new product. We’re working on a new product right now, and we’re following the same approach we used to build Basecamp 3 and Basecamp 2 before it. There’s a new appendix in the book now to answer this question: How to Begin to Shape Up: New versus existing products. People in my book club love all the principles, but they had one question: How did they build Basecamp 3 doing this? It seems like all the practices are for adding features to an existing product. Here’s a common question that’s coming up about Shape Up, our new book on product development:
0 Comments
Leave a Reply.AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |