From Scrum to Shape Up: A tale of catharsis

What happened when a struggling team completely changed their process framework and found a new sense of freedom

By Merlin carter

David wasn’t happy with the way things were working. His team was consistently underestimating their projects. They would aim for three sprints. Instead, projects dragged on for five. Tasks would constantly get carried over into subsequent sprints. It was frustrating. They wanted to start with a clean slate, but they never could. There were always the stragglers to take care of — the tasks left over from previous sprints.

David Arens is a product manager at a startup called store2be. It’s one of our portfolio companies, which is why David shared his story with our Chief Product Officer, Tamer El-Hawari.

We were feeling a lot of pain … around the way we had been working … everybody in the team was very open to anything that would get us out of it.

— David Arens, Product Manager at store2be, Project A Podcast

David said this during a recent Project A podcast. He was in discussion with Tamer and Ryan Singer from Basecamp, who hears plenty of stories like this. Ryan is the author of “Shape Up: Stop Running in Circles and Ship Work that Matters”. In his ebook, Ryan outlines a new process framework for developing software products. One that addresses the kinds of problems that David was describing.

But David was by no means the only one who was struggling with scrum. After publishing his ebook, Ryan started receiving enthusiastic emails from teams who were excited to be applying his system. No matter what the industry, they all had the same problems.

[Teams were] experiencing pain … feeling that there’s no time to really think … feeling like there’s a lot of waste and that they’re not getting where they want to go.

— Ryan Singer, Head of Strategy at Basecamp, Project A Podcast

According to Ryan, the two-week sprints can make teams feel that projects are “never-ending”. This can lower team morale as frustration begins to set in. Product managers get frustrated with developers for not delivering on time. Developers get frustrated with product managers for having unrealistic expectations.

Feelings come up several times during the podcast. David talks about “pain” and “struggling” and later talks of being “calm” and “confident”. Ryan also references pain as a prerequisite to change. He reports that “teams keep using the word ‘energized’” to describe how they feel after using Shape Up. The thing is, when changing a process for the better, teams often go through a kind of transformation. Sociologists sometimes use the term “social catharsis” to describe what happens when a group of people shares a strong emotional experience — in this case, pain and frustration. Emotions become more intense after they’re shared among individuals within a group. This, in turn, can lead to group cohesion.

We already know that there was a general sense that something was wrong, but what sort of sharing was taking place within the group? As it turns out, a coincidental act of sharing became the catalyst for a change in tactics at store2Be.

By this time, David had already started pitching to management about changing their ways of working, but his efforts hadn’t yet borne fruit. Leadership was understandably hesitant to make any dramatic changes. Then one day, he logged into Slack and stumbled upon an auspicious post by one of the engineers. It pointed to an article titled “Why we ditched two-week sprints for a better product development process” in the blog section of Miro — a collaborative whiteboard platform for distributed teams. Just from the title, David could tell that he and the engineers were on the same page. It was exciting.

I jumped [at] the chance … an engineer is proposing this as well … [I thought] let’s team up and … carry forward this momentum.

— David Arens, Product Manager at store2be, Project A Podcast

So David quickly teamed up with some senior engineers and began to discuss what could be done. There was still some skepticism about whether it would be wise to go “all in” on Shape Up. Some believed that the changes should be implemented gradually. But the tipping point came when David got them on a call with Ryan to address their questions about the framework. Ryan was able to alleviate their concerns and eventually won them over.

According to David, this was a crucial factor. He thinks that Shape Up wouldn’t have been given a chance if it was something product management had mandated alone. You need a solid “pilot team” that includes product managers, designers, and developers

Another crucial factor was timing. store2be was at a junction in their product development cycle. Their product is a booking platform for live marketing locations. That is, if a brand wants to hold an offline promotional event in a specific type of space, such as a shopping mall or an airport, they can use the platform to find available spaces. But the platform was due for a makeover, and they had decided to completely rewrite it from scratch. The plan was to then relaunch it as a newly revamped product.

They had a green light from leadership to tear down the old product architecture and replace it with something better. The whiteboard was wiped clean, and new markers were ready to be uncapped. So it was the perfect time to change the way they worked.

They were also lucky to have an open-minded founder who was willing to take a risk on a new development philosophy. Emil Kabisch co-founded the startup in 2015 and is now store2be’s Chief Product Officer. He was receptive to David and Ryan’s ideas right from the start and could see the potential of Shape Up to solve the issues that they were having with delivering on time.

Finally, due to the nature of their product, they had little to lose by ditching the “fast-feedback” advantage of the sprint method. They were a B2B company with a niche product and a small user base. Two weeks did not yield enough data to draw any definitive conclusions about the impact of a newly added feature.

So for store2be, they had little to lose by working with bigger chunks of time. They could invest the time to get a feature right on their first dash, which in turn allowed them to move on to the next project with a clean slate.

How it feels to work with Shape Up

Let’s fast forward a few months after Shape Up was introduced at store2be. The operational catharsis has completely transformed David’s outlook and the outlook of his teammates.

This was partly because their feature backlog was gone. But not the ideas — the tickets. You see, Shape Up doesn’t require you to keep a backlog of tickets like you would normally do for Scrum. David feels emancipated. In a subsequent article on implementing Shape Up, he writes:

Not having a backlog is a liberating feeling … [It] adds to a feeling of: ‘We’re now doing this, and we’re getting it done’. Afterwards, we’re free to do whatever we deem most important then.

— David Arens, “Implementing Shape Up: A Case Study”

Naturally, his team shared his sense of relief. According to David, what they appreciate the most is the extra time that they have to build momentum.

From what I’ve heard, the developers on our team appreciate this very much and motivation has taken an upswing.

— David Arens, “Implementing Shape Up: A Case Study”

Ryan also mentions that he’s seen similar results with the teams that he’s coached.

They keep using the word ‘energized’ …there’s a lot more energy and a lot more interaction happening between design and development to come to the right solution.

— Ryan Singer, Head of Strategy at Basecamp, Project A Podcast

What challenged people the most

David and his team improved their morale by implementing a process that addressed their key pain points. This doesn’t mean that there weren’t any new problems — there were.

Many issues concern the right way to conduct a “cycle”. The cycle is a key concept in Shape Up. You could compare a cycle to a 2-week sprint except that it’s 6 weeks. That’s right, 6 weeks. On top of that, there’s no grooming. To prepare for a cycle, all features are specified at a certain level of abstraction during a process that Ryan calls “shaping”. The abstraction is there to encourage designers and developers to come up with their own implementation solutions without relying on a precise set of specifications.

The other unique thing about a cycle is that any unfinished work is canceled rather than carried over. For example, suppose that you had a cycle devoted to implementing a calendar feature. and you didn’t get all the necessary parts done, well tough luck. The next cycle will be devoted to a completely different feature, it might be a voting feature or registration wizard — whatever it is, your unfinished calendar tasks would no longer be relevant. You’d need to tie up what you’ve done so far by the end of the cycle.

These changes placed an enormous amount of responsibility on the engineers and designers. They sometimes felt forced to make decisions they weren’t qualified to make. For instance, they were now responsible for canceling tasks that weren’t achievable in the cycle. They also had to make important design and architectural decisions on their own instead of following instructions in a ticket.

And you can imagine how product managers felt about this. Such a loss of control was unprecedented. But the idea was this: if the product managers did a good job at “shaping”, the engineers would have fewer tough decisions to make. Nevertheless, product managers had to learn how to let go. No more micromanaging the time that engineers spend on tasks. Not easy for anyone who has control freak tendencies (I’m talking to my people here).

But overall, David has no regrets. His biggest problem is gone:

it’s solved … our biggest pain in that we were now shipping what we want to ship when we want to ship it.

— David Arens, Product Manager at store2be, Project A Podcast

Shape Up isn’t for everyone

Despite encountering some speed bumps along the way, the team at store2be generally thrived under Shape Up. That’s not to say that it will guarantee success for every team. In the Podcast, Ryan outlined two cases where Shape Up isn’t going to work

This first case is what Ryan calls “R&D mode”. In this mode, you’re developing a completely new product idea, or you’re trying out a technology platform that you’ve never used. The assumption is that you’ll probably discard most of your initial work. You don’t yet have a clear picture of what you are trying to achieve, so you can’t define any concrete deliverables for a cycle. Ryan likens this mode to doing a spike in the Agile process, but on a much larger scale. It’s a time-boxed period that you allocate for some exploratory research. However, you can still introduce Shape Up later on when you’ve finished your research and have your basic product architecture laid out.

The second case is when you don’t have direct control over your team’s time. This typically occurs when you’re relying on an external team to do the work. The team could be “external” in the sense that it belongs to another department in your company, or it could be a team that you’ve outsourced to a third party. On the flip side, you might be like us here at Project A — you lend your teams to other companies. In either case, you’re in a situation where you depend on external agents to complete a cycle. A developer could be reallocated to another project or you might be stuck waiting for another department to review a change that you’ve implemented. For Shape Up to work, you need to be able to predict the availability of your resources.

Choose the framework that works best for you

Because of the nature of our projects, we don’t subscribe to a single project management ideology at Project A. We’re an operational VC, so our job is to lend people and expertise to startups at different stages in their evolution. The projects and products are very different in nature, so it would be unwise to rely exclusively on one method, such as scrum or kanban. Although we often use scrum, we occasionally get projects that are small enough to forego any kind of formal process. In these cases, the project is handled by three people sitting around a table, hashing out ideas, and building as they go. But other projects might even require more of a waterfall approach, it really depends.

We value Agile a great deal, but it’s no process panacea. Sometimes another framework fits better. And I wanted to tell the tale of a team who is a good fit for Shape Up. After all, we always delight in the success of our portfolio companies, especially when they’re brave enough to take a risk that pays off.

If you want to find out more about Shape Up…

I haven’t covered the specifics of Shape Up because there are plenty of detailed guides and case studies out there already.

Here’s our recommended reading (or listening) list:

Related