狠狠撸

1
Sebastian Gomez, Engineering Manager @ Adevinta
sebastian.g.moran@gmail.com
Loco Fridays
Tools to improve team’s
wellness and performance

2
When this idea come up?
[In the context explained in the appendix] Team’s engineers were working mostly on solving issues in
production due the huge technical debt of the services, that’s working on putting out fires
With one severe incident per week, the mood of the team was really low
To stop being reactive and start being proactive, we identified, listed and prioritized the
technical debt issues in our backlog, and started working on it in an agile way, as an
engineering team, focusing on repairing the product, developing and applying patch by
patch
The number of incidents decreased a lot, but this took a lot of time (almost 2 quarters), and
after a few months working on fixing bugs instead of developing new features, the team
needed fresh air

3
What loco Fridays are?
To add some fresh air, I tried one thing: I offered the team to spend one Friday every 2
weeks working on anything outside the sprint, just 3 rules:
1. The scope has to be related with team’s scope
2. Track everything in a Jira task
3. Once finished share the knowledge performing a demo to the rest of the team
(Implicit rules: incidents have higher priority)
Can be done alone or in small groups, for that we do a Loco Standup to start each Loco
Friday, so people can join in groups.
In special cases, can put together more than one Loco Friday and work 1+ days in a row

4
What loco Fridays are?
For the engineers, Loco Fridays are:
● A day to “play” with new technologies
● A day to take some issues that they
want to work in
For the team, Loco Fridays are:
● The team invest 10% in R&D → more
competitive
● A tool to be up to date
● A tool to identify improvements →
more reliable products, with more
features → better products →
Happier customers
10%
R&D
Better
products
More
competitive
:)

5
How to setup Loco Fridays
To improve adoption and
maximize the impact , the
alignment within the team
is very important
Start writing the activity
somewhere as a draft,
then share and iterate
with the team to find an
agreement

6
To add visibility and being able to
organize the R&D with the rest of
the work, I recommend to track and
plan R&D work in your backlog tool
For instance: in our case I created an Epic
in our Jira board with an specific color.
Now it is very easy to identify the Loco
Friday activity and ideas among the rest

7
Help the team plan their week by
booking the time for Loco Fridays
In your team’s calendar, add this
event every when you consider or
agreed with the team (i.e. every two
weeks)

8
Until the team gets used, remind them days
before to start thinking about tasks for R&D,
and follow the activities (tracking tasks, demos
when finished, …)
An important thing is to celebrate Loco Fridays,
to celebrate the failures and the success, to
share with other teams to increase your team’s
work visibility, …
The team has to be proud of the work they do
o/
Kudos
Share with
other teams

9
The outcome and the experience
As an example of the results, many new features added to our products came
from Loco Fridays, many improvements for reliability, to optimize the
deployment pipelines, to fix legacy technical debt with new technologies, …
From my experience, engineers love this day, it is the day were they can use
their working hours to experiment, to learn, to fail, to success, to bring
knowledge to the team, … to engine.
As an evidence that they enjoy doing this: Even Loco Fridays are not
mandatory, after one year I left that team they still celebrate it.
This is a great win for the engineers wellness, self training, and to realize
somehow. This is a great win for the team, for its products and for their
projection in the Company

10
Optional appendix: The context

11
I landed in Schibsted early 2018 as engineering manager of a team made by 7 really brilliant devops and software engineers
(Alan, Fabian, Jaime, Oscar, Ivan, Zen and Sergi). This team didn’t had a full-time engineering manager before, they had a high
level product manager managing the priorities, and taking care of their wellness.
The team had 2 main products, one, based in Mesos and Hadoop, offering Big Data capabilities, and another one offering based
in a custom setup of kubernetes, offering microservices capabilities.
The one based in mesos was the older one, because business needs, this service was promoted from a PoC to production the
day after. This means that from the very beginning it had a lot of technical debt. It had in average 500+ hosts running.
1.5 years later, because this team was made by talented people, were asked to build the microservices platform. At this moment
kubernetes was starting so the custom setup was the better option.

12
After delivering the first version of the microservices platform, soon many customers eager for trending technologies onboarded
and soon many microservices were running on it. At this point, both platforms were in production with many customers running
their stuff, and the team continued working on iterations of the product to deliver new capabilities.
At a certain point, the services started failing because some critical issues due the technical debt, causing severe incidents, some
of them with outages.
This was a critical point, because the capacity of the team was really limited with a huge scope, and involved in the delivery of
business critical platforms.
I arrived at this point. The team was doing a great job trying to deal with everything, but the load and pressure was too high…

狠狠撸

Sebastian GM - EM Templates - Loco Fridays.pdf

More Related Content

Sebastian GM - EM Templates - Loco Fridays.pdf