A Proposal to Implement ShapeUp Methodology

[Amzani]

Introduction

In this Issue that was also presented during our last planning meeting, we will explore a proposal for enhancing the workflow of the new Studio enhancements through the implementation of the ShapeUp methodology. The focus of this issue is to introduce you to the benefits of this methodology and seek feedback that can be applied to future projects within the AsyncAPI initiative.

This proposal is an experiment and a continuous learning experience.

Scope of this proposal

• The Shaping / Prototyping phase: Today this phase is implicit as an integral part in the build phase
• The Build phase : When the engineer translates the design and specifications into working code

Out of scope

• Discovery
• Measure impact
• Support

Outcomes

• Enable contributors to know if they are working on the right problems that make sense for users
• Encourage autonomy and ownership
• Using ShapeUp (or adaptation of ShapeUp) without knowing about it! - individual contributors don't need/have to understand ShapeUp in order to use it

ShapeUp

This methodology was created by Basecamp in 2019. Basecamp has gained recognition for their innovative and effective approach to project management. The methodology is explained in detail in their online book. Personally, I have experience using this method in a previous job at Back Market, and it proved to be highly interesting and yielded positive outcomes, It's also used by many organisations.

Why

Let's delve into why we are proposing this methodology. Firstly, it emphasizes the importance of defining the problem before rushing to find a solution. As engineers, we tend to be solution-oriented, but it is crucial to invest time in understanding the problem at hand. Time is a valuable resource, and we need to utilize it effectively by solving problems that truly matter.

Secondly, the ShapeUp methodology treats time as a first-class citizen. Projects are time-bound rather than scope-bound. This mindset shift completely alters how we approach feature development. By setting time constraints, we create a sense of urgency and prioritize tasks accordingly.

Another significant benefit is the encouragement of autonomy and ownership. In this methodology, tasks are not assigned; instead, problems are identified, and engineers have the freedom to choose the most suitable approach to solve them. This promotes a sense of ownership and empowers individuals to take responsibility for their work.

Read more about shapeup

Proposal

I've identified 3 personas that can have immediate benefits from this change

Studio users

As studio user I want to know what's coming next in the roadmap. For that users can check our ShapeIt board

Individual contributors

We identify 2 personas :

Shapers

People having big enhancements / ideas that we call Pitches and Bets as per ShapeUp terminology

Shapers are instrumental in driving roadmap success. Their main tasks involve creating a persuasive pitch to secure community votes, leading to project commitment and owner assignment. Once approved, the pitch transforms into a bet, which requires an initial scope that can evolve during the cycle.

• Example of a Pitch
• Example of a Bet

Builders

People building and iterating on the Bet scopes. Builders can also be shapers

As we don't want to disturb any of normal Issues > Pull request workflow the only quick task needed from builders is to link the issues they are working on with existing Bets (This is only relevant for Bet issues).

To link an issue to an existing Bet/scopes section, you can use the Related to keywork in your issue description. This will automatically track your new created issue under the Bet.

Example:

• Issue part of a scope
• Bet

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity 😴

It will be closed in 120 days if no further activity occurs. To unstale this issue, add a comment with a detailed explanation.

There can be many reasons why some specific issue has no activity. The most probable cause is lack of time, not lack of interest. AsyncAPI Initiative is a Linux Foundation project not owned by a single for-profit company. It is a community-driven initiative ruled under open governance model.

Let us figure out together how to push this issue forward. Connect with us through one of many communication channels we established here.

Thank you for your patience ❤️