Basecamp and Shape-Up: Real-World Experience
Tags: basecamp, shapeup, agile, realworld
Published: 2020-06-18 00:45:35

Hi there!

It has been some time that I've planning to write this post... This is an account of the adoption of the Shape Up method in my daily development routine. Imagine the Shape Up as the handbook and Basecamp as the toolbox needed to follow it. I will not go deeper into Shape Up, but you can learn about it from its book here, for free: https://basecamp.com/shapeup

But let's begin with the 'why'... The dev team I worked on had a common problem in the software development world: The release date has been reached and some subfeature is not complete... Then the subfeature was so attached to the core of the feature in the implementation that it would not be possible to deliver without it, forcing the delivery to be postponed... So, with the help of the Head of Development, we began implementing the Shape Up method together with Basecamp so we could deliver more value, regularly, without postponement.

Four cycles in and the result is what some may call a "revolution" that I've never seen in any adoption of a methodology. I, personally, don't have a lot of faith in stacking processes from commonly used methodologies with the mentality of it being the "key" to a  team success. Also, the results are too meaningful to justify it to be just better developer throughput either. And it is not just on delivering more value, but also having a better team relationship: better team engagement, more skill transfer between developers, easy organization of tasks...

From my real-world experience with Shape Up + Basecamp:

- Organization is way better: By working on TODOs and hill charts the developers can easily transmit their feeling of completeness in a cycle;

- Product definitions became way more clear: Well defined pitches helps by creating a "playground of thoughts" where the devs can work on with autonomy. It also optimizes a lot with reducing meetings for realignment of the development and product;

- Scope manipulation: Probably the main benefit I've seen personally is learning to manipulate a scope, having and applying this autonomy as a developer. This was particularly difficult for me because I had this "well I must achieve the full scope by the end of the cycle" otherwise it would be a bad delivery. So, I learned an amazing skill: learn where to cut, what to cut OR to add so we could have a deliverable by the end of the cycle. With the autonomy comes great responsibility: developers must ensure a consistent delivery (and not a delivery that attends it all but with LOTS of tech debt);

- Team skills improved a lot because of the union of concepts within Shape Up + Basecamp like scopes TODO lists, hill charts and the autonomy to manipulate the pitches: The team pair programmed way more and discussed trying to predict the best solution a lot before even coding;

- Productivity is improved because of the mindset of autonomy in the developers: Clearly define what is core (what is the beating heart of the pitch) and what isn't. By defining the core the developers can work on it with maximum priority and then they can work on the other tasks in an async way w/ creating bottlenecks in each other. Another benefit of focusing in well defined TODO scopes is avoiding creating concepts that are so interlaced that you can't manipulate anything (which is, in fact, a common cause of deliveries postponement) 

As for the cons: Most of the devs have a high difficulty with manipulating scope because of the feeling of delivering an "incomplete feature" relative to the pitch. This was the most felt difficulty primarily because it is also about mindset... A mindset of being free to decide how to solve the problem, which, unfortunately, is not the reality for most developers. It is especially difficult for those who are used to taking orders from the boss because with Shape Up they have accountability on decisions.

Finally, my personal feeling about Shape Up is simple: It is, above everything, about freedom (and of course, the accountability that comes with it). It does not impose processes, it suggests a mindset. And when that mindset is absorbed better productivity and value delivery happen naturally.