Technical workshop at AssoConnect

Lock 4 people up in the same room and pick each other’s brains for 1.5 hours. This is the recipe for our Technical workshop or “Pre-Development Meeting”. Thanks to this ritual, we now produce faster, cleaner code without getting worked up.

Let’s jump in and let me explain why we love these workshops!

Photo by Barn Images on Unsplash

The Challenges we were facing

Earlier this year, we tried a new method to change the way we study the tech needs of the product team’s requests.

Without going too deeply into the specifics of our previous method, here is a list of issues we identified and wanted to solve:

• Every time a question goes unanswered, tickets are late
• When developers are stuck, they move on to another ticket so following-up who works on what is complicated
• Technical knowledge isn’t properly shared and distributed among the team
• The developer does not have a deep understanding of what issue the user is facing
• Classes or methods refactoring pops up during the code review
• The reviewer does not understand 100% what he is reviewing in a PR

We kept digging and discovered the roots of these problems:

• Anticipating potential roadblocks can be difficult when dealing with a ticket for the first time
• The right person is not always available when they are needed
• We thought to have truly understood the full meaning of the ticket, when we unknowingly missed some details
• Some tickets are not descriptive enough
• Some tickets have too many requests
• As surprising as this might sound, developers are not the experts of the product they work on

The new method

Our first plan of attack was to focus on the S of the SOLID principle: single responsibility. A ticket MUST have a clear objective. If it addresses too many issues then it MUST be split up into separate tickets. It makes things more simple: to study, to understand, and to develop.

Our second plan was to group all questions during a dedicated meeting on the collective agenda: and so our technical workshop was born!

So, how does it work?

The PO leading the project plans a meeting with the people in these roles:

• Software Architect
• Developers
• PO

And the agenda of the meeting is:

• Current state of the product — 15minutes
• Future state of the product — 15 minutes
• Technical solutions — 1 hour

So first, the PO owns the floor: we review the feature as it is currently, then we discover what we want to solve and the PO’s ideas to fix the problem.

During this process, the developers will have time to understand new aspects of AssoConnect, think like a user and understand what is at stake when they’ll work on it.

Then, developers suggest some technical solutions to implement. First, we try and breakdown the main tasks to determine the workload. If there is too much, then the PO will split up the subjects into different tracks. We then proceed to study one track per workshop.

At any time, anyone can interrupt the process in case he/she/they are missing information on what is being discussed: product features, code structure, etc. Our philosophy is that any question asked during the workshop is one less question that will pop up later and interrupt the implementation process.

Then we split the track into individual tickets: each ticket has a well-defined purpose.

The way we split the track is important. First and foremost, we work on the related technical debt: the first tickets treated will clean the code, taking off some of the technical debt, while the last ones will update current features. This is our way to keep the technical debt under control.

A developer is assigned to each ticket: he/she/they will be in charge of writing the technical “to do” list. Finally, we detail everything down to the classes’ name and properties, methods’ signature so we won’t lose time later during the PR process.

The goal of a technical workshop is not to go through all the planned tickets but to study as many as possible. If some are left to study then the PO will plan another workshop and that will not surpass 1.5 hours.

However, by the end of the workshop, all attendees MUST have a deep understanding of all the tickets we thoroughly worked on so the dev will be as smooth, and the PR as relevant as possible.

The last step of the process is a 30 minutes session: we review all the tickets of the track to ensure that nothing is missing.

What’s next?

Our observations thus far:

• Fewer comments during the PR
• Higher velocity
• A significant drop of interruptions during implementation (about 80%)
• Developers have a better knowledge of the product they are working on
• Technical knowledge is shared better amongst the team

We also have found new improvements to work on. For instance: how can we boost efficiency during the workshops?

More answers to come on that in another article, stay tuned!