Shape Up: Practical Lessons from the First Cycle

Salsita is always on the lookout for new ways to speed up development without sacrificing quality and design. About a year ago we incorporated Design Sprints into our design process and have been happy with the results. A couple of months ago we adopted another product management methodology with excellent results: Shape Up.

The Shape Up Method was created by Basecamp and it is based on their own product development approach. The method aims to better define and prioritize projects before handing off to teams to build and ship. – Product Plan

Why Shape Up? At Salsita we are focused on delivering great results on time and on budget. When Basecamp published the methodology they had been using for years to define and manage development projects, we felt immediately that it would be a good fit for us. Shape Up allows us to give our clients predictable timelines, increases transparency, and helps us identify which features bring the greatest value to our clients.

We first tried Shape Up a few months ago while creating a web-based 3D car configurator. This article will give you a brief explanation of Shape Up and the practical lessons we learned from our first cycle.

WHAT IS SHAPE UP ABOUT?

Shape Up differs in a few significant ways from traditional agile methodologies like Scrum. Instead of one or two week sprints, Shape Up is a six-week cycle followed by a two-week cool down period. The goal is clear: break the routine of never-ending sprints and focus on shipping specific deliverables within a predictable time frame. Development is followed by a cool-down period for refactoring, small improvements, and figuring out what the team should focus on during the next six-week cycle.

Another important difference is that in Shape Up you don’t create user stories, estimate them, and then put them into the sprint. Instead, you create a comprehensive proposal for a mini-project and let the development team self-organize around the scope you established.

The proposal has the following key characteristics:

1. Problem: Clearly define the problem to solve
2. Appetite: Establish how much time the team should spend on the problem
3. Solution: Describe a high-level solution, e.g., with rough sketches
4. Risks: Explore any edge cases or risks that could jeopardize the mini-project
5. No-goes: Have clear boundaries for what is in scope and what is not

HOW DO YOU ACHIEVE PRODUCTIVITY?

Basecamp is vocal about creating a distraction-free environment in order to achieve high productivity. Every little distraction can cost 20 minutes of developer time before they are able to get back into a productive state.

They also recommend that your team should be made up of just two or three people in order to enable clear communication and reduce bureaucratic overhead.

If I were to summarize their approach into imaginary formula, it would look like this:

In order to be productive, limit the number of meetings, avoid unnecessary Slack conversations, and don’t waste time on bureaucratic decisions that don't bring value to the team or product, like unnecessary reporting.

If you can protect your developers from distractions, that’s half the battle. The second half is making sure that they are not wasting their time and energy on unimportant things. So, the team should not overcomplicate features, overengineer the code, or work on “nice-to-haves.”

TRUST IS KEY TO EVERYTHING

Trust is crucial and must exist between everyone involved: the team, the PM, and the client. If this is missing, the whole exercise is likely to fail. If you establish trust between all participants, the team will have freedom and a sense of ownership, which creates motivation. On the other hand, the team needs to be accountable, reliable, and responsible for what they’re doing. They need to work independently in a proactive way

That is a simplified overview of the Shape Up Method. Now let’s take a look at how we applied it in practice.

PRACTICAL LESSONS WE LEARNED

A key element of Shape Up is preparing a thorough proposal for a six-week mini-project. The goal is simple: Have a clear description of what needs to be done so the development team can work independently without major product discussions for the following six weeks.

Earlier this year Salsita Founder and CEO Matthew Gertner came up with a vision for creating a 3D configurator SDK that would allow us to create web-based 3D product configurators for our clients more effectively. When you start a big project like this, there are many unknowns. That’s why we decided to create a demo 3D configurator first. We decided to reimagine a car configurator using modern best practices for UX and software implementation.

Car configurators are complicated products. To do good “shaping” (Basecamp’s term for preparing the proposal for a mini-project), we decided to run a four-day Design Sprint. Design Sprints are a great way to define requirements and scope before the development cycle starts.

During the Design Sprint we explored current solutions on the market, identified the biggest pain points, prepared proposals, selected the best ideas across the proposals, and put everything into one common concept for a car configurator.

I feel this was beneficial and was one of the reasons why the first Shape Up cycle was successful. A UX deep dive is a really good approach, especially when you have a big feature and you’re not sure how it should work. Either someone needs to spend days and weeks preparing it or you could do it as a team in a four-day Design Sprint. Design Sprints and Shape Up are a powerful combination.

KICK-OFF CALL

When we finished the Design Sprint, we decided to do one more iteration of the clickable prototype that UX Designer Katerina Kelepouri had created in Adobe XD. After the second iteration we felt that we had tied up all the loose ends. I then transformed the results into a Shape Up proposal for a six-week mini-project.

In the kick-off meeting we first reviewed the proposal to make sure that it was clear to everyone. Most of the development team was part of the Design Sprint, so they already had a good understanding of what we were trying to achieve.

The most important purpose of the kick-off call was to clarify and communicate the goal for the six-week cycle. Why? The team has a fixed deadline and, as we all know, managing software scope is tricky. Developers can always tweak their code architecture, QA and UX engineers will find small improvements to make, and PMs can always see just one more little feature to add.

Everyone needs to make compromises in order to meet the deadline. With a strong grasp of the sprint goals, they will be empowered to make good decisions about priorities. Less critical items can wait until the cool down period or another cycle.

In our case, the goal was simple: build a configurator that we can send as a demo to our clients and promote on our website.

Another purpose of the kick-off call is to discuss key aspects of the project. To this end we wrote down major elements that needed to be tackled during the development cycle. For us this included the app’s UI, 3D model, data storage, API, and a few other things. We had a short discussion about each element. We focused particularly on any risks and how we could mitigate them.

One of our biggest challenges was that we wanted to build the product configurator as an SDK. Trying to create generic solutions can massively increase project complexity and is thus a huge risk. Sometimes the best way to mitigate risks in software projects is by avoiding them all together, and this is what we ended up doing. We simply agreed not to focus on the SDK during our first cycle.

Then the team got to work.

THE BOARDS

Basecamp uses their own tools for managing Shape Up cycles with their proprietary to-do lists and a nice feature called a Hill Chart, which allows teams to show their progress during a project.

At Salsita we don’t use Basecamp, so we tried to recreate the same idea in GitHub. We used GitHub both as a code repository and project management tool.

We created two project boards. The first was called “Shape Up View.” It contained all the key elements we identified during the kick-off call with a list of tasks to be done. The board had five columns:

• Not started
• Unknown phase
• Known phase
• Finalizing
• Done

Every week during the catch-up call we went through the board and discussed progress with the solution’s key elements and any potential blockers.

The second board was a normal kanban board which served as the developers' to-do list. As the product manager I didn’t spend any time checking or organizing this developer board.

The separation between the developer’s to-do list and the project overview kept developers protected from unnecessary bureaucracy and distraction and, at the same time, gave me a good overview of where we were with the project.

HOW DEVS SHOULD WORK IN SHAPE UP

Around 80% of the Shape Up Method relates to how PMs prepare requirements for developers. But there are a few principles that developers should keep in mind as well.

Shape Up is self-organizing, which is why small teams are preferable. Our team consisted of Tech Lead Jiří Staniševský, Full-Stack Developer Mark Karpilovskij, and UI Developer Jan Bartůněk. They had daily stand-ups and often got into technical and UI discussions.

Sometimes QA Engineer Matvey Dorkin and UX Designer Katerina Kelepouri joined the standup if the team needed some QA and UX input. As Product Manager, I wasn’t attending the standups since I trusted them to do good work. They were responsible for organizing their tasks and deciding what they had to accomplish at various stages of the projects.

Since the Shape Up Method involves a six-week cycle, it is recommended to have a proof of concept within the first or second week. What you should try to do here is take the biggest tasks from your defined scope (or the ones that seem riskiest), explore them, and work on the “happy scenario.”

This approach helps to surface details and edge cases that need to be addressed. Once you know that the solution is doable, you can climb the "hill", leave the “unknown phase” and enter the “known phase.”

Having prepared a comprehensive list of items to complete, you can start prioritizing. If you realize at this point that you won’t have enough time, you can adjust the scope accordingly. You will likely have to make some compromises with respect to technology and UX. This is fine as long as you stay focused on the end goal. The most important thing is to focus on the key objectives even if some details are missing.

QA AND UX

I’m still figuring out the best way for QA and UX engineers to work on Shape Up projects. Nevertheless, I felt fantastic about the role of my QA and UX colleagues on the project.

Basically, they asked the main team a simple question: How can we help you? The developers told Matvey that it would be beneficial to prepare some mock data. Matvey prepared it and it really helped, especially for Jan, who did a great job styling the whole UI.

It was great that they self-organized and asked those "how can I help?" questions. It worked well.

On the UX side we started with the Design Sprint, so most of the work was done before the cycle started. There were many edge cases that were handled through regular cooperation between our UI developer and UX designer.

There were some downsides because we were working against the clock and there wasn’t much time for feedback. The main reason for this was we were trying to minimize distractions as much as possible and focus on our priorities. Constant suggestions from the UX designer can be very valuable but they also distract the developers, resulting in wasted time.

Apart from having less time for feedback and working to minimize developer distractions, overall, I felt confident about the entire process.

DEMO, COOL DOWN, PROS AND CONS

After six weeks the team showed off its final demo. They were really proud of their work and what they had accomplished in just six weeks. And rightly so. They fulfilled the goal of the cycle and prepared an impressive car configurator demo that we can show off on our website. They also prepared a good foundation for turning the configurator into a proper SDK that we will be able to use to implement different types of configurators in future.

Here are the main points that we discussed during our "post mortem" retrospective:

Pros

• Motivating: Most of the team mentioned that it was one of the best projects they’ve worked on so far.
• Enjoyable: The team enjoyed using the Shape Up Method and loved the interesting technical challenges of RxJS and 3D development.
• Successful: The team delivered a working car configurator that we can demo to potential clients.
• Predictability: The team’s goal was to deliver the car configurator in six weeks and they hit the deadline.
• Efficient: As the PM, I spent a lot of time in the shaping phase, but during the main six-week cycle, my involvement was limited to only one or two hours per week.

Cons

• Overtime: The team was really motivated and that led to accruing overtime in the last two weeks. Some teams might consider the hard deadline of the six-week cycle to be a plus because it creates urgency. In other cases the scope can be cut to avoid overtime.
• Unfamiliarity: Since it was our first Shape Up cycle there were some details that we needed to figure out on the fly. Obviously, this will be less of a factor next time.

The team was motivated and had fun; I felt that at every catch-up meeting. The predictability was also great because we knew six weeks ahead of time when the configurator would be ready to demo.

The team felt that the last two weeks were rushed. It was our first cycle, so there are still details to work out, such as the best way to fit QA and UX in the process. This methodology requires trust, so it might be harder to implement in the case of a client project. Leaving the team alone for six weeks requires a leap of faith but we are confident that the results will speak for themselves.

WHAT’S NEXT?

After having theoretical discussions about how we could use the Shape Up Method a full year ago I'm pleased that we now have some hands-on experience. We will be continuing to use this methodology for the ongoing configurator project and on other internal projects. Furthermore, we have one successful Shape Up cycle under our belt on a client project, have started using it on another client project (ADCO), and plan to propose it to other clients where appropriate.

In September we will do a webinar on Shape Up. We will be talking specifically about our experience using this method on our client projects.

Additional sources about Shape Up:

· Shape Up book by Ryan Singer

· Podcast with Ryan Singer about Shape Up

· Shape Up Forum to discuss with other Shape Up practitioners