[oss-2018] applying Carla's review

Melissa Wen
1 parent 720c4541
Showing 7 changed files with 249 additions and 187 deletions Show diff stats
oss2018/content/00-abstract.tex
oss2018/content/01-introduction.tex
oss2018/content/02-relatedwork.tex
oss2018/content/03-methods.tex
oss2018/content/04-results.tex
oss2018/content/05-discussion.tex
oss2018/spb-oss-2018.tex
 \begin{abstract}
-Government and academia can collaborate on bringing innovation and filling design-reality gaps in e-government projects. However, differences in project management methods employed by the organizations is often a challenge for collaborative works. Bearing that in mind, we investigated a 30-month government-academia partnership to find appropriate ways to get around this obstacle. From the analysis of \textit{post-mortem} data as well as the results of questionnaires and interviews with project participants, we present a set of best practices based on FLOSS and agile software development approaches that favors team management in government-academia collaborations in e-government development projects.
+Government and academia can collaborate on bringing innovation and filling
+design-reality gaps in e-government projects. However, differences in project
+management methods employed by the organizations is often a challenge for
+collaborative works. Bearing that in mind, we investigated a 30-month
+government-academia partnership to find appropriate ways to get around this
+obstacle. From the analysis of \textit{post-mortem} data as well as the results
+of questionnaires and interviews with project participants, we present a set of
+best practices based on FLOSS and agile software development approaches that
+favors team management in government-academia collaborations in e-government
+development projects.
 \end{abstract}
-\keywords{Open Source Software, Free Software, Agile Methods, Best Practices, Project Management, E-Government.}
+\keywords{Open Source Software, Free Software, Agile Methods, Best Practices,
+Project Management, E-Government.}
@@ -12,9 +12,11 @@ the collaboration project, aligning goals, synchronizing the pace of between
 government and academia \cite{anthopoulos2016egovernment}, and overcoming the
 failure trend of e-government projects \cite{goldfinch2007pessimism}.
-Poor project management is one of the causes of e-government projects failure
-\cite{anthopoulos2016egovernment} which, in turn, grows into a critical issue
-when government and academia combine efforts to develop an e-gov solution. 
+One of the main causes of e-government project failure is poor project
+management \cite{anthopoulos2016egovernment}. When government and academia
+combine efforts to develop an e-gov solution, it becomes a critical issue.
+
+ 
 Academia commonly works on cutting edge technology while the government
 still relies on traditional techniques. Changing the development process in
 large-size institutions represents an organizational disturbance with impacts
@@ -22,7 +24,7 @@ on structure, culture, and management practices \cite{nerur2015challenges}. As
 a result, government and academia have to harmonize their view to increase
 the chances of success in projects with tight deadlines and short budgets.
-We believe that procedures from Free/Libre and Open Source Software (FLOSS) and
+We believe that recommended community standards from Free/Libre and Open Source Software (FLOSS) and
 agile values may be an option for harmonizing different management approaches,
 due to the plurality of FLOSS ecosystems and the diversity favored by agile
 methodologies. Open communication, project modularity, the community of users,
@@ -34,8 +36,12 @@ process management and the cooperation of distinct teams.
 In this work, we investigate the empirical method developed during 30 months of a
 government-academia project that helped to harmonize the differences between
-both organization management cultures. We trace the best practices based on
-FLOSS ecosystems and agile methodology. Finally, we collect data from the
-project repository and survey the project participants points of view to
-extract a set of best practices to conduct effective government-academia
-collaboration.
+both organization management cultures. We present both quantitative and
+qualitative analyses of the benefits of FLOSS and agile practices in an
+e-government project. We identify and trace the best practices based on FLOSS
+ecossystems and agile methodology. We collect and analyse data from the project
+repository. Finally, we conducted a survey target at projects participants to
+find their perception around the set of best practices, and which of them are
+effective to government-academia collaboration. In doing so, our aim is to help
+academia better understand key issues they will be confronted with when engaging
+in a government-academia software project.
 \section{Related work}
 \label{sec:relatedwork}
-% TODO: Verificar se não vale a pena citar os fatores que o Strode descobriu.
-% Eu acho que deixaria a frase mais completa
 Discussions on how to introduce new management methods into an organization are
 present in several works.  Nerur et al. recognized critical issues concerning
 the migration from traditional to agile software development by comparing
@@ -33,10 +31,9 @@ academia.
 Complex and large-scale organizations, such as the public administration, have
 to deal with multiple project variables. Alleman et al. describe a production
 deployment for the US government, focusing on the methodology applied to address
-long-term planning and value estimation \cite{alleman2003making}.  The application of agile
-methods in the Brazilian public sector is approached by Melo et
-al. \cite{melo2013agileBr} and De Sousa et al. \cite{de2016using}, both are
-experiences limited to pilot projects.
+long-term planning and value estimation \cite{alleman2003making}. The
+application of agile methods in the Brazilian public sector is approached by
+Melo et al. \cite{melo2013agileBr}.\todo{reler essa ref}
 Several works tried to highlight the FLOSS practices, while others attempted to
 determine the relationship between FLOSS practices and agile methods.
@@ -52,4 +49,9 @@ Eric Raymond describes many of his experiences and decisions in his work with
 FLOSS communities \cite{raymond}, this report has many intersections with the
 agile manifesto.
-This paper differs itself from others by studying the development collaboration between government and academia of a production level platform. From questionnaires, interviews, and development activities data. We extracted best practices that helped to harmonize the interactions between two different development process and satisfied the management process of both sides. We analyzed the decisions made from the FLOSS and agile perspectives.
+This paper differs itself from others by studying the government-academia
+collaboration for developing a production-level solution. From questionnaires,
+interviews, and development activities data. We extracted best practices that
+helped to harmonize the interactions between two different development process
+and satisfied the management process of both sides. We analyzed the decisions
+made from the FLOSS and agile perspectives.
 \section{Research Design}
 \label{sec:researchdesign}
-% TODO (by Siqueira): Tenho a impressão de que esse parágrafo cairia bem no último parágrafo
-% da introdução. Pelo menos a ideia dele uma vez que resume bem o trabalho
-In this paper, we studied practical alternatives to harmonize different
-software development processes. We are interested in the relationship between
-government and academia from the project management perspective, without the
-enforcement of changing their internal processes. We present two research
-questions that guided our work:
+In this paper, we studied practical alternatives to harmonize the software
+project lifecycle when confronting different development processes from crucial
+stakeholders. We are interested in the relationship between government and
+academia from the project management perspective, without the enforcement of
+changing their internal processes. We present two research questions that guided
+our work:
 \textbf{RQ1. }\textit{How to introduce open source and agile best practices into
 government-academia collaboration projects?}
@@ -18,7 +17,7 @@ government-academia collaborative projects?}
 To answer these questions, we use the case study as research method. We selected
 as a case the evolution of the Brazilian Public Software portal (SPB)
 \cite{meirelles2017spb}, a government-academia collaborative project based on
-FLOSS systems. To validate our answers, we picked three different points of
+FLOSS systems. To validate our answers, we covered three different points of
 view: developers, government agent, and data collected from the project
 repository.
@@ -39,36 +38,50 @@ portal includes social networking, mailing lists, version control system, and
 source code quality monitoring. All of this software is integrated using a
 system-of-systems framework \cite{meirelles2017spb}.
-The platform development activities happened in the Advanced Laboratory
-of Production, Research, and Innovation in Software Engineering (LAPPIS) at
-UnB. The laboratory born from a professor that is part of Brazillian FLOSS
-community and another one that spreads out agile values. Thus, naturally,
-LAPPIS embrace the best practices of both ecosystems. For this project, the
-laboratory had a total of 42 undergraduate interns, and two professors engaged
-in the development team. Finally, the project hired six senior developers with
-significant experience with FLOSS communities, and two designers specialized in
-User Experience (UX).
-
-The government team was composed of one director, one coordinator, and two IT
-analysts from MPOG. They were responsible for contracts and collaboration
-management, which means they do not produce software. The MPOG analysts had
-their background in traditional management approaches, such as RUP, CMMI,
-and PMBOK.
-
-The leaders of LAPPIS and MPOG periodically met in person to manage the project
-progress, discussing strategic issues and technical goals. Initially, these
-meetings took place at the Ministry's headquarters and, usually, only directors
-and professors participated. On the academic side, the management of the
-development teams often spent two weeks per sprint and released a new version
-every 4 months. During the project progress, this workflow proved to be
-inefficient. Conflicts between the internal management processes and
-differences in pace and goals of each institution were compromising the
-platform development.
-
-Professors, with the senior developers' collaboration, incrementally employed a
-set of best practices based on FLOSS and agile values for  improving
+The development of the platform took place at the Advanced Laboratory of
+Production, Research, and Innovation in Software Engineering (LAPPIS/UnB) and
+followed the model of management of sprint of 2 weeks and launches every 4
+months. On the other hand, at the beginning of the project, project management
+and strategic discussions happened only once a month, when Lappis leaders and
+MPOG directors met in person at the ministry's headquarters. The differences
+in organization of the two parties involved in the collaboration are summarized
+by the table\ref{gov-academia-diff-table}. 
+
+\vspace*{-.5cm}
+
+\begin{table}[h]
+\centering
+\def\arraystretch{1.2}
+\setlength\tabcolsep{0.2cm}
+\resizebox{\textwidth}{!}{%
+\begin{tabular}{m{4.3cm}!{\color{white}\vrule}m{6cm}!{\color{white}\vrule}m{7cm}}
+\rowcolor[HTML]{c0d6e4} 
+\textbf{Collaboration peaces} & \textbf{Academia} & \textbf{Goverment} \\
+\rowcolor[HTML]{f2f2f2}
+\textbf{Responsibilities} & Platform development activites & Contracts and collaboration management \\
+\rowcolor[HTML]{fafafa}
+\textbf{Team size} &
+\begin{tabular}[c]{@{}l@{}} 42 undergraduate interns; \\ 2 professors; \\ 6 senior developers with significant \\ experience in FLOSS projects;\\ 2 User eXperience specialist \end{tabular} & 
+\begin{tabular}[c]{@{}l@{}} 1 director; \\ 1 coordinator; \\ 2 requirement analysts \end{tabular} \\
+\rowcolor[HTML]{f2f2f2}
+\textbf{Workplace} & LAPPIS at UnB & MPOG headquarters \\
+\rowcolor[HTML]{fafafa}
+\begin{tabular}[c]{@{}l@{}}\textbf{Management} \textbf{approaches}\end{tabular} & Agile methods and practices from FLOSS development & Traditional methods, such as RUP, CMMI, and PMBOK \\
+\end{tabular}%
+}
+\caption{Differences between academia and government sides}
+\label{gov-academia-diff-table}
+\end{table}
+
+\vspace*{-1cm}
+
+During the project progress, this workflow proved to be inefficient. Conflicts
+between the internal management processes and differences in pace and goals of
+each institution were compromising the platform development. To improve
 the project management process and reducing the conflict between government
-and academia. Throughout the project, the LAPPIS team built an experimental
+and academia, professors, with the senior developers' collaboration,
+incrementally employed a set of best practices based on FLOSS and agile values.
+Throughout the project, the LAPPIS team built an experimental
 management model to harmonize the different cultures. The development leaders
 made decisions in a non-systematic way to promote the usage of these best
 practices. In this paper, we analyze and codify these decisions and its
@@ -76,33 +89,44 @@ benefits.
 \subsection{Survey, Interview and Data Collection}
-We divided the development team into two groups of participants according to
-their roles during the project: undergraduate interns and IT professionals.
-For each set of members, we designed an online questionnaire with topics
-related to (1) project organization, (2) development process, (3) communication
-and relationship with members, (4) acquired knowledge and (5) experience
-with FLOSS projects. We also interviewed two MPOG analysts who directly
-interacted with the development team and project development process.  The
-interview questions had four parts: (1) Professional profile;(2) Organization,
-communication and development methodologies (3) Satisfaction with the developed
-platform; (4) Lessons learned.
-
-We sent the online questionnaire to 42 interns and 8 IT professionals. All
-interns worked as a developer and received a scholarship. We got a total of 37
-interns responses, and all professionals joined on it. On average, interns had
-22 years and professionals had 30 years, wherein 8\% and 13\% respectively were
-women. About 43\% of the interns had the SPB project as their first contact
-with FLOSS. On average, the IT professionals had 11 years of experience, worked
-in at least 5 different companies, participated in 4 to 80 distinct projects,
-and 86\% of them had some background with FLOSS before the SPB project.
-
-We also interviewed two MPOG analysts separately. Each interview took an
-average of 2 hours with 28 open questions. They are over 30 years old, and they
-have more than 7 years working in the government. The analysts said that SPB
-project represented their first experience of government-academia
-collaboration.
-
-Finally, we analyzed the data from the principal project repository considering
+We divided the project team into three groups: undergraduate interns, senior
+developers and MPOG analysts. For the first two groups we sent online
+questionnaires and for the last group we conducted, separately, a 2 hour
+interview. The table \ref{survey-table} have more details about these processes.
+
+\vspace*{-.5cm}
+
+\begin{table}[h]
+\centering
+\def\arraystretch{1.2}
+\setlength\tabcolsep{0.2cm}
+\resizebox{\textwidth}{!}{%
+\begin{tabular}{m{4cm}!{\color{white}\vrule}m{4cm}!{\color{white}\vrule}m{5cm}!{\color{white}\vrule}m{5cm}}
+\rowcolor[HTML]{c6b3df} 
+\textbf{} & \textbf{\nohyphens{Undergraduate Interns}} & \textbf{Senior Developers} & \textbf{MPOG Analysts} \\
+\rowcolor[HTML]{fafafa}
+\textbf{Research technique} & Online questionnaire & Online questionnaire & Interview \\
+\rowcolor[HTML]{f2f2f2}
+\textbf{Discussed topics} & \multicolumn{2}{l!{\color{white}\vrule}}{\begin{tabular}[c]{@{}l@{}}(1) project organization,\\ (2) the development process,\\ (3) communication and relationship with members,\\ (4) knowledge sharing\\ (5) experience with FLOSS projects\end{tabular}} & \begin{tabular}[c]{@{}l@{}}(1) professional profile;\\ (2) organization, communication \\ and development methodologies;\\ (3) satisfaction with \\ the developed platform;\\ (4) lessons learned\end{tabular} \\
+\rowcolor[HTML]{fafafa}
+\textbf{Number of interviewed} & 42 & 8 & 2 \\
+\rowcolor[HTML]{f2f2f2}
+\textbf{Rate of responses} & 88\% (37) & 100\% & 100\% \\
+\rowcolor[HTML]{fafafa}
+\textbf{Average age at the end of the project} & 22 years old & 30 years old & more than 30 years \\
+\rowcolor[HTML]{f2f2f2}
+\textbf{Gender} & \begin{tabular}[c]{@{}l@{}}8\% women \\ 92\% man\end{tabular} & \begin{tabular}[c]{@{}l@{}}13\% women \\ 87\% man\end{tabular} & 100\% women \\
+\rowcolor[HTML]{fafafa}
+\begin{tabular}[c]{@{}l@{}}\textbf{Experience} \\ \textbf{background}\end{tabular} & 43\% of the interns had the SPB project as their first contact with FLOSS & 11 years of experience; worked in at least 5 companies; participated in 4 to 80 distinct projects; 86\%of them had some background with FLOSS before the SPB project & more than 7 years working in the government; SPB project represented their first experience of government-academia collaboration \\
+\end{tabular}%
+}
+\caption{Surveying the project participants}
+\label{survey-table}
+\end{table}
+
+\vspace*{-1cm}
+
+Finally, we analyzed the data from the central project repository considering
 all the issues and commits. From April 2015 to June 2016, 59 distinct authors
 opened 879 issues, 64 different users made the total of 4,658 comments. The
-development team made 3,256 commits in the central project repository.
+development team made 3,256 commits in this abovementioned repository.
@@ -9,28 +9,23 @@ 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 a
-more considerable wealth of data. Much of the management and communication
+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, several FLOSS practices and agile values were applied to the
 development process to harmonize the cultural and organizational divergences of
 the institutions involved. At the end of the project, an empirical approach to
 communication and management was built using the development leaders'
-experiences in FLOSS and agile projects to cater to government bureaucracies.
-
-In this section, we list the macro-decisions taken during the project and the
-practices that made these decisions concrete. We use data collected from the
-central repository to map best practices and, with the respondents' answers, we
-analyzed how each decision benefited the project collaboration.
-
-The development team decided to \textbf{use of the system under development to
-develop the system itself}.  The team released the first version of the new SPB
-portal nine months after the project beginning. 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
+experiences in FLOSS and agile projects to meet the government bureaucracies.
+
+\textit{\textbf{Use of the system under development to develop the system itself}}.
+The first version of the new SPB portal was released nine months after the
+project beginning. 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
@@ -52,20 +47,20 @@ see everything that was happening.&#39;&#39;}.
 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 evidence the frequent use of the platform by the
+collected from the repository highlight the frequent use of the platform by the
 academic and the government teams. In the last 15 months of the project, the
 central repository issues were opened by 59 different authors, 8 of them MPOG
 agents. These issues received comments from 64 distinct users, 9 of them from
-MPOG. When we consider the issues with much interaction, those who had ten
-comments or more, we notice that the government team also felt comfortable with
+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
-issues with much interaction, MPOG staff created 43 of them (this represents
+issues with more interactions, 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 lot of evolution, a
-lot of communication via Gitlab.''}.  Migrating to the platform also led MPOG
+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.  Consequently, the use of the system validated most of the 	features.
+itself.  Consequently, the use of the system validated most of its features.
 From the moment we began to use it for development, this validation was
 constant. We felt confident in the code developed.''}.
@@ -75,12 +70,12 @@ without bureaucratizing or modifying the development process. The team started
 to \textbf{produce documentation and records organically} on the platform
 itself, as mentioned in one of the MPOG responses: \textit{``For me, it was a
 great learning experience. There are a lot of things documented in emails as
-well as in the portal itself. When necessary, we can access the tools and find
-out how we develop a solution. We can recover these positive points.''}.
-
+well as in the portal itself. We can access the tools at any time and find
+out how we develop a solution. Therefore, we can remember the project positive
+points.''}.
-The development coordinators worked to \textbf{brings together government staff
-and development team}.  At the beginning of the project, the interviewed MPOG
+\textit{\textbf{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
@@ -93,7 +88,7 @@ In the second phase of the project, these analysts came to represent the
 government directly in the dialogues with the academia, and they started to
 visit bi-weekly the university's laboratory. One of the analysts believed that
 \textit{``at this point, the communication started to change.''}. The new
-dynamic \textit{reduced communication misunderstandings and unified the two
+dynamic \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
@@ -117,13 +112,13 @@ The implementation of a Continuous Delivery pipeline also reinforced the teams&#39;
 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 regarding the low productivity of
+\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 what we did with the quality we delivered.''}. Additionally, the
-deployment of each new version also \textbf{improve the translation of the
+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 a strategic level view. When we went to the technical level, we had
 difficulty to plan each four-month release. However, in the final stages of the
@@ -133,15 +128,15 @@ qualified, the code had quality, and the project was well executed. So in
 practice, our difficulty interpreting the technical details did not impact
 release planning.''}.
-The project leaders \textbf{divided the 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
+\textit{\textbf{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 of them, at least one professional in the IT market was
-hired to raise the quality of the product. Senior developers have a vast
-experience in the FLOSS systems and tools used in the project.
+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 participation of senior developers in the project contributed to
+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
@@ -166,14 +161,14 @@ the project for all of them. {75\%} of the senior developers believed that ``Wor
 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
-taught by them to a intern was widespread among the others in the team.
-Government analysts also pointed this acquisition of knowledge: \textit{``On
+shared by them to a intern was widespread among the others in the team.
+Government analysts also pointed this knowledge sharing: \textit{``On
 the side of the universities, what we noticed was a significant improvement in the platform
 with the hiring of the original developers of the systems. They had a guide on
 how to best develop each feature and were able to solve non-trivial problems
 quickly.''}.
-Dividing the development team and hiring senior developers allowed each team to
+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
@@ -13,88 +13,112 @@ different management processes is crucial, since the poor and unadaptable
 management could lead the project to fail, resulting in the waste of
 population-funded resources.
-\begin{table}[hbt]
+We investigated the management method employed at the SPB portal project, a
+partnership between the Brazilian government and universities. The development
+leaders empirically built an approach using FLOSS and agile development
+practices and values.  As a result, we identified a set of best practices which
+improves the workflow and relationship between the organizations involved.  Our
+results reveal a set of nine management practices successfully employed in
+abovementioned case.  We analyzed unsystematic decisions made during 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. The Table \ref{practices-table} summarizes
+macro-decisions, practices, and benefits.
+
+Regarding our first research question \textit{``How to introduce open source and
+agile best practices into government-academia collaboration projects?''}, we
+examined the SPB project and identified three macro-decisions taken by the
+academic coordinators that led them to intuitively and non-systematically adopt
+FLOSS and agile practices in the development process. We extracted nine best
+management practices and verified their efficient use collecting data from the
+management tool and interviewing the project participants.
+
+The interviewed responses allowed us to understand how FLOSS and agile
+practices have benefited the people and project management. Based on that, we
+answered our second research question \textit{``What practices favor
+effective team management in government-academia collaborative projects?''},
+making to explicit in Table \ref{practices-table} eleven benefits obtained from
+the use of the nine best practices.
+
+\vspace*{-.5cm}
+
+\begin{table}[h]
 \centering
+\def\arraystretch{1.2}
+\setlength\tabcolsep{0.2cm}
 \resizebox{\textwidth}{!}{%
-\begin{tabular}{ | m{4cm} m{10cm} m{10cm} | } 
-\hline
-\textbf{Decision} & \textbf{Practice Explanation} & \textbf{Benefits} \\ \hline
-\textbf{Use of the system under development to develop the system itself} &
+\begin{tabular}{  m{4cm} m{8cm} m{8cm}  } 
+\rowcolor[HTML]{b7d0b9} 
+\textbf{Decision} & \textbf{Practice Explanation} & \textbf{Benefits} \\
+\rowcolor[HTML]{fafafa} 
+\begin{flushleft}
+\textbf{Use of the system under development to develop the system itself}
+\end{flushleft} &
+\begin{flushleft}
 \begin{itemize}
+\setlength{\itemsep}{2pt} 
 \item The features and tools of the platform under development supported the project management and communication activities.
-\end{itemize} &
+\end{itemize}
+\end{flushleft} &
+\begin{flushleft}
 \begin{itemize}
+\setlength{\itemsep}{2pt} 
 \item Communicating with transparency and efficiency; 
 \item Monitoring of activities;
 \item More interactions between developers and public servants;
 \item Trust the developed code;
 \item Organic documentation;
-\end{itemize} \\ \hline
-
-\textbf{Bring together government staff and development team} &
-\begin{itemize} 
+\end{itemize}
+\end{flushleft} \\ 
+\rowcolor[HTML]{f2f2f2}
+\begin{flushleft}
+\textbf{Bring together government staff and development team}
+\end{flushleft} &
+\begin{flushleft}
+\begin{itemize}
+\setlength{\itemsep}{2pt} 
 \item Government staff, academic coordinators, senior developers and team coaches biweekly meet at the university 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} &
+\item Build a continuous delivery pipeline with stages involving both sides.
+\end{itemize} \end{flushleft} &
+\begin{flushleft}
 \begin{itemize} 
+\setlength{\itemsep}{2pt} 
 \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} &
+\item Sharing a common understanding of the process from one side to the other.
+\end{itemize} \end{flushleft}  \\ 
+\rowcolor[HTML]{fafafa}
+\begin{flushleft} 
+\textbf{Organize the development team into priority fronts, and for each one, hire at least one specialist from the IT market}
+\end{flushleft} &
 \begin{itemize}
+\setlength{\itemsep}{2pt} 
 \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}
+\setlength{\itemsep}{2pt} 
 \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{itemize}\\
 \end{tabular}%
 }
 \caption{Empirical SPB management decisions and its benefits.}
 \label{practices-table}
 \end{table}
-\vspace{-.9cm}
+\vspace*{-1cm}
-We investigated the management method employed at the SPB portal project, a
-partnership between the Brazilian government and universities. The development
-leaders empirically built an approach using FLOSS and agile development
-practices and values.  As a result, we identified a set of best practices which
-improves the workflow and relationship between the organizations involved.  Our
-results reveal a set of nine management practices successfully employed in
-abovementioned case.  We analyzed unsystematic decisions made during 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. The Table \ref{practices-table} summarizes
-macro-decisions, practices, and benefits.
-
-Regarding our first research question \textit{``How to introduce open source and
-agile best practices into government-academia collaboration projects?''}, we
-examined the SPB project and identified three macro-decisions taken by the
-academic coordinators that led them to intuitively and non-systematically adopt
-FLOSS and agile practices in the development process. We extracted nine best
-management practices and verified their efficient use collecting data from the
-management tool and interviewing the project participants.
-
-The interviewed responses allowed us to understand how FLOSS and agile
-practices have benefited the people and project management. Based on that, we
-answered our second research question \textit{``What practices favor
-effective team management in government-academia collaborative projects?''},
-making to explicit in Table \ref{practices-table} eleven benefits obtained from
-the use of the nine best practices.
 The results of this current work corroborate the lessons learned in our
 previous work on studying the SPB project case \cite{meirelles2017spb}.
@@ -105,25 +129,24 @@ academic side. In short, the government staff had difficulty to understand how
 collaboration works. They took 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. Finally, they also felt the project needed
-a decision-maker role to resolve impasses between organizations, and the
+a decision-maker role to solve the impasses between organizations, and the
 development coordinators sometimes took on that.
 The decisions, practices, and benefits presented in the Table
 \ref{practices-table} should be evaluated and used in contexts with more
-substantial plurality and diversity of government stakeholders. As threats to
-the validity of this work, we point out the lack of communication records and
+substantial plurality and diversity of government stakeholders. This study has
+a few obvious limitations. Firstly, we point out the lack of communication records and
 low traceability 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. Secondly, we consider a drawback the hiatus between the completion of the
 project and the conduction of interviews and questionnaires, since we rely on
-the memory of the interviewees to rescue the events. Furthermore, the new work
+the memory of the interviewees to rescue the events. Lastly, 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
+mindset may also modify their perceptions on the topics addressed in the
 questionnaire and consequently their responses.
 Finally, we collected a significant amount of data and testimonials related to
-the teaching of software engineering. We consider that the project studied is
-also an educational case. It is an example of how to teach information
-technology students FLOSS and agile approaches applied to production-level
-software development. As future work, we intend to analyze this collected
-information to propose improvements in the teaching of software engineering for
-undergraduates.
+the teaching of software engineering. We consider the project studied an
+educational case, an example of teaching FLOSS and agile techniques applied to
+real-world software development. As future work, we intend to analyze this collected
+information to propose improvements in software engineering undergraduates
+education methodology.
-\documentclass{llncs}
+\documentclass{llncs}
+\usepackage[table,xcdraw]{xcolor}
 \usepackage{llncsdoc}
 \usepackage{graphicx,url}
 \usepackage[utf8]{inputenc}
 \usepackage{float}
 \usepackage{setspace}
-
+\usepackage{hyphenat}
 \usepackage{tabularx}
 \usepackage{cite}
 \usepackage{hyperref}
 \usepackage{comment}
 \usepackage{todonotes}
+\usepackage{colortbl}
 %------------------------------------------------------------------------------
 \begin{document}
1	\begin{abstract}	1	\begin{abstract}
2		2
3	-Government and academia can collaborate on bringing innovation and filling design-reality gaps in e-government projects. However, differences in project management methods employed by the organizations is often a challenge for collaborative works. Bearing that in mind, we investigated a 30-month government-academia partnership to find appropriate ways to get around this obstacle. From the analysis of \textit{post-mortem} data as well as the results of questionnaires and interviews with project participants, we present a set of best practices based on FLOSS and agile software development approaches that favors team management in government-academia collaborations in e-government development projects.	3	+Government and academia can collaborate on bringing innovation and filling
		4	+design-reality gaps in e-government projects. However, differences in project
		5	+management methods employed by the organizations is often a challenge for
		6	+collaborative works. Bearing that in mind, we investigated a 30-month
		7	+government-academia partnership to find appropriate ways to get around this
		8	+obstacle. From the analysis of \textit{post-mortem} data as well as the results
		9	+of questionnaires and interviews with project participants, we present a set of
		10	+best practices based on FLOSS and agile software development approaches that
		11	+favors team management in government-academia collaborations in e-government
		12	+development projects.
4		13
5	\end{abstract}	14	\end{abstract}
6		15
7	-\keywords{Open Source Software, Free Software, Agile Methods, Best Practices, Project Management, E-Government.}	16	+\keywords{Open Source Software, Free Software, Agile Methods, Best Practices,
		17	+Project Management, E-Government.}