My key take aways from Shape Up:

1. Deliver completed and entire pieces of work in an amount of time that is sufficient for you to be able to do that (i.e. 6 weeks instead of a typical 2 week sprint).

2. Stay focused on scope and the end goal, don’t worry too much about all the bells and whistles and instead focus on delivering as much value as possible in the time you’ve got available.

3. While they try hard to mention that Shape Up isn’t your typical “Scum” or “KanBan” process, Shape Up, at least to me - is an abstraction on top of the typical Scrum or KanBan process. This ofcourse isn’t a bad thing and I particularly like some of their ideas when it comes to relaying information back to managers, such as hill charts.

What would I change about Shape Up?

1. Pitches in an email/thread. While this does allow for asychronous flow and autonomy, important nuances and context can me missed in documentation that can be more easily shared in a short 15 minute kick-off call (with a reference to the document).
2. If you’re maintaining a list of items to achieve, it’s a backlog of work, so I would personally avoid teaching new developers to avoid a backlog in the way that the book does - I think it might cause confusion.
3. I would actually include an architect or some sort of lead. Developer exploration can be inefficient and lead to much overlap. In the case of 1 designer/1 developer, it makes sense, but as soon as you start to add more designers/developers, I believe you’d lead to repeated exploration. I would perhaps tweak the method to work from the outside in and instead build a layer up approach. Starting with a core set of services that can be identified between each feature and increase in fidelity as time progresses. Also - if so much time has been spent shaping and betting, there’s a lot of extra context you can probably provide the team in an initial kick-off call, rather than a document.

What do I like about Shape Up?

1. “Scope Hammering”. This isn’t new to any particular methodology, but I believe it’s vitally important when avoiding feature creep and appreciate that it’s such a core focus of the approach.
2. Comitting to what they build and preventing distractions from the team. Again, this is the core focus of approaches such as Scrum, but in a typical development team, it’s all too common to see someone “borrowed” for a “small thing” that can completely throw off their focus. So I appreciate their commitment to sticking to what they bet on.