We've taken some inspiration from Shape Up by the Basecamp folk. We don't use Basecamp or follow it strictly, but since we had already been practicing some of t

We've taken some inspiration from Shape Up by the Basecamp folk. We don't use Basecamp or follow it strictly, but since we had already been practicing some of the things the book advocates for, we decided to take a closer look and adopt some of their terminology. Some highlights: * 6 week cycle + 2 week cooldown * no ticket backlog * handoff between product and eng, scope hammering * fixed deadlines * integrate first then refine To me it feels like a modern blend that takes a few good things from the Agile philosophy but concedes that not everything happens in 2-week sprints in reality and that effective product people have to actually design product and buy work instead of just dump user stories into the issue tracker and tell engineers to build them all. With our team of 4, we essentially choose from a set of "pitches" 3-6 "bets" for a 6 week cycle. We then work on answering all the unknowns (e.g. "does this platform API support some requirement in the way we think it might?", or "is there a de facto library for this or do we need to build it?") and prototyping solutions for the projects. Those prototypes we share with each other once they're working (and of course collaborate along the way as needed). From the prototype, now that you actually have an engineering handle on the task, you basically resolve how much time is left in the "appetite" (allotted time for the project) against the remaining scope of work. Then you do an amazing rare thing: the engineering team cuts, or "hammers", scope until they can deliver something on time. This is very different from the norm in my experience where product tries to micro manage the outcomes of the project the whole way. Obviously things are not totally rigid and sometimes a little more appetite appears to allow something to not be hammered out of the final thing or some preferences are expressed for which project to hammer harder when competing for remaining time, but it generally works pretty well. At the end, product gets to taste what got cooked up by the chefs and then, during cooldown, decide (with eng leaders) what to pitch and ultimately bet on for the next cycle while the eng team addresses smaller tasks, monitors deployments, polishes, and fixes bugs. The key, "shape up" terminology and logistics aside, is forcing product to make up front "purchase commitments" (my term) of things they need/want in the product. This forces a lot of things that don't happen normally or happen ad hoc during a sprint to happen up front (in theory, alas no process is perfect). Somewhat secondary but also very important and close to my heart is that this methodology avoids the utterly useless and inaccurate time waste of trying to achieve task-level estimates prior to work, usually building something that nobody has every build before, has starting. It inverts the commitment so that engineers are building what the time allows rather than product asking how long something is going to take and then rightfully getting angry/frustrated when things 4x as long as the engineers said they would. It feels way more human as an engineer to be given some freedom to explore the solution space and then use your and your teams expertise to deliver a solution in the allotted time.