%% Last Updated: - [[2021-02-17]] - [[2020-09-06]] - [[2020-09-26]] Related: - [[Productivity]] [[Work Methodologies]] [[Software Development]] [[Agile]] %% - Some of the terminology is confusing and unnecessary. - It uses terminology not present in either traditional software methodologies or even [[Agile]] methodologies. - In [[Shape Up]], a scope is a small chunk of work, but in other parts of [[Shape Up: Stop Running in Circles and Ship Work that Matters|the book]]), a scope retains its normal sense of being the content and limitation of the work. Sometimes this is called "bounds" instead of scope. - Shape Up emphasizes being in [[Shape Up Terminology#^6a4cda|production mode]], where work is actually built, but being constantly in a state of production is not realistic. In fact, Shape Up acknowledges this by introducing several non-production modes such as [[Shape Up Terminology#^fd5dce|R&D mode]], bug smashes, or the [[Shape Up Terminology#^eaca83|cool-down]]. The existence of these modes calls Shape Up's long-term sustainability into question and opens up the possibility of staying longer in non-production modes than in the production mode. - Reliance on management may be too restrictive. (top-down rather than bottom-up) - Despite the fact that Shape Up emphasizes the development team's freedom to implement solutions, all work is canonically still shaped, pitched, and bet upon by management. - It's too easy for managers to shape work to the extent that development teams no longer have meaningful decisions to make, and the work becomes a matter of filling in the blanks. - Managerial involvement doesn't translate too well for smaller teams where there may be one or no official managers. - Both [[Flood (company)]] and [[You Need A Budget (YNAB)]] addressed this by opening up shaping and pitching to everyone, not just management. - The principle of uninterrupted work during the [[Building shaped work (Shape Up)|building phase]] is unrealistic. - While the team is in the Building stage, they are meant to be allowed to work solely on the project. While [[Deep Work]] is essential for productivity, it's difficult to imagine having all the teams unreachable for the length of the cycle, which in Shape Up is longer than normal at six weeks. - Possible solution: staggered cycles that still leave some teams/people around to react to issues that come up while freeing up others to go into production mode. However, this arrangement would probably lead to [[Agile]]'s permanent teams, whereas Shape Up is built on the premise of variable teams. Perhaps teams could be periodically shaken up? - Shape Up cycles include testing, but not documentation and marketing activities that are also essential. - In smaller teams, Shape Up does not include non-developer members. This could be addressed by making documentation/marketing an essential component of a cycle and by allowing non-development projects to be pitched. - Shape Up tries to actively steer away from the concept of a backlog, but since pitched work that is not bet on can return to the betting table or be reshaped for future pitching, it does amount to the same thing. The only difference is that this bet backlog must contain _shaped_ work. - However, it's difficult to imagine not keeping track of unformed or unshaped ideas, and teams on Shape Up likely still maintain such a list anyway. Shape Up would be strengthened by an acknowledgment of this fact. - Shape Up seems to be geared towards smaller teams with fewer structures. It's unclear how it would work in a larger team or in a more enterprise setup where there are several teams working independently but needing to collaborate. - Shape Up's six-week structure can be too big a bet in some situations. - Shape Up doesn't explicitly include time for reflection or retrospection, although presumably this could be done in the cool-down period. ![[Basecamp's Shape Up: how different is it really from Scrum?#^9ef1c9]] ## See also - [[Shaking Up Shape Up]]