But the big thing to talk about today is Shape Up. I just finished re-reading the book and have a huge list of items I want to start implementing in my own practice. I am sharing a few below in case they may be helpful in your own work.

First a quick intro to Shape Up.

Shape Up is a product development framework that was born out of internal practices at Basecamp. They eventually codified these practices and made them public. Shape Up runs counter to many of the current conventions in software development. Despite being different and new, Shape Up works. The quality of product produced by Basecamp (I’m using one to publish this), as well as, dozens of other companies who have adopted Shape Up, demonstrate its efficacy. If these new ideas peak your interest, you should read Shape Up for yourself. It’s free online, or if you prefer a hard copy like myself you can get that here.

With that background in place, let’s get into some of the highlights:

When I was in graduate school I subjected myself to the full gamut of management frameworks. Lean 6 Sigma, Traditional Project Management, Agile, Scrum. In each course, I was struck by how much personal conviction and zealotry the instructor held for the framework. They truly believed that their specific discipline was the only way to get things done. This created dissonance for me, trying to reconcile how 4+ different ways of doing something could all be the one right way.

What I found out when I got into the real world was that none of them are 100% effective. They all have good elements and bad. The real task is being able to understand your situation and your team, and then building a framework that works best.

Shape Up is intended to be used in this way. You shouldn’t follow the book 100% verbatim. Rather you should determine which elements of the approach work for you, which need to be adapted, and which need to be dropped.

This is not so much a part of the Shape Up framework as it is an emphasis on how to work. Working in tech and startups there is always a feeling of being behind and of needing to go faster. What this usually translates into is everyone working insane hours, all the time, even if there isn’t anything critical to do.

The better approach is to work hard, on the things that matter. When that is done take a rest and recharge. I have heard this summed up as "work like a lion". Leave yourself prepared to do your best work when it is really needed, instead of doing marginal work, all the time.

Estimates are the norm in software development, but it's time to ask why. Estimates are usually wrong and focus on how long something will take rather than if something is worth doing in a given timeframe.

Appetites flip this idea on its head. You start with a set amount of time and then have to decide: should we do this thing? And if so, how can we do it in the time allotted?

My favorite part of appetites, that is not in the above excerpt, is that they have a circuit breaker at the end. This means that at the end of a time period if a feature hasn't been delivered, it doesn't  automatically carry over to the next sprint. Instead, by default work stops on it, and if we still want to pursue it, a new appetite must be set for it. This prevents cases of the feature that is never done or never delivered but always in development. Either you build it all the way or leave it behind and put your resources behind something more worthwhile.

Shape Up puts lots of value into the mapping out of interactions with a feature/application/product. It’s a tool for discovering natural user flows and uncovering blind spots in thinking.

One area that Shape Up doesn’t cover with workflowing, where I have seen great value, is in working with data. Specifically when designing data products. For me a key step in the design process is creating workflows of both the processes that create the data and how it will be used once it is productized. 

The first set of workflows help to ensure that you truly understand the data you are using. And the second set help to uncover potential gaps in the data product or ways in which it could be misused.

The takeaway is no matter the feature or product your are building, there is value in spending the time to map out how users will interact with it.

Once a problem or issue has been identified there is a tendency to want to jump right into crafting a solution. The issue with doing this is that we are often not the best person to craft a solution. That work is best left to engineers and designers.
 
In fact if we venture too far down the solutions road, we can cause some major issues. As a leader and stakeholder our opinion carries weight. Those we work with may not want to go against the grain and may pursue our design even if it is not best. We may also mask some major gaps or unknowns by presenting a too polished version of the problem and a potential solution.

Instead we should present the problem in as raw as form as possible, and then empower the experts to determine how to best tackle the work ahead.

One of the most powerful ideas in Shape Up! I can't calculate how much time I have spent looking at items from years ago, that may or may not matter, but we are too afraid to throw out.

Instead of cataloging every request and every idea that was ever imagined, Shape Up focuses on what is important right now. The idea being that focusing on anything other than your current work is a drag and a distraction.

For those worried that great ideas will be lost if there is no backlog, rest assured that truly great ideas will keep coming up again and again. If it really matters to customers they will keep asking you. No need to keep them in a list that you check occasionally, spend hours rearranging, and then decide to ignore ,in favor of working on other things.

Once something has been identified as something to potentially be worked, you don't dive right in. Instead you have to craft a pitch. This pitch lays out what you are trying to solve, how much time you are willing to spend on it, things that your solution must do, tangents to avoid and things you explicitly won't do. This pitch is then used just as the name implies, you present it to a group who decides if it indeed will be worked.

If it is selected then it gets assigned to a team to get working. If it's rejected then it is either never done, or you can rework it and pitch it again at a future time.

This concept democratizes the roadmap. It prevents one person from dictating what is on the roadmap. And even when something seems to be an obvious fit for the roadmap, it still has to be shaped in a way the group agrees to before it can be worked.

Once something has been pitched and selected it’s given to a team who will focus on that work in the coming cycle. Going back to the idea of not over-solutioning, the entire pitch prepared problem is given to the team. It’s their responsibility to define the work to be done and to deliver by the end of the cycle.

There is a a fear of engineers and teams not having enough to do. This is often countered but throwing together a bunch of stories and tasks we assume they should do. This approach leads to wasted time, chaos and rework. Instead of trying to pre-populate a list of work for the team, we set them up with the pitch and then trust them to figure out what is needed. Better to let them get started with a general direction, and let them figure out what is needed as they explore. Then to set them off working on a bunch of tasks that we later discover were meaningless guesses.

Many, if not all of us in the tech space, are perfectionists and obsessionists. We want our work to speak for us and we want it to say only the best things. But if we’re going to truly deliver for customers and get things done we need to reframe our thinking. We shouldn’t be focused on if an idea is perfect or even “good enough”. Instead we should anchor our thinking in how do we deliver value to customers as quickly as possible. Delivering value over perfection is what is going to keep the company alive, and let us continue to do the work we love and pride ourselves on.