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 consolidated several FLOSS practices and agile values

employed 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. The development
team 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 \textbf{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 IT professionals, 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 IT professionals 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, IT professionals 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 IT professionals was important during the project. {75\%} of the IT
professionals 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 the 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 of the IT professionals 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 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 of the IT professionals the coaches was

essential for their interaction with the development team. MPOG analysts saw
the 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 (interns)''}, \textit{``Usually, we