Software Público Brasileiro

\section{Discussion}
\label{sec:discussion}

The results presented in this paper reveal a set of nine best management
practices from the agile and free software development methods that were
successfully employed in a government-academia collaboration to develop an
e-government platform. Around a case study, we analyzed unsystematic decisions
made by the coordinators in a 30-month collaborative project and identified
three macro-decisions that harmonized the differences of the management
processes of each organization. We evidenced from data collection, and responses
of the members of both sides to the questionnaires and interviews, the benefits
obtained through the adoption of this empirical method. As a result of our
research, macro-decisions, practices, and benefits are listed and related in the
table \cite{practices-table}

\begin{table}[]
\centering
\resizebox{\textwidth}{!}{%
\begin{tabular}{ | m{4cm} m{10cm} m{10cm} | } 
\hline
\textbf{Decision} & \textbf{Practice Explanation} & \textbf{Benefits} \\ \hline
\textbf{Use of system under development to develop the system itself} &
\begin{itemize}
\item The features and tools of the platform under development supported the project management and communication activities.
\end{itemize} &
\begin{itemize}
\item Communicating with transparency and efficiency; 
\item Monitoring of activities;
\item More interactions between developers and public servants;
\item Confidence in the code;
\item Organic documentation;
\end{itemize} \\ \hline

\textbf{Bring together government staff and development team} &
\begin{itemize} 
\item Government staff, academic coordinators, senior developers and team coaches biweekly meet at the UnB's lab, academia headquarters, for sprint planning and review.
\item Conduct on the platform the technical discussions between government staff and the development team.
\item Involve government board directors only in strategic planning of the project.
\item Build a continuous delivery pipeline with steps involving both sides.
\end{itemize} &
\begin{itemize} 
\item Reducing communication misunderstanding;
\item Better meeting expectations of both sides;
\item Improvement of decision-making process;
\item Overcoming the government bias regarding low productivity of collaborative projects with academia;
\item Synchronizing the execution pace of activities;
\item Improve the translation of the process from one side to the other;
\end{itemize} \\ \hline

\textbf{Divide the development team into priority fronts, and for each one, hire at least one specialist from the IT market} &
\begin{itemize}
\item The coordinators separated the development team into priority work areas considering the main demands of the project.
\item IT market professionals with recognized experience on each front were hired to work in person or remotely.
\item Define among the interns the leadership roles: a coach for each front, and a meta-coach of the entire development team.
\item Each team has certain self-organization, being guided by one intern-coach and at least one senior developer.
\end{itemize} & 
\begin{itemize}
\item Conciliating the development processes of each institution, taking better technical decisions;
\item Improving the management and technical knowledge;
\item Self-organizing and gaining autonomy in the management of their tasks;
\end{itemize}\\ \hline
\end{tabular}%
}
\caption{Empirical SPB management method and its benefits}
\label{practices-table}
\end{table}

The results of this current work corroborate the lessons learned in our previous
work on studying the SPB project case \cite{meirelles2017spb}. Evidence from the
data collected and responses of questionnaires and interviews reinforces what
has been reported by the academic coordination of the project, adding point of
views of government and other roles involved on the academic side. In this work,
the new evidence also reveals conflicts not overcame during the project and that
should be evaluated for future software development partnerships between
government and academia. Among the problems faced, the government staff had
difficult to understand how collaboration works, that is, they took a time to
realize that the project was not a client-executor relationship and that both
organizations were at the same hierarchical level in the work plan. They also
felt the project needed a decision-maker role to resolve impasses between
organizations. Finally, they said that at times they felt intimidated by the
coordinator in some attempts to communicate directly with the UnB interns.

\textit{Limitations}. We consider that the results found in this work are valid
for the project studied, but may not have the same effectiveness for another
government-academia collaboration. However, based on the benefits presented in
the Table \ref{practices-table}, we believe that the abovementioned practices
and other OSS practices should be evaluated and used in contexts with plurality
and diversity of stakeholders, such as collaborations. 

As threats to the validity of this work, we point out the lack of
communication records and lack of treceability of the management data referring
to the first phase of the project. We also consider as a threat the hiatus
between the completion of the project and the conduction of interviews and
questionnaires with the former team members, since we rely on the memory of the
interviewees to rescue the events. Also, the new work experiences of the
respondents after the project and their current working mindset may also modify
their interpretation of the topics addressed in the questionnaire and
consequently their responses.