Shape Up, Shaping vs Building

It is one of the articles in the Shape Up series. For Table of Contents go to: Shape Up, Introduction

Same shit, different naming

The whole process from idea to production might be called differently. Shape Up hasn’t invented the concept of separation, but it made it clear when the crossing line goes in this specific methodology.

If we take a look at different ways of producing the software, we may realize such stages:

No matter the religion, phrases closer to the left-hand side are here to answer What we will build, while phrases on the right-hand side focus on Getting the solution done.

The overlap of these two areas and the feedback frequency may differ depending on the methodology. The crossing line and its thickness are the main differences between the methodologies. Think where this line goes for your implementation of Shape Up.

It is worth keeping the Shaping & Building naming convention for Shape Up. It will enable people to look for it in a book and give them a sense of working with a new fancy methodology.

Explicit separation of Shaping and Building

When you start implementing the Shape Up, you need to understand the current state of Shaping and Building within’ your organization.

In most companies, the whole Shaping process happens before something goes into Jira. Most engineers have no idea where the stories are coming from. If you want to learn how to visualize these stages, I encourage you to watch Upstream Kanban by Radoslaw Orszewski or review a few images presenting the Double Diamong method.

In Shape Up, we want to raise awareness of the existence of the left-hand-side-phases. To do that, it is worth separating Shaping and Building explicitly. This is the moment to let everyone know what these phrases mean and what they will look like.

Make it clear and explain What Shaping means? and What Building means?. Also, share your expectations on Who should participate in which phase?.

Usage of non-Shape Up methods

As there are many similarities in Discovery/Shaping - Delivery/Building processes in various methodologies; this is wise to use techniques popularized elsewhere.

For both stages, you may use such the methods or at least take some inspiration from:

• Personas
• Competitive Analysis
• Unfair Advantage
• Customer Interviews, Surveys, Visits
• User Journey Mapping
• User Story Mapping
• Impact Mapping
• Event Storming
• Jobs-to-be-done
• Opportunity Solution Tree
• Mind Mapping
• Prototyping
• A/B Testing
• Double Diamond
• Value Stream Mapping
• MoSCoW
• Vertical Slices
• Increments
• Kickoff
• Planning
• Health Checks
• RAG Light
• … and many more.

Just think twice, do not over-complicate, and adjust it to your own needs within’ Shape Up.

Each framework sets up the mindset

And do not get me wrong - while the methodologies bring many similarities, and we may see the same big picture process everywhere - each methodology comes with a specific mindset. Techniques are easily transferable, but choosing a particular workflow framework will strongly influence the thinking around how your team wants to work.

Shape Up seems to be the choice for high autonomy, understanding the users, giving trust from the leadership to the teams, and keeping developers creative and proactive. Shape Up may help you build very mature teams made of people willing to build high-quality, meaningful things. Many Mid-Level Developers grown within’ Shape Up will act like Lead Devs grown in Scrum environment.

In the following article, we will answer the simple question Who does the Shaping?.