A Scrum team journey (at the countryside)
--
At the end of June, we, as the Knowledge Graph team*, keep working with all the team ceremonials as they should be, while respecting the Scrum Sprint and release objectives. And, to be honest, we were in a good mood regarding the schedule.
Despite this, a recurring need of the team was felt: to see each other. We are people who know well each other, but whose team is new from the start of lockdown (1 year ago). The fact of working together on a daily basis is only known behind computers, but rarely physically. One solution: meet each other to work together and have a good time outside of work.
* Antoine Caron, Baptiste Lecocq, Charles Gouwy, Chunpeng Xing, Delphin Aubin and Vivien Longuet.
“Lightness, a swimming pool and a barbecue”
Here are the words that prompted us to rent a cottage in the countryside of Saint-Omer, 1 month later.
While thinking on this seminar initiative, an idea rose up: let’s shake things up. It is true that a certain pressure was felt during our Sprints, in particular due to remote working, but also due to development and organizational practices which were so well mastered, that could sometimes restrict us to innovation.
To innovate, our wish was the following: a high speed of delivery. By the end of this week, a usable deliverable had to be in production. We therefore ignored certain good practices, such as DDD, BDD. But we still wanted to keep focus on low-level practices, such as TDD on business value features.
To make this possible, we are really proud in having a sane, clean, and high-quality codebase that was easy to squeeze into. In less than 2 hours, we were able to put into production a version of the new “showcase” product, capable of connecting to our data source. In fact, it was a blank page, with “Hello World!”, deployed in dev/preprod/prod environments, linked to the CI, plugged to our databases, with all of our technical tools ready to use.
Moreover, some ceremonials have been questioned, in order to save time, but above all, to focus on their real value:
- no need to have daily meeting, as we were in constant synchronization
- no need to have sprint planning, as we knew what to do, and which order of priority
The product
The knowledge graph is a way to build on the extended knowledge of products, to be useful to residents.
This knowledge is, at the moment, split in the expertise of all the people of Leroy Merlin. Our goal is to centralize it, make it understandable, and help teams to use it, to meet specific needs.
So far, workshops have been set up by members of our team (PO, developers, taxonomists) in order to understand the need, and to model knowledge to meet this need. Use-cases are already in production regarding the knowledge already modeled, but it could be even more interesting to receive contributions directly from collaborators.
We’ve decided to pause the current release, in order to embark on an idea allowing collaborators to provide us a great feedback on the work we are daily doing.
Collaborators at the heart of knowledge
To start this idea, we simply grouped together around a paper sheet, drawing the simplest and most rewarding features for the user:
- suggestions for new data (see: Screenshot PoC (5)),
- vote on suggestions,
- discover already integrated knowledge (see: Screenshot PoC (1, 4)).
A codebase was placed on the existing one, mastered by all (NestJS). Some new technical choices have also been made, for the simple purpose of having fun (React).
Then, in a second step, our concern was to make the collaborator want to participate, to bring him into a game…
Why not use the principles of gamification?
- Some actions are worth more points than others.
- Points system allow you to gain levels (see: Screenshot PoC (2)).
- Levels are unknown, and are discovered over time.
- A leaderboard stirs up the most playful among us, to become the best handyman of ADEO / Leroy Merlin (see: Screenshot PoC (3)).
A retrospective full of enthusiasm
The week of the seminar being over, we undertook a retrospective in order to perpetuate what worked very well during these days.
There are many more post-its that we won’t show here 😉, but the recurring topic is lightness in decision-making:
- leadership was taken by all team members,
- the right to make mistakes has enabled us to ship more quickly,
- the technical points (architecture, features, dev practices, etc.) are shared between each other,
- the challenge was met with additional features, without stress,
- trust is greater among all team members,
- the recognition of the organization is strong.
Result is making noise
To sum up: it’s a real success for the team. The goal was achieved in 4 days of development, in a good mood, in a restful and rejuvenating environment, while making “wow effect” around us.
For the first 2 days of going live, there are already more than 60 suggestions made by collaborators.
- ADEO is a place that was able to give us the opportunity to experiment, and we took it with open arms. The trust that we have in each other has been crucial in bringing this moment of life to a successful conclusion.
- Thanks to the constant quality of the project we are working on, it was very easy to get involved in order to build a project from scratch. Indeed, in 2 hours of time, a new product was born until production.
- It is great to take some time off the daily routine, to re-focus on the heart of all of the practices we used to do: why are we doing daily meeting? Why are we doing multiple kind of tests? Why this daily thing is taking so much time? Can we decrease it?
