Experimenting with a new way to Shape Up at TheFork
Since TheFork was founded in 2007, different methodologies have been used to create the products it now offers. You may be familiar with our B2C app (soberly named TheFork), especially if you are a restaurant aficionado like us. However, chances are you’ve never heard of our B2B product, TheForkManager. This is an ERB (which stands for Electronic Reservation Book) that allows our partnered restaurants to manage their bookings, floorplan, and a lot more. Don’t hesitate to check out our website if you want to know more!
TheForkManager is built by a team we called Supply featuring multiple smaller teams composed of 4 to 6 engineers, an engineering manager, a product manager, a product designer, and a QA Engineer. Each team follows the Shape Up methodology. As with all methodologies, it is subject to adaptation when real life comes in and we are no exception at TheFork. Each team is free to adapt the methodology to match best with how its members work and to find the most efficient way to build the best ERB on the market.
I arrived at TheFork in May 2020, after a long and difficult period for the restaurants. I was part of a newly created team with Pierre as Engineering Manager (check out Pierre’s story on his first steps as a Forkie). From 2 persons, the team quickly grew to 11 engineers, split into two mission teams. It means we had to find a way, our way, to work together and to onboard the newcomers in the fastest and best way we could. What follows in this article is the method we are currently using.
Cycles and steps
We are using the ShapeUp framework, which revolves around 6 weeks of delivery followed by 2 weeks of “cooldown”, which we use to tackle our technical debt. If you read french, you can check out this article detailing how we work with ShapeUp.
Step 1: Discovery & Framing
Throughout the year and for all future cycles, we explore the needs of our restaurants. We meet restaurants, salespeople, trainers, software engineers… Everyone is invited to give input during this step. We believe everyone can contribute and offer a different point of view that could be useful. It’s creating a deep understanding of our customers and we are using that knowledge to build vital products. While discovering the needs of our customers, we try to maintain the habit of correctly framing the problems we find out. Framing is a habit developed by Teresa Torres in Continuous Discovery Habits, which we try to stick to when discovering.
Who?
- Product managers
- UI/UX researchers and designers
- Engineering managers
- Software engineers
- Everyone who wants to get involved
When?
- Continuously
Output.
- User research
- Opportunity Solution Tree
Step 2: Shaping
Once the problems of our customers are clearly defined and categorized, it is time to find solutions. We shape the features answering these problems altogether, within the team. To be efficient during this step, we are using a template (you can find it at the end of this article) that we fill up for each of the problems and ideas we discovered. This step is the moment to list and describe precisely the solutions, draw the first wireframes, list some KPIs, and highlight the no-goes. This step is crucial to properly implement the solutions to our problems. Exploring each path is a way to anticipate future issues we could encounter. What is really important here is that a shape may not lead to a feature. If it is determined that the problem or the idea we had is not a priority or could be answered in a completely different way, we simply do not move on to the next phase with it. It’s not a waste of time, on the contrary, we believe we spared ourselves some hazards down the road.
Who?
- Product managers
- UI/UX designers
- Engineering managers
- Software engineers
- Architects
- Data team
- QA
When?
- During a cycle, for the next one.
Output.
- A shaping document
Step 3: Technical analysis
After shaping a problem, we are (finally) starting to get into the technical details. This is something we do with a smaller scope than the shape. A shape can lead to the conclusion that we need a single feature to answer a problem, but sometimes it is decided that multiple features are needed. In this case, each feature is analyzed through a document. Once again, we are using a template to do this analysis. Sometimes, the feature is really simple and straightforward, so we just skip this step. We do not believe in writing an analysis for the sake of writing.
The technical analysis is also a way to generate some technical documentation before starting to code. We plan which service is going to be impacted and draw some diagrams representing the changes we are going to make. During this analysis, we explore the technical solutions we could use to implement the feature. If we judge that the choices we have to make imply a higher scope in the architecture, we write an ADR (Architectural Decision Record) that we submit to our architects to help us make a decision.
At the end of this step, we should have a clear understanding of how we are going to implement the feature. It allows us to make an estimation of the time needed to do the work and plan a roadmap accordingly.
Who?
- Software Engineers
- Engineering Manager
- Architects
- Data team
- Code owners (read our article about code owners)
When?
- During a cycle, for the next one.
Output.
- A technical analysis document
- An ADR, if necessary
Step 4: Tickets creation
Once the technical analysis is done, we create tickets that we will handle during the next cycle for our delivery. We currently are using GitHub, but we try to not be tight locked to a single tool so we can easily switch if necessary. We just made the switch from Jira and with this mindset, the migration was quickly and easily done.
Creating the tickets basically mean splitting the feature into technical tasks we identified during our technical analysis. Dividing the feature into tasks is important as we may be several engineers to work on it and correctly splitting allows us to distribute the workload easily.
We are also using a ticket template, even if it is not mandatory, it is a guide to not forget some important information such as a link to the designs, for instance.
Who?
- Software Engineers
- Engineering manager
When?
- During a cooldown, for the incoming cycle.
Output.
- Tickets. 😄
Mastering the dual-track
The steps I listed above are essential, but the key ingredient to our delivery recipe is to achieve them through a dual-track. This means we need to do all of that while delivering other features, during the previous delivery cycle.
Doing it last moment, or during cooldowns, leads to:
– Time pressure on the team
– Rushed work which leads to not exploring some paths for our solutions or to unanticipated problems
– Bottleneck with the teams working with us: designers, architects, …
Having a dual-track allows us to anticipate better and be even more creative in our customers' solutions. The brain is a muscle that needs time and finding the perfect solution cannot be done in a few hours, it needs to go back and forth between thoughts to stimulate our creativity and our problem-solving skills.
This is why we shape our features weeks in advance.
Conclusion
Building a great product is not an easy task. It’s even less easy if you apply a method that doesn’t fit your team.
The method described in this article is what works best for us for now. However, we are constantly making it evolve to match our needs. ShapeUp is a framework on which we’re building blocks, moving them as we go, and we are not afraid to remove them when we feel they don’t serve a purpose anymore. This way, we make sure our processes are clutter-free and each of us can focus on delivering a great product.
If our story convinced you to try ShapeUp, don’t forget to give your team the space to invent and own its processes on top of the framework.
Bonus: Our templates
These are the templates we use throughout the process. Feel free to adapt them to your needs!
Shape document
# 🙋♂️ **Problem**---The raw idea, a use case, or something we’ve seen that motivates us to work on this# 👩🔬 **Solution**---*The core elements we came up with, presented in a form that’s easy for people to immediately understand.*- **Details solution**
- **Rules**
- **Edge Case**# 👨🎨 Design---*A few wireframes to materialise the idea, it is necessary to remain succinct. If this is not enough with our design system and a design validation at the end of the chain, we will also add the link to the official models.*# 📊 KPIs---*KPIs to be set up and monitored following implementation. They should verify the use and performance of the solution. They should allow a conclusion of success or failure to be reached and may contain a target.*- **Business Impacts**
- **Tracking**
- **Tech performance**# 👉 Attention points---*Details about the solution worth calling out to avoid problems anything specifically excluded from the concept: functionality or use cases we intentionally aren’t covering to fit the appetite or make the problem tractable*- **Rabbit holes**
- **No-goes**
- **Dependencies**
Technical analysis document
# 🤗 Context---*Describe the feature concerned by this analysis and its background. The description must be short and straightforward but must contain key elements.*# 👨🔬 Current implementation---*Describe the current implementation of the feature. How the components interact together, and how the services communicate with each other. You can use schemas and graphs to clarify the different flows. Provide screenshots of the UI if necessary.*# 🧪 Possible implementation---## Summary*Summarise the solution you will implement to complete the feature.*## Risks*List here the risks/difficulties you may encounter when implementing the solutions. These risks will be considered when evaluating the time required for the implementation.*## Advantages*If multiple solutions are studied in the Analysis, list the advantages of this solution compared to the others (performance, retro compatibility, ...).*## Touchpoints*Detail the implementation by listing and describing briefly the changes required in the codebase.*
Ticket
## 💡 Summary*As*
*I want to*
*So That*## ℹ️ Detailed Solution*Give a more detailed description of the task and solution that needs to be implemented*## 💻 Technical Analysis*Link(s) to the technical analysis (if relevant)*## ✍️ Additional notes*If you want to add anything to the description!*
