How to share experiences between development teams: TPS Develer
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:
- Post Mortem: incident reports
- Retrospective: reports following completed projects
- Evergreen: reports independent from project events (such as an accident or termination)
How are the TPS structured?
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:
- Team members can find details whenever they need, even in the middle of the night. It can be really helpful! In addition, even new team members can get details about the projects history from such documents. These documents are particularly useful because they have no vocabularies strictly and expressly related to the different projects (otherwise, they would not be understandable outside the contingency) and will therefore be more acceptable for someone who just joined the team.
- The “bus factor” of the experiences acquired on a project is reduced.
- The document created is easy-to consult by all Develerians on the Wiki.
- During the presentation of a TPS, a certain time is destined to discussion. This time, mainly aimed to clarify unclear points to participants, can be sometimes spent by the presenter to question his/her own solution and, perhaps, think and make changes as a result of ideas sharing and discussion.
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.