What's a tech workshop and how to make the best of it?

Before defining what's the best tech workshop, the first step is to define the tech workshop and its objectives.

The tech workshop finds in place in the Scrum flow, which objective is to optimise efficiency. It is a meeting where all software developers of a team gather on a regular basis, where the technical strategy and the estimation of the difficulty is made for each task.
In Scrum, the entire process has been defined in order to reduce the number of retroactive loops, because these have been known to cost the most: what could be worst than developing a feature for a month and then realise the needs were misunderstood from the start because you didn't ask the client for details?

This used to be the standard workflow and the perfect example of what you want to avoid: coming back to features months after they were developed.

The philosophy to define the best tech workshop must therefore be the same than in Scrum in general: lose a little time now, to make sure everything is right, in order to save a lot of time in case a retroactive loop has to be made.

Since I've participated to a lot of tech workshops, sometimes as "a simple developer" and sometimes as a technical lead, here is what I learned and what could help you make the best of your tech workshops.

First of all, in case some of you have never participated to a tech workshop, here is where it usually finds its place in a standard Scrum workflow:

You usually shouldn't organise a tech workshop for a feature unless it is perfectly well defined, and you shouldn't start the development of a feature unless it has been well analysed under a tech workshop.
The retroactive loops the tech workshops can help prevent are obviously the Development/Review loop first, but also all the feedbacks between junior and senior developers whenever the junior developer needs help during the development process.

Knowing that, the best tech workshop definition almost becomes an evidence: it should be a moment of sharing, in order to find the best technical strategy so that even the less skilled developer can develop it himself, without the need to ask for help later. Therefore:

• All the architectural questions must be resolved
• The person who has the best knowledge of the project should be here to mention if some work can be saved because utils functions or another feature can share similar parent files
• The 2 points above must be written in the most detailed way
• It isn't a bad idea to make it a friendly competition to improve efficiency
• The less skilled developer should ask as many questions as necessary for him to be able to develop the feature itself

When I was working at Dior with developers from Theodo, this was one of the moments of the week I preferred the most because I could watch much more skilled developers think, their process while thinking, and I could learn about the architecture of the project and other theoretical developer tricks.

It goes without saying that I've been able to write this article mostly thanks to them. So kudos to them, and think of checking them out!