| Been using ShapeUp for nearly a year now in an org of ~50 engineers. Let me start by saying, if you intend to adopt ShapeUp, spend a great deal of time reading and buying into their structure of teams. Aside from SIP/QA & KTLO work, they flatten the “Core Product team” and build ad-hoc teams for a pitch that has won at the betting table - for that cycle. Trying to maintain standing teams with domains of ownership is a very challenging way to adopt this process. In my experience, unless the entire org is drinking the kool-aid - hard - you end up with 6w cycles of waterfall. Pitches morph quickly from “present your idea that we bet against” to “write up a detailed design doc, along with an Epic, backlog and all projected work” - then the org will just do the work they want (betting or no). Now your team is committed to delivering on your pitch - any other work just gets dumped on the wayside - unless you’re on-call of course. As with any other incantation of an agile process, you can bastardize it to confusion, thinking you’re smarter, or “we’re adapting this to fit our org”. Folks, this stuff is a discipline. You have to buy in, you have to learn the principles, you have to practice them - as described - until you attain some degree of mastery that you can adapt. This is not an individuals game, this is at the org level. The individuals must commit with the org to gaining mastery before customizing to your liking. In spirit - there’s nothing fundamentally broken with Scrum or Kanban or ShapeUp or whatever. It’s really how you hold it - and yes you can shoot yourself and others in the face by holding it wrong. |