Meet Roland Lacroute, Engineering Manager at Trustpair.

I was really interested by the project and the stage of the company, not too small, not too big, with a will to grow and to structure itself. When I joined, the company was using the Shape Up methodology. I had some ideas about it, but not much further than some articles I’d read, and I had never experienced it before. It could be the next trend and I had to be part of it!

Let's see how it went...

Some key points about ShapeUp

It was created and implemented in Basecamp in early 2000. Basecamp is a rather small software editor. We owe them Rails. Ruby on Rails, or RoR for those in engineering, but I'm sure you’ve already heard about it.

In 2019, they released a book describing the methodology called "Shape Up Stop Running in Circles and Ship Work that Matters". It's available for free, if you want to go deeper.

It was adopted at Trustpair in 2020 at a time where the company was still rather small, around 25 people with just a few engineers in R&D.

With Shape Up, work is divided into "small stuff" (small technical debt, bug fixes and various small enhancements), called Cooldown and Features. A feature has 2 stages, Shape and Build:

The idea is to organise the work within cycles which has these key steps:

At Trustpair, the team grew a lot since 2020. Candidates were really seduced by this new way of working and were ready to challenge themselves and try new methods. In R&D, we went from 4-5 people to around 30 while the whole company quadrupled its number of employees.

Yeah, so what happened?

The limitations of ShapeUp

As I said, Shape Up comes from Basecamp, a rather small company with a single product which can be seen as a Wysiwyg. It counted around 30 people overall in 2019 with developers working there for ages (yeah, I know, it changed since then). As a consequence, a lot of things are not documented in the method:

The methodology at Trustpair was continuously evolving. Generally speaking, this is normal and sane. But here, the amount of methodological enhancements was huge and it was hard to follow what was working, what wasn’t and what iterations to do. We asked a lot of people who had to change their way of working continuously.

Nevertheless, we did some great things. If there was one to mention, it would be the introduction of Cellular Organisation promoted by Eric Delavallee. He has a great blog in french about this idea, worth reading.

But despite all our efforts, there were 2 aspects which weren’t significantly improved:

Ending a Cycle

All projects start and end at the same time, so some phases overlap in terms of R&D, review and QA in particular. Having everyone in review or QA at the same time caused a real bottleneck.

Another aspect was how to deal with the hard deadline of the end of a cycle, whatever its size or events that happened during its build. To finish all projects, we had to make compromises. And technical tradeoffs always means lower the quality or accept technical debt. It’s harder to cut functionalities at the end of the cycle, when most of it is developed.

Thirdly, as a cycle is relatively long, if a subject is not prioritized, it will remain on the side, possibly for a long time. In theory it's good, we prioritise only what we really want to do. In practice, we loaded the cycles as much as possible with a lot of subjects "just not to lose it". Typically, these last minute projects weren’t well defined or even really ready...

In short, we fell into a vicious circle:

Managing Support

By the book, support is done during the Cooldown phase, in the last 2 weeks of a cycle. But the reality is that a client encountering a bug won’t wait weeks before being fixed, not even speaking about SLA.

So we decided to allocate a developer every week to manage support cases. Then it became a dedicated developer, then 2 developers… It continuously increased.

In the long run, this way of doing things proved to be ineffective:

Switching methodology

So after all the excitement around this new method, we were starting to have doubts. We could feel exhaustion and frustration from all stakeholders. There were more and more hiccups. It was time to move forward.

What changed?

The main idea was to stop cycles, leverage Product Managers in the day to day life of the team and manage support along the way.

On the different level workflows:

We’re - happily - back in the most of the main stream boxes with methods that are well documented and already used by many stakeholders in tech.

We split R&D into two areas; one called Domains, which improved ownership and specialised developers and PM’s. We kept the idea of an organic organisation within domains. People are changing context easily and frequently, we avoid having people on the very same topic for ages.

From an organisational point of view, we are clearer on the roles. Developers are working more peacefully: no more stressful end of cycles or overloaded support weeks.

On a day-to-day basis, we introduced stand-ups which is the only real new meeting. We have successfully introduced Jira and Product Boards. We are now able to follow progress on topics much better. We can gather metrics on our work and really measure our progress and our delays.

The adoption of the new support management was a bit slower to start. Now, the climate starts being more peaceful and the subject is really embraced by all stakeholders. We can’t accept only quick fixes anymore and real initiatives started.

How was the change accepted and perceived?

Shape Up was a recruitment argument and people were attached of the principle of doing something different.

Some problems have been solved, many even. However, the two subjects described above did not really improve. So as I said, people were exhausted and we needed to try something else.

In the end, there was very little resistance to change. The teams were already used to change and try continuously: this mindset helped us a lot. Eventually, change management was quite easy even if we introduced new tools and new way of working.

Overall, we were able to switch methodologies within few weeks.

And now, how are things going?

It’s been just a few months. The journey is not over (will it ever be?).

The end-of-cycle rush has disappeared and we really have ways to improve the support. Our two biggest problems are on their way to be managed. So far, there are no real new issues that have been identified.

With Shape Up, we were constantly questioning how to improve this or that. Now we have a macro framework in which people can make their own improvements and iterate.

We can now focus on other aspects that previously existed with Shape Up, but weren’t serious enough to really deal with, like better roadmap management, for example.

What have we learnt?

ShapeUp is cool and has a good image on the market. But like every other methodology, there are pro’s and con’s.

Pro’s

Con’s

Short conclusion

Overall, ShapeUp is a good methodology and we learnt a lot from using it for several years. It helped us grow the company and the product with the resources that we had at the time. We have to be thankful for that!

Now we’ve moved on to something else, but this is probably just a step in the journey and we’ll write some new articles in the future explaining how things go & how we can further improve.