Shape up: Stop Running in Circles and Ship Work that Matters by Ryan Singer

Summary

December 2020 I did read some books and papers: The MM-M book, Design by Contract, PROGRAMMING WITH ABSTRACT DATA TYPES, Shape Up: Stop Running in Circles and Ship Work that Matters, Domain-driven design, and others, but those in specific look like are directly connected; because that book had come with similar proposal and ideas I already had developed my application in the last years, problems and solutions that I found. You should read all those paper and books to better understand, the DDD you can just read the first 1/3 of the book and you will be fine to understand why I already loved to read those books and papers. They proposal lot of stuff related to every step of software management to you learn or better remember the best practices; but working with IT I saw the common problem were not related to the software itself when in mid, mid-end and end of development but the beginning.

The MM-M book proposal all we do today but using waterfall model, and from my point of view shape up remove this waterfall model “problem” to implement a different type of agile to also to maintain motivation to the team. The other book and paper help to have a better overview opinion about everything

How to first planning the project

The problem talked in the MM-M about the second first system would be a fail were because of Waterfall Model, that were better develop to “An incremental-Build Model is Beter - Progressive Refinement Builduind an end-to-end skeleton system” where you first create a system’s skeleton of your system with empty functionalities and in different modules of the development process since you you compile, test and compile until you fill all those modules. This way every delivery we will have a module working with with tests and debug done. This way we can create tests with the user earlier. This way you always have a product to sell and it make easier to the financial planning team to plan the future of the software with only the cost of less features, not bad software. TDD, frequently deploys, staging environment with versions that always work were just some of all the stuff proposed here in 1975, not 2020!

My connection to shape up is exactly there, where the proposal was based with waterfall the shape up proposal is related to our current agile culture, there makes it easier to fit our current environment of work and business.

The path proposal in shape up book is:

1. Problem: The raw idea, a use case, or something we’ve seen that motivates us to work on this 2. Appetite: How much time we wen to spend and how that constrains the solution 3. Solution: The core element we came up with, is presented in a form that’s easier for people to immediately understand 4. Rabbit holes: Details about the solution worth calling out to avoid problems 5. No-Goes: Anything specifically excluded from the concept: functionality or use cases we intentionally aren’t covering to fir the appetite or make the problem tractable

When you’re doing the shape-up proposal we probably already would be following the MM-M process, but easier to understand with our common way to work also using TDD, frequently deploys, staging environment with versions that always work and etc...