How to share experiences between development teams: TPS Develer

Photo 2019
Develer Technical Project Stories: interview with Lorenzo Savini

The experiences of a development team rarely overcome internal boundaries and are shared with other teams. It may happen by chance, during a coffee break, but not in a structured way. These experiences are usually the result of a lot of time and stress and could bring enormous benefits to other projects as well.

What did we think of in Develer so that everyone can benefit from the best practices adopted by the different teams?

Lorenzo Savini, software developer and responsible for our TPS (acronym of Technical Projects Stories), tells us today.

Hi Lorenzo, what are TPS and what needs do TPS meet?

TPS are appointments on a monthly basis and internal to the company, so that everybody can be free to discuss with colleagues.

TPS main purpose is to share experiences and choices, made and taken during projects, with members of other teams who would otherwise never have known anything about them. TPS encourage opportunities of aggregation and discussion where everybody can examine both technical choices (such as tools and architectural choices) or concepts (documentation, code cleaning, work organization), and specific events that brought new knowledge (the so-called incidents).

How many types of TPS are available?

We divide TPS into 3 main groups:

How are the TPS structured?

Photo 2019

As I said before, TPS are monthly and can last from half an hour to a maximum of one hour each. One Develerian presents the chosen topic to the internal audience and part of the time is always destined to a Q&A panel and discussion.

At the end, the speaker is asked to draw up a document including a report about what said and discussed. This document is then uploaded to the corporate Wiki, so that all Develerians, including our future colleagues, can consult it and benefit from these meetings.

What are the advantages of sharing experiences outside the working groups?

Advantages of sharing experiences are many, as follows:

Any downside?

Actually, not many. Of course, sometimes separating a single experience from the history of an entire project is not easy and may require a more or less complex introduction in order to fully comprehend the specific TPS.

Moreover, it is not easy to restrict in half an hour the work made in several months. From this point of view, TPS are also excellent “gyms” to train high performing speakers.

We are convinced that the advantages of sharing knowledge and experience among the different development teams can create a truly precious added value.

Do you agree with us? Do you like the way we work?

Discover the open positions