profile

Juani Villarejo

How I started with Shape Up

It's been 4 years since I've been working with Shape Up, the software methodology from 37signals, the people who made Basecamp and Hey.

On this journey of being the CTO and CPO of Nulinga, a company I also co-founded, I've been applying the methodology with great satisfaction.

Every time I give a talk about Shape Up and share its benefits and its difficulties, people, specially product managers, ask me:

How can I start using in my company?

As an example a few days ago, in Nerdearla Argentina 2024, our product manager Dani, gave an intro talk about Shape Up and the audience asked the same question:

How can I start?

It's hard for me to give prescriptions on how to start, because I, as an executive and co-founder of the company, have the leverage to make the decision to try something.

But my style of managing isn't by imposing things, but presenting the arguments, and infusing an experimentation mindset. That was the way I introduced Shape Up to my team.

It was 2020, and our product team, of 3 developers, one product manager, one designer and me was using a mix of Scrum and Kanban. We were working in 3-week sprints, assigning one epic to each developer and defining the user stories in our planning meeting at the start of each sprint.

But there was a huge struggle with this way of working. The Epic defined a Raw Idea, but there wasn't any clear definition of what the problem was or of a possible solution as a whole.

In the planning, we defined user stories with the typical template:

As X, I want to do Y, so that I expect Z.

But when the clock started to tick and the developers and designer started attacking each of the stories, they couldn't decide the approach in terms of user flow and experience.

That uncertainty caused me to be constantly on demand, helping the team decide the next steps. As a product executive and founder, I had the whole product's strategic vision inside my mind, but when you are in the trenches too, it's hard to externalize it clearly.

And even though, this pain was hugely affecting me, because I was the scarce resource, there was pain for the team because for each User Story we would need a meeting to decide the best way to approach it. This was indeed an incredible waste.

When I started programming the first version of the product, as a single developer I had all the decisions in my mind and I could change it in any way I wanted. The software was simple, the impact of any change was small.

As the product, and the organization grew, building new features became more complex because of the interrelationships that emerged. There were many more decisions to make when building a feature, like:

I was a big follower of Basecamp and 37signals, and I love developing with Ruby on Rails, so I heard about Shape Up. But, I didn't read the book until I listened to their Q&A podcast episode in 2020.

There is something about my mind that going from practice to theory is highly more effective for me than the reverse.

Something that resonated a lot with me after reading the book was that If I wanted the team to ship with autonomy, I needed to make some decisions upfront. This was the total antithesis of lean and agile. That every decision should be delayed until the limit, because what you decided might not be relevant anymore. "Priorities change" is its motto.

However, if you can commit a budget in weeks (3, 4, 6, depending on your appetite) and in people, to build a specific feature, because it is strategically important, as Shape Up propose, you are very certain that priority won't change. Then you can make some decisions before the clock starts.

Of course, those decisions should be at the correct level of abstraction, in order to give the team the freedom they need to solve the local issues they find along the way.

After I realized that, I decided to introduce the team to Shape Up, presenting our struggle in one of our retrospectives. They understood the problem, but they were very skeptical.

People don't like when you try to change their habits, and Scrum is highly ingrained in the developers' brains.

Whenever I hear skeptical voices, I try to present the new idea as an experiment. I remember I said: let's try it as a small trial. A 3 weeks appetite project, with 1 developer and 1 designer just assigned to it, as a separate track that can work in parallel with the rest of the team working with our current 3 weeks sprint.

The downside would be just 1 developer and 1 designer' time wasted for 3 weeks if we can't ship the project.

The upside, that people could work more autonomously, so our product manager and I can have free time to concentrate on other very important questions like:

What would be important to build next so we can improve the business goals?

If I wanted to raise the chances of success for the trial project, I needed to reduce the risk as much as possible. That's why I decided that the feature we were going to build was for the Admin user. The admin dashboard, on the technical side, is very easy to modify, and the admin user was more forgiving with the UI experience.

The project we defined was to add more options to configure the accounts of our clients so we can have more flexibility with the contract to meet the needs of our customers. This was already happening, but it wasn't reflected correctly on our product.

As Nulinga is a B2B company, in order to make a sale, there are some differences in the plans and features that some accounts have. This should be configurable in our product, so our client sales team can negotiate better deals.

The main point of the trial was that the appetite was very strict, the developer and designer would have to cut the scope and communicate properly what they left out.

The upfront decisions that we made on the pitch were to define clearly the new fields and types (date, price with currency) and UI steps in order to correctly configure a client contract.

The technical decisions, we decided, were the names of the new domain concepts that would be introduced with the feature. This was very important because how to name domain concepts was highly discussed during our on-demand meetings during the sprint.

If I wanted the team to work autonomously, these domain concepts should be given, and if the team finds a better name, they can propose it. But at least, they have something to start with.

The project was a huge success. 4 years later, we are still very happily working with Shape Up. But there were some learned lessons.

One of the main lessons was that the level of abstraction of the pitch changes depending on who is going to develop the feature. People with more experience can have more freedom, higher levels of predefined abstractions, and fewer uncertainties solved upfront.

More junior people need more predefined decisions, not only in UI terms but also in technical terms. This happens because they don't have the knowledge and experience to make decisions with the expected quality autonomously. They need a more clearly defined path they can take without having to doubt if they are doing the correct task.

Another lesson is that, in order to be able to attack bugs and other kinds of reactive work that can emerge during the cycle, we would need some slack capacity. We call that role a pivot developer.

During the cycle, this pivot developer, just solve bugs and work on small improvements that are prioritized weekly with a Kanban board. These reactive tasks don't require shaping because there aren't many options for how to solve them.

We don't have a formal betting table with the pitches perfectly shaped. Instead, the betting flows dynamically during the cycle on a side track. This constant betting flows by removing raw ideas.

We have a formal framing table during our second week of the cycle, where we list all of our problems, raw ideas and opportunities we seek to pursue. Then we remove those that are "not for now" or "too hard to solve now".

After that, we are left with the raw ideas that we think would be interesting to shape, but also the ones we feel that can be shaped with the available information we have during that cycle. For each of these ideas, we define an appetite and assign them to be shaped.

At the end of the cycle, and sometimes we extend to the cooldown, we decide between those that have a clear shaping. Also, we consider which developers and designers are going to be available (because of time-offs or they are assigned the pivot role) during the next cycle to make the decision.

This is important because, in order to reduce the uncertainty of shipping the project, it's better to assign the pitches to the people with more knowledge about that part of the product.

It's been a long post, but if you have to take away something, it would be that if you want to introduce a new way to work in your organization, try to make it as a proof of concept, as an experiment with a limited downside.

Don't present it as if you would need to change the entire organization or team to make it work. Start small and raise the chance of success by mapping the risks and removing them.

As Shape Up promotes, think in bets and work hard to reduce the risks of not shipping.