TL;DR
This article outlines some of the challenges that development teams can face and how the Shape Up workflow methodology looks to solve them.
Here is an interesting thought...
A project's success might not always be related to how beautiful the design looks or performant the codebase is.
Let's consider these examples...
Can a designer create a user-friendly screen without a clear understanding of the actual problem the customer is facing?
Can a developer give an accurate time estimate without getting a chance to test out a new API they never used?
Can a product manager keep a project on track without being able to see what is completed and what is left to do?
Can a CEO sign off on a new feature without feeling confident that its benefit will be worth the time spent on it?
Often times great ideas and the talented teams executing them succeed when pivotal workflow areas are also successful.
Discovering the Shape Up workflow methodology
Recently I was introduced to a process called Shape Up that looks to solve many of the issues mentioned above.
It was developed by the team at Basecamp, a company that builds project management software. (Seems fitting.)
They found it worked so well on shipping (lanching) their own features — they turned it into a book to help others.
"Shape Up: Stop Running in Circles and Ship Work that Matters".
I just finished reading it and am so excited to start using this at work!
Below are my key takeaways for each chapter. There is a lot more in the book, so be sure to read it afterward as well!
Chapter 1: Introduction
This chapter outlines the common challenges the Basecamp team saw when shipping new product features. It establishes their "why" for formulating Shape Up.
🙌 What stood out to me...
...the overall structure of the Shape Up methodology. All of their principles (and book chapters) are divided up into 3 main sections.
Shaping (Ch. 2 – 6)
Betting (Ch. 7 – 9)
Building (Ch. 10 – 15)
These sections made it easier for me to understand where and why stages exist where they do.
Chapter 2: Principles of Shaping
A key concept in Shape Up is called Shaping. This is the process of deciding which problem to solve and figuring out what is needed to solve it.
The goal is to take an abstract idea and turn it into a well-defined project for the team to build.
🙌 What stood out to me...
...is this shaping stage is done in private with 1-2 senior team members. It allows them to quickly and freely run through ideas without being distracted by (usually well-meant) input from others.
The coming chapters will explain in-depth the properties that make shaping process successful.
Chapter 3: Set Boundaries
When shaping an idea, one of the first things done is to set boundaries on it. This helps clarify what the project should be about and where it should stop.
🙌 What stood out to me...
...was one of the boundaries called setting an appetite.
This is where the product team selects a pre-determined timeframe called a cycle and then designs a realistic solution that can be executed within it. Once the cycle ends, whatever work is done must be shipped or everything is scrapped.
Contrast this with creating a "perfect" design first and then estimating it afterward. Sure it looks great, but it might take 6 months to actually ship.
Chapter 4: Find the Elements
Next, the person(s) shaping will conceptualize what to build.
For example, if the goal is to "add an auto-pay option", this is where they will decide what screen it should be accessed on.
🙌 What stood out to me...
...was the emphasis on not trying to solve design problems at this stage.
Building a wireframe now would only slow the brainstorming down and take choices away from the designer later on. Instead, it was recommended to draw sketches with a fat marker which are visual, but not overly specific.
Chapter 5: Risks and Rabbit Holes
After a tangible direction is shaped, it is vital to identify as many potential issues as possible.
Some potential issues posed in the book...
Does this require new technical work we’ve never done before?
Are we making assumptions about how the parts fit together?
Are we assuming a design solution exists that we couldn’t come up with ourselves?
Is there a hard decision we should settle in advance so it doesn’t trip up the team?
🙌 What stood out to me...
...is how unresolved core questions are not passed down to the design or development team.
As much as possible the approach is worked out in the shaping process, so there are minimal unknowns. If there is an obvious grey area, it doesn't make it into the cycle.
Chapter 6: Write the Pitch
Now that the solution has been shaped it is time to pull all of the information into a concise pitch.
Included sections...
- Problem
- Appetite
- Solution
- Rabbit holes
- No-goes
🙌 What stood out to me...
...is how the Pitch puts all the cards on the table.
It is advised to clearly define the problem, in addition to the solution. A well-defined problem will give context to why the proposed solution is the right one.
Any potential issues are also highlighted so well-informed decisions can be made.
This also includes specific features that should not be built as part of this project.
I love how the goal is not about building the ultimate project, but rather the most realistic and therefore impactful one.
Chapter 7: Bets, Not Backlogs
Unlike an Agile model, there isn't some large central list of feature requests that get constantly added to and reprioritized.
Instead, key stakeholders only decide or bet on a few pitches for one cycle at a time.
🙌 What stood out to me...
... were pitches that are not selected for a cycle, are also not preserved in an official way.
By not tracking pitches officially, there isn't an overwhelming list of features to consider when it is time to plan a cycle.
Also, pitches that were not picked could usually stand more shaping. An individual team member could always re-work it and re-present it for a later cycle.
Chapter 8: The Betting Table
The key decision-makers (CEO, CTO, Product Manager) will meet before a cycle and determine what should be worked on. They place bets on pitches they feel are worth the risk and time investment.
This meeting is very focused and productive. Key areas are predefined, which gives this leadership team parameters to place their bets on. This gives them confidence.
Cycles are usually only 6-weeks long. (2-weeks for really small projects.)
In between cycles there is a 2-week cool down period to plan the next cycle, fix bugs, and work on misc projects.
The team building the project is usually a designer, 1-2 programmers, and sometimes a QA specialist.
Once the cycle is done a circuit breaker happens. That means if the project isn't finished, the deadline can't be extended and the project is scrapped. (In most cases.)
🙌 What stood out to me...
...because there is a real belief (bet) that the pitch is worth building, leadership will let the product team focus fully on it.
In other settings, a programmer might work on 4-5 different projects in a day. But in this setting, if the project doesn't get done in the 6-week cycle, that is it. The investment would be lost.
With Shape Up, product teams are given the space to focus on just the project(s) dedicated in the given cycle. This uninterrupted focus sets them up for success.
Chapter 9: Place Your Bets
In addition to the parameters described above, leadership takes into account what they are actually building. Is it adding a feature to an existing product or starting from scratch?
🙌 What stood out to me...
...when building a new product the standard stages change, but the core principles of shaping and cycles stay true.
Stages for new products are defined as R&D, Production and Cleanup.
For example, in the R&D stage, the shaping and build phases are typically carried out by only the senior members of the company.
Work done during an R&D cycle is not to ship, but to validate assumptions. If at the end of the cycle the leadership team confirms that feature A didn't pan out, then that is still a win. It means that the product team should probably focus on feature B later on.
Chapter 10: Hand Over Responsibility
Now that the pitch(s) has been approved, the cycle can begin! Product managers release the details to the designers and developers to start building.
🙌 What stood out to me...
...a lot!!
This is a short chapter, but probably one of the most impactful for me personally.
Coming from an agency background, every minute spent on a project needs to be tracked against a pre-defined budget.
I'd often feel guilty for spending time getting oriented at the beginning instead of jumping straight to InDesign or Figma.
In this chapter, it says that the first few days are expected for work to not looks like "work". Managers understand that the team needs to take some time to try solutions out, before jumping into "real production".
Specific tasks are also not given to the team. Rather they have the freedom and responsibility to tackle the project as they see fit. (More on that later.)
Chapter 11: Get One Piece Done
To help make meaningful progress, it is advised to work on one full slice of the project at a time.
What this doesn't look like...
Working on sub-features A, B & C in order and starting with the design, then development, then QA, and then presenting.
Working on just sub-feature A, but still starting with the design, then development, then QA, and then presenting.
Instead, the designer should rough out the core HTML elements needed and the developer can connect them to the database.
If they see the very rough version works, they can show it to their manager. If it looks good then they can really flesh out the design and code.
🙌 What stood out to me...
...these pieces should be small and related to the core feature. That way a simplified, but technically working iteration can be done and validated in a few days.
Because it is also a "core" aspect of the project, future pieces will be informed by it and time therefore saved.
Chapter 12: Map the Scopes
The pieces of the project are actually given a more official name called scopes.
A scope is a collection of tasks that allows a meaningful part of the feature to be fully completed. The tasks inside it are not role-specific (design vs development), but rather structure-specific.
For example, a project to add an auto-pay feature might include a scope to build just the confirmation email on payment. The tasks within it would include everything needed to finish it: designing the layout, writing microcopy, coding the HTML, and connecting it to the mailing server.
🙌 What stood out to me...
...was that scopes grow naturally over the course of the cycle.
I found this to be true in many projects in the past. Despite my best efforts to map out tasks ahead of time — new ones pop up as production progressed.
I love how Shape Up is so open to this. It gives more freedom to the designer & developer to create their own tasks as needed.
Chapter 13: Show progress
Speaking of constantly adding tasks to scopes... How does a manager tell when something is actually close to being done?
The concept of the hill is used to visualize where a given project's progress is really at.
Imagine a literal hill with an up-slope on the left and a down-slope on the right.
The left side of the hill represents the "unknowns". Any scope that requires research on how to execute it will be more to the left. The further up the hill, the clearer the solution is to the team.
The right side represents execution. The team knows what to do to make a scope happen, but just needs to actually design/code it.
🙌 What stood out to me...
There is a wonderful example given in this chapter of how the hill relates to cooking. Highly recommend reviewing it.
This chapter also illustrates why the hill enables managers to see possible scopes that "stuck". If it is lingering on the left side for a week or two, then it becomes apparent that some support around it might be helpful.
Chapter 14: Deciding When to Stop
So this is an age-old question...when should we stop working on a feature? We know already that the project is done when the cycle ends. But is it really worth stopping? Is the result good enough?
🙌 What stood out to me...
...of the many great points discussed the baseline made a lot of sense to me.
Don't compare what the feature could be if we threw more time and talent at it. That would be the ideal product.
Instead compare it to the current product that the customers are using. That is the baseline.
If shipped in its current state, would the feature improve their experience in a real way? (Not perfect, but better than before.)
If the answer is yes, then that is a win.
This mindset helps the team cut out extra pieces and just focus on the 1-2 core parts that will directly help the customer. It is better to execute the core items really well than 5 things "ok" because of not enough time.
More additions can always be shaped and added overtime in future cycles.
Chapter 15: Move On
That awesome (maybe slightly terrifying) moment comes and the feature is shipped! Now what?
🙌 What stood out to me...
...is how Shape Up sticks to its principles even after launch.
There will probably be a lot of post-launch feedback, both negative and positive. But it is important to remember that all new features have to be shaped first.
Just because it sounds like a good or even urgent addition, it needs to be weighed against the pros and cons of everything else.
Staying intentional will keep the team on track, morale high, and features of high quality over time.
Thanks for reading!
I hope this summary of key takeaways has piqued your interest in reading the full book. It is really well written and has great examples and illustrations to help highlight their points. Plus it is free and online. :)
"Shape Up: Stop Running in Circles and Ship Work that Matters".
But, let me know your thoughts! Have you used Shape Up before? If you did, how was your experience? What other workflow methodologies have you used and found successful?
Until next, happy coding! 🤓
Thumbnail designed with Adobe Photoshop
Top comments (0)