I had the pleasure of talking with Lina Prato, a graduate of Political Science by training but who has long been involved in the world of project management, and from there she transitioned to the role of Scrum Master.
Lina has been working at Grupo Esfera in recent years and is also a very active professional in the Agile community of her native Argentina.
Lina began by telling that she got involved in the world of Agility in 2015 and her first job was as a Scrum Master. Lina said that her previous experience had been in project management, but that knowing Scrum was something more natural and aligned with her thinking.
Lina realized early on that when working with a technical team and being non-technical, there were many topics that she simply did not have the knowledge to debate. She intuitively started looking for allies within the team to cover the technical knowledge side.
Since she joined Grupo Esfera, this search for a technical peer to collaborate with a team has been systematized for Lina. Grupo Esfera works using eXtreme Programming practices, which allowed her to find technical peers with the necessary knowledge to support improvements within technical teams.
In her experiences prior to Grupo Esfera, Lina perceived that using only Scrum, improvements do occur but end up hitting a ceiling. She observed that the technical ceiling ends up limiting the Agility of a team in the end. This was due, according to her, to the fact that technical practices were not being improved, only human and process ones.
She advises non-technical Scrum Masters to be curious about the craft of making software, and primarily to understand the technical complexity the team deals with when building a product. The second advice that she offered is to identify who the technical pair will be and build a bond of trust with her/him.
Lina warned that you should not focus only on the technical, leaving aside the humanistic aspect of software development; on the contrary, both factors must be balanced within a team that aspires to build good software. Following the same logic, the relationship of a Scrum Master with its technical pair should be with no hierarchy involved.
Improving technical practices, according to Lina, requires much more discipline. She gives an example that in a retrospective someone may be half-present flying over the meeting, but in a technical discussion, it is noticed when a person is not involved or lacks knowledge. Lina proposes to make explicit with clients that the team requires time to learn, to code in pairs, and to invest in the technical quality of what they build.
Lina made a couple of final observations: technical profiles have somehow moved away from Agile conferences, and companies that offer transformation services do not offer the technical side and focus only on Scrum. In her opinion, sell the improvement without considering technical aspects, it is a half-sale because it will not end up giving profound results.
