Leadership at the Edge

Intro

Transitioning to Shape-Up has been a transformative journey. Shape-Up, a product development process from Basecamp, offers a unique approach with its fixed 6-week cycles and flexible scope. Unlike Agile, which is a one-size-fits-all solution, Shape-Up is tailored to specific needs, requiring thoughtful adaptation. Here, I’ll share my experiences, the challenges we faced, and the benefits reaped from this innovative methodology.

Shapeup focuses on managing risk by limiting projects to 6 week cycles. The scope of each project is negotiable, but the timeline isn’t. Engineers and Designers receive a project pitch which outlines the project scope. Pitch writers, usually leadership, define project boundaries using abstractions like breadboards and fat marker diagrams. The team then collaborates over the course of the 6 weeks to define details and build the project. Like in Agile, teams work in vertical slices to reduce risk and allow for early learnings. When the 6 weeks is up, the work stops and the team gets 2 weeks to cool down and tie up loose ends. The team will start a new pitch in the next cycle, even if the work was not completed.

Assumed Challenges

Once we had all read the book and thought about the prospect of switching to Shape-up, we had some upfront concerns.

What happens if we don’t finish the pitch?

Being able to work on something until it “feels” complete is a luxury we had to give up. This made many people uncomfortable. Engineers wanted to know, “what will happen if we get to the end of the 6 weeks and the project isn’t done?”

There seems to be an assumption at the core of this concern. The assumption that completion is an all or nothing proposition. Meaning if we fail to deliver all requirements, the entire project is a waste. This isn’t true. We break up our projects into small vertical slices. We then prioritize those slices. If we do this well, the requirements at risk will be the lowest value requirements. And if we deploy code as soon as possible, the most important features will already be in production. This is a great outcome. In reality there is very little waste. As the team approaches the end of a cycle, they become more aware of scope risk and can adjust .

How will we deal with legacy code and refactoring?

Our company had a lot of legacy code and our former engineering practices led to a lot of tech debt. Our test coverage was lower than it needed to be. Most of the original engineers had moved on and most of our team was relatively new. Because of this, any significant project started with lots of research. This is usually followed by a significant refactor to prepare the codebase. Then we move on to actual feature implementation. When the team learned that they would have to do this in a rigid 6 week line, they became concerned. The engineers wanted to know if there would be enough time to do research, refactoring and implementation.

The answer is, there is time if you make it. To make room for all this work, we would need to aggressively descope features. The feature itself would need to be small enough to allow for the research and refactoring time. The good news is that Shape-up provides for variable scope. With each cycle we have been able to find a scope that is small enough and yet still sufficiently valuable. As we progress through cycles, we clean up our codebase, increase our understanding and increasing test coverage. As a result, newer features require less research and refactoring than previous ones. This allows teams to deliver larger features with each cycle.

Will moving to cycles slow us down?

One of my initial concerns was that moving to 6 weeks cycles could slow us down. Before we moved to Shape-up we were doing Kanban. Kanban allowed us to move as fast as we possibly could. There were no arbitrary start or stop points. We worked on things as long as we needed to and moved on at any time.

Working in this way takes an enormous amount of restraint and self discipline. It’s critical to end projects as soon as they pass the point of diminishing returns. Unfortunately we didn’t have that level of discipline. As a result, although we had the capability to turn on a dime, we rarely did. We often worked on projects indefinitely. Teams would refine and improve with no end in sight. Although there was value in these improvements, they weren’t the most impactful thing we could work on. Having a hard stopping point at the end of 6 weeks, forces us to be ruthless with scope. We often have to make really difficult decisions, in order to have something deliverable in the time frame. These conversations wouldn’t have happened without that stopping point.

Actual Challenges

The majority of the challenges we face are related to pitch sizing and descoping. As mentioned, we have a legacy codebase that requires significant cleanup prior to feature implementation. This forces us to descope often.

Getting sizing right

For the pitch writers and the engineering team, there is a desire to get the size of the pitch right. When the pitch is so big that it requires a lot of descoping, the team feels like they’ve underdelivered. The pitch writers take the feedback and in an effort to do better attempt to make pitches smaller.

This is problematic however. For pitch writers to make pitches artificially smaller, they will need to ask for less than they want. Without the input of the engineers and designers, how will they know if they’ve made it too small? How will they know if they’ve removed the right requirements? There is risk that they will unknowingly remove something valuable but trivial. This would result in large impact to value and small impact to scope.

It’s important for all parties to remember that the appetite (6 week time box) is not an estimate, it’s more like a budget. The pitch writer is saying, “I want this functionality, and I don’t want to spend more than 6 weeks on it.” This is much like walking into a car dealer to purchase a car. You want the car to have a certain set of features, but the price should not exceed your budget. It’s possible that your feature list actually exceeds your budget. In that case, your dealer is going to try to get you into a car that is as close to what you wanted but still within your budget. (Actually, your salesperson will likely try to get you to expand your budget as well; just don’t give in.) When the pitch writer’s ask exceeds their budget, it’s the team’s responsibility to help them find a feature set they can afford. The conversations and rescoping that follow are the most valuable aspects of Shape-up. Engineers and Designers consulting with pitch writers to find the right scope is how you move fast.

Sticking to small vertical slices

Having a 6 week time box might disincentivize small slices and early deployment. In order to manage risk, it’s critical that work is deployed and put in front of users as soon as possible.

There are 3 concerns with large deploys:

1. Larger scopes reduce optionality and opportunity to pivot
2. Big deploys are more complicated
3. A single release creates an all or nothing situation. If you don’t finish you risk delivering nothing.

Small vertical slices and early deployment addresses all 3. Make sure your team understands that even in a 6 week cycle, our goal should be to deploy as many times as possible. Encourage them to define their scopes to allow for early deploys.

Uncomfortable uncertainty

very cycle begins with uncertainty for the teams. There is a tendency to feel like the pitch is too big and there is too much unknown to deliver on time. Once the teams get deep in work they feel more certain and the discomfort subsides. It’s a good idea to get engineers comfortable with this brief period of uncertainty. Make sure they see how quickly it passes once work begins. A few cycles of confident delivery should remedy this issue.

Actual benefits

Plan so that cycles can build on each other

Clear start and stop moments for projects provides more opportunities to coordinate projects. In nearly every cycle, team A has been able to benefit from something that team B built in the previous cycle. Allowing for teams to build off of each other’s work makes it so that we deliver more value with each cycle. Prior to shape-up it was difficult to know when a project would wrap and the teams were so much more siloed. Teams were more likely to get in each other’s way than they were to benefit from each other’s work.

Maximum value for minimum effort

The descoping discussions that come from having a time box are incredibly valuable. Without a budget for a project, there is nothing forcing the hard decisions. The team is forced to decided which features are critical and how to design so that we can deploy maximum value for minimum effort. Having that constraint forces prioritization and encourages creativity. The solutions we end up with are all high value low effort. This means we will achieve more with less effort.

Getting ahead of our roadmap

The combination of descoping and teams benefitting from each others work has actually put us ahead of where we thought we’d be in our roadmap. That’s a pretty rare place to be. We are consistently outperforming our expectations and it’s created more opportunity.

Pro tips

Make sure engineers understand the value of descoping. If they don’t, it’s possible they will feel like they’re underdelivering. Even when they are succeeding, it will feel like failure. If their previous goal was delivering everything product asked for, this will be an adjustment. If there’s guilt associated with not being able to deliver, the team will find it difficult to negotiate scope. Get them onboard with their role as consultants for product and leadership. The business is coming to them to help find the right scope. The right scope is one that delivers maximum value without sacrificing quality, timeline or team well being.

Engineering and Design collaboration is critical. Get designers used to delivering low fidelity designs as quickly as possible. Engineers want to get the first deliverable into production as early as possible. To do this, designers will need to deliver low-fi designs. These initial designs will be subject to change as the design evolves. In order for Designers to feel comfortable with that, they need to know it’s ok to change designs later. Engineers need to be comfortable with changing designs and the rework that follows. Coach your engineers to keep logic out of the UI, so they are easy to change. Make sure they always make designers comfortable asking for changes. This type of collaboration requires trust between designers and engineers. Once established, the benefit is enormous.

Some aspects of shapeup may not suit your organization as was the case for ours. We’ve tried to address these challenges by first attempting to implement by the book. We only make changes when we are certain we need them. This is to avoid the pitfalls of premature optimization. We’ve also had to be patient and avoid temptation to view Shape-up as the problem. Some small tweaks have allowed us to “shape” Shape-up to our organization and reap the benefits.

Summary

Shape-up has been enormously helpful. We’ve eliminated many issues and become far more efficient with product development. We’ve also discovered some new issues, but the tradeoff has been worthwhile. Of course, your mileage may vary. My aim is not to encourage you to adopt Shape-up. Nor is it to inform how you should go about adopting shapeup. My goal is to share my experience, so that it may help answer some of your questions should you find yourself on a similar path.