In a BeforeDevBreak session, inviting a Tech expert to illustrate a problem experienced and solved within his or her organization and supervised by Talent.io, Simon Elcham, our CTO, spoke about the Shape Up methodology, which we have adopted for over two years now.
Shape Up is a product development methodology that reinforces efficiency, collaboration and delivery within Product and Tech teams. While structuring its team and looking for a way to build a robust and at-scale Product, Trustpair decided to adopt the Shape Up methodology in 2019. In this live sessions that you can find here, Simon shared his experience on how to setup such a disruptive way of working for its teams, and the results that show it today.
Simon has worked for more than 10 years in the SaaS industry; first in the design and development of product, then in managing of a Tech team. He founded Trustpair in 2017 with two associates : Baptiste Collot and Alexandre Gillier.
A time-consuming and disorienting process
“Back in 2018-2019, when the company’s activity was definetely started and running, we witnessed important pains in our processes.”
Our initial working process was focused on the Agile Scrum Organization and everything was done on Gitlab. We established a roadmap every week by separating our different priorities into categories (P0; P1; P2; PX…). We were based on cycles of 2 weeks, the next one was 3, then the next one had 2, and so on.
Here are the main pains we faced at Trustpair:
- Time: the time delivery of each of our accomplished projects often exceeded our predictions and expectations;
- The global questioning: a lot of open questions were raised during sprints which caused us a lot of struggle every time when we tried to develop new features;
- Need: we sometimes shipped features that weren’t pleasant for the customer base. They sometimes didn’t even need those. We put a lot of effort in it for a mediocre result;
- Vision: tech teams sometimes lacked of vision on it, didn’t understand why they were working on a specific feature. It didn’t only affect the tech team but the whole crew.
But that’s not all! Sprint periods were sometimes chaotic. At that time, we were entangled in:
- A lack of time to design each feature correctly;
- Technical debt pile up;
- Passive development handling tickets as they come (the 2 weeks cycles weren’t long enough to complete the main tasks and missions);
- Never-ending projects (guaranteed loss of motivation!);
- Unfinished tasks that went on to the next sprint;
- Way too many meetings.
Logically, it was the right time to question ourselves and make some essential changes in the way we do things and rethink the way we worked.
The wind of change
“Back in 2019, a member from my team shared a tweet from Basecamp; introducing the renowned Shape Up methodology. By the time i’m talking to you about it, we have been using it since 2 years already.”
Here are the main concepts of it:
- Shaping the work is the key. The whole methodology is based on defining the elements of the solution.
- No backlog! Important ideas come back (that means that you shall always start fresh when beginning a new cycle. A blank page, with new needs for your team and product). Focus on shaping the only feature that matters.
- Allowing full responsibility and autonomy to the involved team and members.
- Setting appetites instead of estimates (estimate the time the feature will be built in): how much money and effort do you want to spend on this specific feature?
The Shape Up methodology is divided into 3 phases
Shape phase:
It’s the dedicated track to prepare the solution to a need, you’ll have approximately 6 week to work on it. What do you want, and especially, what not? This is why you’ll need a clear view of the scope and define, at that point, a rough solution (without going into too much details). It’s also the right time to identify risks and rabbit holes. It will last 6 weeks, added to the construction phase.
Build phase
The construction phase assigns tasks to teams and gives them free rein (based on what was determined in the shaping phase). The project is split into different scopes. Milestones achieved and progress made are constantly shared. The decision to stop or define the “end” of a project is taken collectively.
Cooldown
These are two weeks between the Build and Shape periods. There is no assigned work. It is dedicated to a “debriefing” where we consider what to do next. This is the ideal time to fix bugs, explore new ideas. The cooldown ends the cycle.
What we implemented at Trustpair:
- We have opted for a 7 week cycle (5 week shape and build; 2 week cooldown);
- We considered that everyone could bring up new and efficient ideas : all the teams were involved in requesting features;
- The involved teams had an impact on Shape and also the Build, (we had no architect or side track dedicated to one step);
- We composed a new team on every cycle.
Our strategy:
Collect
- On every cycle, we collect requests about and on the next Shape
- The product manager meets all the team and helps specify the different requests and features
- Needs and ideas defined for the upcoming cooldown
We systematically asked 3 questions to the the entire team:
- What is my need/problem?
- What could we do to answer it?
- Why do I want this project/ What is the urgency?
Select
For the shape:
- Requests must satisfy our “ready to shape” checklist;
- Priotization using the RICE method (Reach, Impact, Confidence and Effort);
- Based on our ressources for the next cycle, we select the incoming project and create teams.
For the cooldown:
- The requests must satisfy our “ready to cooldown” checklist;
- Priotization using a simplified method;
- Process in order of priority, without prior commitment.
Create
- A new team is created for every Shape and Build;
- The product manager of the team is in charge of following the progress;
- Only one sync meeting a week on the Shape with the team and stakeholders if needed.
Our 5 weeks of Shape
Week 1: kick off and boundaries
Week 2: open and close as much questions as we can
Week 3: which solution are we going to work on (decision and choices)
Week 4: refine design, risk and rabbit holes identification
Week 5: finalize pitch and appetites
What do we call the Pitch? It’s the Shape Output, declined on 5 steps:
- Request overview: what is our initial need?
- Appetite
- Solution: functional decisions, technical conceptions, UI designs and wordings
- Rabbit holes
- No-gos
We accept to stop a project and drop the ongoing shape, if it ain’t progressing well, and if it exposes us to failure by building it. At week 2-3, if too many questions and problems remain unanswered, we decide to not spend any more ressource on it.
Tools for the cycle:
- Notion: for collecting requests and redacting notes for the shape and pitch;
- Gitlab (for implementing both the build and cooldown).
The Shape Up methodology, adapted to our challenges, our constraints could be summarized as follows: Involvement, Autonomy and Pace. Thus, we have been able to adopt this new model while refining it around our product, our culture, our team and our business.