Software Público Brasileiro

\section{Results}
\label{sec:results}

The SPB portal project had two phases according to the traceability of
project management activities. The first one, between January 2014 and March
2015, is non-traceable since only the universities managed the development
activities. The communication between government and academia was, generally, in
private channels, such as professional e-mails, personal meetings, and
telephone calls. Therefore, the quantitative data found for this period
are not conclusive or have little expressiveness, and we do not examine them.

The second phase, from April 2015 to the end of the project (June 2016), has
meaningful data. Much of the management and communication activities were
recorded and published on online channels and tools. During this period, the
development leaders' employed several FLOSS practices and agile values in the
development process. At the end of the project, the academic team had an
empirical management approach for meeting the government bureaucracies.

\subsection{Use of the system under development to develop the system itself}

Due to the platform features for software development and
social network, the development coordinators decided to use the platform under
construction to develop the system itself. Gradually, in addition to development
activities, government and academia migrated the project management and the
communication between teams to the portal environment. 

In short, the wiki feature was used for logging meetings, defining
goals, planning sprints, documenting deployment procedures and user guides. The
issue tracker was used for discussing requirements, monitoring features under
development, requesting and recording changes, and validating the delivered
functionalities. Finally, the mailing list was used for collaborative construction
of requirements, defining schedules, and scheduling meetings between institutions.

Our surveys report Mailing list (100\%) and Issue Tracker (62.5\%) as the main
means of interaction between senior developers and interns. Developers and MPOG
staff also interacted mostly via Mailing List (87.5\%) and Issue tracker
(50\%).  According to one of the interviewees, this movement made the
\textbf{communication more transparent and efficient}. An MPOG analyst said
that \textit{``Communicating well goes far beyond the speed. It means enabling
someone to tell everyone about everything that is happening in the project. We
did not use emails, we use more mailing list and avoid emails. This usage
helped us considerably. Everything was public and did not pollute our email
box. So, when you wanted to know something, you could access the SPB list and
see everything''}.

Migrating to the SPB platform also \textbf{easied monitoring of activities and
increased interactions between developers and public servants}. The data
collected from the repository highlight the frequent use of the platform by both
sides teams. In the last 15 months of the project, 59 different authors opened the
central repository issues, 8 of them were MPOG agents. These issues received comments
from 64 distinct users, 9 of them from MPOG. When we consider the issues with more interactions, those which had ten
comments or more, we notice that the government team also felt comfortable in
using the tool to interact directly with the development team. In a set of 102
active issues, MPOG staff created 43 of them (this represents 42\% of the most active issues).

For the MPOG analysts, interaction via
repository improved communication. \textit{``There was a big evolution, we
increased our communication via Gitlab''}.  Migrating to the platform also led MPOG
staff to \textbf{trust the developed code}: \textit{``Everything was validated.
We tested the functionalities and developed the project on the SPB platform
itself. Hence, the use of the system homologated most of its features. From the
moment we began to use it for developing, this validation was constant. We felt
confident in the code produced''}.

The abovementioned decision also collaborated to meet the government's demand
for meticulous documentation of the software design and stages of development
without bureaucratizing or modifying the development process. The usage of the
platform for project team management conducted \textbf{the organic production
of documentation and records}, as mentioned in one of the MPOG responses: \textit{``It was a great
learning experience. There are many things documented in emails as well as
in the portal itself. We can access the tools at any time and find out how we
develop a solution. We can remember the positive project points''}.

\subsection{Brings together government staff and development team}

In the first phase of the project, the interviewed MPOG
analysts did not participate in any direct interaction with any university
representative, even though they were the ones in charge of the government in
ensuring the collaboration agreement and the delivery of the products. Because
of this, they relied on feedback from their superiors on inter-institutional
meetings. They reported that there was significant communication noise in the
internal dialogues with their superiors, as well as between their superiors and
the development team.

In the second phase of the project, these analysts became direct representatives
of the government and started to visit the university's laboratory bi-weekly.
One of the analysts believed that
\textit{``at this point, the communication started to change''}. The new
dynamics \textit{reduced communication misunderstandings and unified both
sides}, as reported by another interviewee: \textit{``It was very positive. We
liked to go there and to interact with the team. I think it brought more unity,
more integration into the project''}. {73\%} of the interns considered positive
the direct participation of the MPOG staff, and {81\%} of them believed the
presence of government staff in sprint ceremonies was relevant for the project
development. For 76\% of the interns, writing the requirements together with the
MPOG staff was very important to \textbf{better meet expectations of both
sides}. According to one of them, \textit{``Joint planning and timely meetings
were very important for understanding the needs of MPOG''}.

The closest dialogue between government and academia generated empathy, as
reported by one of the interviewees: \textit{``Knowing people in person makes a
big difference in the relationship because it causes empathy. You know who that
person is. He's not merly a name''}. Consequently, this empathy helped to \textbf{synchronize
the execution pace of activities}: \textit{``Visiting the lab and meeting
the developers encouraged us to validate resources faster and give faster feedback to
the team. In return, they also quickly answered us any question''}.

The implementation of a Continuous Delivery pipeline also reinforced the teams'
synchronization \cite{siqueira2018cd} .  For 81\% of the interns and 75\% of the senior
developers, deploying new versions of the SPB portal in production was a
motivator during the project. On the government side, this approach helped to
\textbf{overcome the government bias toward low productivity of
collaborative projects with academia}, as mentioned by themselves:
\textit{``Government staff has a bias that universities do not deliver
products. However, in this project, we made many deliveries with high quality.
Nowadays, I think if we had paid the same amount for a company, it would not
have done the amount of features we did with the technical quality we have''}. Additionally, the
deployment of each new version also \textbf{share a common understanding of the
process from one side to the other}, as mentioned by a MPOG analyst: \textit{``We
had only the strategic vision of the project. When we needed to deal with
technical issues, we had some difficulty planning the four-month releases.
However, in the last stages of the project I realized that this was not a
problem. The team was delivering and the results were available in production.
The team was qualified, the code had quality, and the project was well executed.
So in practice, our difficulty in interpreting the technical details did not
impact the release planning''}.

\subsection{Organized development team into priority fronts, and for each one, hire at least one specialist from the IT market}

The development team had four work areas divided by the main demands of the
project: User Experience, DevOps, Integration of Systems, and Social
Networking. For each segment, at least one professional in the IT market was
hired to raise the quality of the product. Senior developers have been selected
based on their vast experience in FLOSS systems and their knowledge on tools
used in the project.

The presence of senior developers in the project contributed to
\textbf{conciliate the development processes of each institution and make
better technical decisions}, as quoted in one of the answers to the senior
developer's questionnaire: \textit{``I think my main contribution was to
balance the relations between the MPOG staff and the university team''}. {63\%} of
the senior developers believed they have collaborated to conciliate the management
and development process between the two institutions and also {63\%} of them 
helped MPOG staff express their requests more clearly. Government
analysts were also more open to suggestions from these developers:
\textit{``They are upstream developers of the systems that
integrate the platform. They conveyed trust, and then we trust in the developed
code''}. According to questionnaire responses, senior developers largely agreed with the
project development process. For 63\%, this process has close similarity to
their previous experiences. In contrast, {62.5\%} of them did not understand
the MPOG's project management process and {50\%} believed this process could
affect their project productivity.

The senior developers were also responsible for \textbf{improving the management
and technical knowledge} of the interns about practices from industry and open
source projects. {91\%} of the interns believed that working with professionals
was essential for learning, and, for all of them, working with senior developers
was important during the project. {75\%} of the senior developers believed that ``Working
in pairs with a senior'' and 63\% that ``Participate in joint review tasks''
were the tasks with the involvement of them that most contributed to the
evolution of university interns in the project. {75\%} believed that the knowledge
shared by them to one intern was widespread among the others in the team.
Government analysts also pointed this knowledge sharing: \textit{``On
the university side, we noticed a significant improvement in the platform
with the hiring of the systems original developers. They had a guide on
how to best develop each feature and were able to solve non-trivial problems
quickly''}.

Organizing the development team and hiring senior developers allowed each team to
\textbf{self-organize and gain more autonomy in the management of their tasks}.
There was a development coach to lead each team, and a ``meta-coach'' supported
all of them in their internal management activities. The coaches (most advanced
university interns) were points of reference in the development process. {89\%} of the
interns said that the presence of the coach was essential to the sprint's
running, and for {88\%} of the senior developers coaches was essential for their
interaction with the team. MPOG analysts saw coaches as facilitators their
activities and communication with the development team. They said \textit{``I
interacted more with the project coordinator (professor) and team coaches''},
\textit{``Usually, we contact a coach to clarify some requirements or to
understand some feature. The coaches were more available than senior
developers and, sometimes, they would take our question to a senior developer''}.