Shape Up, Shaping vs Building

It is one of the articles in the Shape Up series.

For Table of Contents go to: How to make Shape Up successful?

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 clarified when the crossing line goes in this specific methodology.

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

No matter the religion, phrases closer to the left side are here to answer What we will build, while phrases on the right 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 methods. 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 Shape Up, you need to understand the current state of Shaping and Building within’ your organisation.

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

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

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

For both stages, you may use such 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

• Triple 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 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 a Scrum environment.

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

---