In an area dominated by Scrum, it is genuinely pleasant to learn that a successful company is adopting a totally different approach on how they develop their product.

Me quedo con que es un buen framework para aprender a decir que no, y a partir de eso, aumentar la capacidad de delivery.

Shape Up is a great read for software teams who are looking to improve their development practices. It’s not capital-A-Agile, nor kanban, nor pair nor agile nor a mashup of methodologies: instead, it’s an organic practice developed at Basecamp over the years to address their specific needs as a software team dedicated to the development, maintenance, support, and growth of SAAS digital products. I particularly liked how the book addressed both “Truths” in software development, and the apparatus they developed to address the Truths. Some are well known: “Work expands to fill the time available.” Some feel like a refreshing wakeup from typical practices: “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.” And others defuse the perennial problem of scope changes: “Scope grows naturally. Scope creep isn’t the fault of bad clients, bad managers, or bad programmers. Projects are opaque at the macro scale. You can’t see all the little micro-details of a project until you get down into the work. Then you discover not only complexities you didn’t anticipate, but all kinds of things that could be fixed or made better than they are.” Finally, other truths come from a “developers-first” culture that takes seriously the value and thinking people bring to the table: “Teams love being given more freedom to implement an idea the way they think is best. Talented people don’t like being treated like “code monkeys” or ticket takers.” Shape Up breaks from typical PM and development methodologies. It starts with “well-shaped pitches,” that is, a proposal for development that is flushed out—not in terms of look and feel, but rather in terms of integration, user experience, and flow. No dead ends or handwaving stuff by the time it comes to the dev team. It continues with a de-emphasis on issues and tasks, created before the work has started — it uses the pitch, instead, to drive an assigned team, enabling the team itself to understand the scope of the problem, and create the issues and tasks needed to address it. This emphasis on “get something working” and the focus on doing real work is a nice break from what one thinks one has to do, at the start of the project, well outside the weeds of doing it. Finally, the methodology locks on time as a constraint, and flexes on scope: Basecamp uses a six-week work cycle, and projects are expected to launch within that cycle. That can happen by chunking off the right amount of work, and enabling the team to flex on scope — identifying “nice to haves” as such, and keeping the eye on the mission of launching within the cycle. “Anybody can suggest expensive and complicated solutions. It takes work and design insight to get to a simple idea that fits in a small time box. Stating the appetite and embracing it as a constraint turns everyone into a partner in that process.” While the specific implementation techniques Shape Up highlights are unique Basecamp and may be more appropriate for SAAS teams, the underlying truths of software development will resonate with all teams. I’m looking forward to applying some of these methods to our own practices.

Clear thinking. I'm sure there's a million "What about X" that Ryan didn't cover, but this is a good starting point for simple product development.

Send this to your PMs.

Really great for those looking at a different way of building software.