Sprint, races, and marathons — how we changed our sprints and improved our mental health
When we were just the three of us, surrounded by mountains, the cycling sounds of our bike chains would cut the air together with us poorly singing out loud. We sang so bad that we luckily even scared the rain clouds away. What was also scary, according to a more experienced bike friend, was how I was pedaling. According to him:
“You are pedaling too fast, you will lose pace and will not be able to follow us. Just stay behind and try to keep cycling at the same speed. Making the wrong effort will only tire you faster and slow us all down.”
After learning this lesson and some patience from him, the biking and awful singing routine was evenly conducted during 650km spread over 5 days while we crossed Korea by bike. Sounds like an epic story, right? Well, maybe, but today we will not delve into epics but focus on sprints and how we achieve cycling effort in order to not slow us all down, and keeping the pace to our objectives.
A bit of context and background
In the past, we from the Design Ops team at Creditas were turbo-bursting all the time dividing our work into a single week besides trying to understand how to adapt, and fit in meetings and work during that period. Still, we were having a hard time figuring out our pace as I was assigned as the new design leader.
To make it even harder, we had no stories, epics, or a person dedicated to product metrics and roadmap in our team, which makes understanding the pace and effort even more challenging to be figured out. All I could see was the team handling overly complicated work in weeks and, once finished, starting another complicated effort without breath.
As someone that did a whole master degree focused on mental health and how design can help against it, damn, I was ready to intervene not only as the professional but as a researcher. This other facade of myself started to bring two of my favorite methods to get work done: the Design Sprint, from Google Ventures, and the Shape Up, from Basecamp. “Why don’t we mix both adapted to our context?”, I innocently thought. Then, that sounded like a good idea.
The Design Sprint — Google Ventures
The Design Sprint is a methodology created by Google Ventures and aims to solve a problem within five days. Considering how the sprint works, the days are divided into 5 categories and in each of those, you have a particular focus and problem-solving mindset.
Companies around the world have created their own version of Design Sprint with their own adaptations and niche, such as the AI Design Sprint from 33a or the Hypersprint from Deepwork, or even challenges such as the Global Virtual Design Sprint facilitated by Robert Skrobe. Others have kept the original formula and improved upon it, such as the Design Sprint from Studio AJSmart, a German company that produces great content about it.
The main problem I see about Design Sprint is its lack of continuation. Doing one Design Sprint after another Design Sprint is not an effective method when we consider the number of people involved, and that, in a startup scenario, needs to really dive deep into technological aspects to make things work. This is the point where the Basecamp way of seeing things comes in handy.
Shape Up — Basecamp
According to the Shape up book, Basecamp runs its process in six weeks instead of five days, and divides how people work based on their own professional beliefs of what can be shipped — transformed into bets. Bets are an array of effort proposed by the delivery team towards a solution. The team starts working on those bets, spending effort and understanding, towards the development of it, a process which is very fluid but allows us to borrow the “ramp up” concept from it.
With high knowledge of their own bet, the team understands when they need to ramp up or still to better define the concept and technical challenges which should be tackled. After that decision, new technical definitions or features cannot be added, so the team can meet their deadline and the bet is finished in time. If there is something the team wants to explore or work further, a new bet must be made and roll a new cycle of work.
After the six weeks of work, there is a pause called cooldown. It is a two-week cycle where the team uses their product, refines with a border-radius their pointy edges, and shapes the next six-week cycle bets.
To sum up the concept, consider how a skill or superpower works in games. After you use a powerful skill you need to recharge the resource spent before you can use it again — that being mana, time, or whatever it was used as a source. During that time, you can only use “basic actions”, no superpower or skills. The main objective of having a cooldown time, at least in games, is an opportunity for enemies or different teams to explore and use their own abilities and ramping up, this way making it a competitive strategy concept. This can be seen in card games with the concept of cantrip and competitive MOBAs such as Dota2 or League of Legends. I was looking forward to applying this concept to work.
Then, I started to hypothesize: What would a Design Sprint with Ramp up and Cooldown look like?
When we look to both methods, one of them seems not feasible because, as my cycling friend told me before, “don’t do only turbo bursts or you will tire yourself out” — burnout alert! Looking to the other side, if we consider our work routine, making an 8-week cycle would not be feasible.
I just became a leader and still need to get trust from my team and myself to conduct such a long-term investment without experience and trust from peers. However, I ran Design Sprints before, so why not mix both and propose a 10 days Sprint? 🤯
The main objective was to turn a Design Sprint into a “Ramp Up Design Sprint’ and a “Cooldown Design Sprint”. The first week would consist of activities that work within scope, that need to be created, designed, developed, and so on. The second week would focused instead on cooling down, starting with a refinement session followed by reviews, code and design, and most of the team 1:1 meetings. After the sprint ends, we wrap it up with a classic retrospective on day 9 and we leave day 10 as a “free day”.
I feel like people tend to overlook studies, gatherings, and personal tasks for job when working in a pandemic-driven remote office. Whilst we live where we work, sometimes there is a very blurry line between what is professional and what is personal life. If we address that blurriness with a free day for people to work on themselves, there is a possibility to restrain an imminent burnout, and also be in pair with other great tech companies around the world which already register the effect of a 4 day work week.
The time to present this idea to the team has arrived, and interestingly, we all felt like this was something we would benefit so much from that we compromised to go the extra mile to make this design process works. Since it was only 10 days, it was also enough for us to test and pilot before making this process official. To make sure we would follow, the team also took notes of the type of work that was considered ramp up and cooldown in our contexts, this way we could make ourselves even more productive and focused.
How did that shape up during our Design Ops marathon?
One of the biggest benefits we feel from the sprint is that we ramp up in a week, focusing on solo work and our deliverables. Then, in the second week we put all the meetings, 1:1s, reviews, and retrospectives. As such, there are fewer meetings and interruptions during the ramp up week, which boosts our productivity. to better visualize that, here is a representation of what our schedule currently looks like.
Together with the productivity increase, some reports from the team made me really happy. I’ll share a few here:
“I am happy because looking at the way we work I feel like I will not have another burnout”
“Now that I started working this way, I don’t want to work in any other way”
“I did all the ramp up work during ramp up week and in the cooldown week only what we proposed. It works!”
Nowadays, more than 20 people shared in three different teams are in this type of process in Creditas, 10 of them from our Design Ops team. There are also other teams talking with us to see how they could implement our Sprint and we will support those when the time comes, so that number will keep growing. Seeing this method works in different contexts shows us its scalability and potential to be used in other squads and contexts outside of design. But first, we still have some homework to do.
To be honest, we are still learning the best way to conduct metrics and define our scopes within the sprint. Even if we run our sprints smoothly, we understand that there are still problems and things we need fixed, each within their own team specific scope and focus. For that, we will keep working. And before I forget, to achieve that we will rest and sing out loud again on the 10th day.
Further readings
Books
The Sprint Book — Published by Jake Knapp that defined what is a Design Sprint.
Shape up — Details how Basecamp ships its work (free to read and download).
Articles
We should understand how Design Sprints are different from Agile Sprints.
Now that we know its differences we can jump into case studies with the Design Sprint as a framework to see it in practice.
The other method we mention here is the one structured by Basecamp, further explained in the article below by the company CEO.
