Abstract
How many software practitioners use agile methods in Brazil? We currently have little knowledge about Brazilian developers profile and about the software processes applied. One of the issues that remain unanswered is whether these practitioners are using agile software processes or not. With the aim to start filling this gap, we conducted a study with the objective to identify whether Brazilian software practitioners are agile. Our research approach was the survey as the method for collecting data. We applied a clustering algorithm to analyze data and characterize the software process, and text mining techniques to identify respondents perceptions of their software processes. Our results show a preliminary profile for Brazilian software processes and practitioners positive and negative perceptions about these processes. We contribute with a method to characterize agile, traditional and hybrid software processes.
Keywords
This research project is supported by CNPQ (National Council for Scientific and Technological Development) – Process Number 408976/2016-0.
1 Introduction
How many software practitioners use agile methods – or “are agile” – in Brazil? Actually, we know very little about it. Softex (Association for Promoting the Excellence of Brazilian Software) performed the last government research on software and information technology (IT) services more than five years ago. They characterized the industry (number of people, revenues, among others), and mapped competencies, human resources and tendencies [25]. However, this census did not include information that is specific to software development companies, e.g., how people develop software or, more specifically, whether agile methods have spread in Brazil.
Recent world-wide surveys have been describing developers’ profiles and practices [26, 27]. These researches are important because they describe current software development situation providing basis for decision makers in companies and for new studies in academy. Nevertheless, only about 2% of these results represent Brazilian situation. In academic literature, recent surveys we found with Brazilian practitioners have presented specific aspects of software development [1, 14, 15] but no information about software process was provided.
To start filling this gap, this study presents preliminary findings of a survey that aims at mapping whether we are agile – or not – in Brazil. The research question that drives our study is “what is the percentage of Brazilian software developers that use agile methods?”. When conducting this research, we kept in mind two issues that differ from other surveys. The first was conceiving a short questionnaire that could be answered in two minutes, to increase the probability of getting bigger sample sizes [2]. The second was creating a way to identify whether practitioners’ processes are agile without asking them specifically which software process models they are using. We have recent evidence that, in practice, software processes are a mix of methods [7, 9], thus our research captures the essence of software process avoiding bias due to respondent’s judgment.
Facing the challenges of creating a survey to be quickly answered and not asking respondent which his/her software process is, we ended up with findings not only related to the data collected, but we also provide a methodological contribution on software process mapping. Next section describes related work, Sect. 3 describes the challenge on defining a few characteristics to identify whether the software process is agile or not. Section 4 describes our research approach. Next, we present our results and, finally, discussions and conclusions.
2 Related Work
Although big companies around the world commonly perform practitioners’ surveys about software development in general [26, 27], recent academic surveys have been focusing on specific aspects of the practices or methods applied in software development.
The work of [10], for example, investigated software testing practices in Canada. They described the results obtained from 246 responses from local practitioners. The contributions of the authors were describing latest trends in software testing industry and pointing out strengths and weaknesses.
Other examples of industry surveys are described by [11] and [12]. The work by [11] investigated agile requirement engineering practices and their importance. Their results were based on 136 practitioners’ responses mainly from US, Poland, UK, India and Germany. The study by [12] described practitioners’ knowledge and perceptions of technical debt effects. They surveyed 184 practitioners from Brazil, Finland and New Zealand. These studies aimed at describing specific aspects (such as testing, requirements, technical debt) of software engineering in different countries, providing an international view of a few elements.
Differently, the work presented by [7] is a world-wide survey, but they investigated software practices in general to characterize hybrid software development. They identified used approaches, how they are combined and how contextual factors influence the combination of different approaches for development.
Regional surveys investigating software practices in general are scarcer. We found the work by [13], which described software engineering practices in Turkey. They got 202 responses for a questionnaire with 46 questions, mainly based on Software Engineering Body of Knowledge (SWEBOK). Their findings included a general description of software development sectors, measurement methods, efforts employed in each phase of development cycle, software process models used, among others.
In Brazil, specific studies are also found, such as the one by [14], which complies a survey that described agile software development adoption, the one by [1], which presented critical success factors for software projects and the one by [15], with results from a survey about the use of Unified Modeling Language (UML) and model-driven approaches in embedded software development.
Our study contributes to the literature by presenting general findings for Brazilian software development sector and thus identifying whether practitioners use agile methods or not. Next section describes the foundation to our approach.
3 The Challenge on How to Identify an Agile Process
The simplest way to identify whether practitioners use agile methods or not is asking them: “are you agile?”. The answer is not simple, though. Most software processes are not a pure application of a single method [7], once organizations customize their development processes – adopting and abandoning practices – very easily [8].
To accomplish the challenge on conducting a survey that identifies software processes, we decided thus not asking people which development methods they use. Instead, we defined our survey constructs [16] based on the literature that evaluates agile methods adoption.
The first reference to evaluate agility are the Agile Manifesto Principles [28]. According to these principles, agile software development must satisfy customers, accept requirements changes, deliver working software frequently, make developers and customers work together, build projects with motivated individuals, stimulate face-to-face conversation, measure progress with working software, promote sustainable development, stimulate technical excellence, allow team’s self-organization and promote a reflective work process.
Some researchers have been working on agility assessment models, with the aim to evaluate agile adoption. These models also allow characterizing agility because they define how – in practice – agility could be identified in real teams. We analyzed four models: Sidky et al.’s [20], Qumer and Henderson Sellers’ [19], Özcan-Top and Demirörs’ [17, 18] and Fontana’s [21].
Sidky et al. [20] present the agility measurement index (SAMI). It is a five-level maturity model to determine the highest level of agility for a project or organization. For each level, more than forty agile practices are distributed through five agile principles: embrace change to deliver customer value, plan and deliver software frequently, human-centric, technical excellence and customer collaboration.
With a similar foundation as Sidky’ model, Qumer and Henderson-Sellers [19] present the Agile Adoption and Improvement Model (AAIM). The model identifies six stages for agile improvement, based on agile principles. Each stage defines a group of practices to be implemented starting with an “Agile Infancy”, passing through “Agile Initial”, “Agile Realization”, “Agile Value”, “Agile Smart”, and getting to an “Agile Progress”.
Özcan-Top and Demirös [18] present the Software Agility Assessment Model (AgilityMOD). The content in their paper is complemented by a technical report [17]. This model was developed based on ISO/IEC 15504 International Standard. They defined aspects attributes grouped into agility levels. Each aspect attribute is related to agile principles and are defined as: “Performing Aspect Practices”, in the first level; “Simple” and “Iterative”, in the second level; “Technically Excellent”, in the third level; and “Learning” for the fourth level. The agility of one aspect is, then, evaluated in a four-point scale: “Not implemented”, “Ad-hoc”, “Lean” and “Effective”, which are the agility levels.
The most recent work we found was the one presented by Fontana et al. [21]. The authors proposed the Agile Compass, a tool to identify maturity in agile software development teams. This tool was developed based on an empirical study that identified the evolvement of nine agile teams. Their proposal is not based on levels, but on outcomes that teams should pursue. There is therefore no specific path to maturity. Authors identified seven categories of outcomes: practices learning, team conduct, pace of deliveries, features disclosure, software product, customer relationship and organizational support.
We have extracted from each of these authors the characteristics of agility, by analyzing how they defined a mature team, that is, a team that is actually agile, as described in Table 1. We also analyzed the agile principles defined in the Agile Manifesto [28] and chose three of them. The characteristics of Sidky et al. [20] were not included because they proposed more than 40 items do define agility and it would go against our purpose of a short questionnaire. As our proposal was to create a short survey, we selected only the characteristics that were straightforward to be evaluated and did not involve discussions about organizational culture and personnel issues.
By combining the characteristics of agility selected from these studies, we identified that they were related to four main aspects of the software process: requirements definition (based on characteristics 1, 6, and 10), software documentation (based on characteristic 3), development activities planning (based on characteristics 5 and 8) and delivery of working software (based on characteristics 2, 4, 7, and 9).
We understand that the essence in the difference between traditional and agile processes is the moment when each of these aspects are emphasized during software development, as dynamism is one of the key differences between the two approaches [23]. We then based our survey in this assumption, as explained in the next section.
4 Research Approach
The objective of this study was identifying the percentage of Brazilian software practitioners using agile software development methods. The research approach was the survey, defined by [16] as a method that collects information from individuals to contribute to knowledge in a particular area of interest. Our results are descriptive, as we aim at describing the distribution of a phenomenon – agile methods usage, in a population – software development practitioners [16].
According to Forza [16], conducting a survey must include the following subprocesses that lead to getting the desired results: (1) translating the theoretical domain into the empirical domain; (2) designing and pilot testing; (3) collecting data for theory testing; (4) data analysis process; and (5) the process of interpreting the results and writing the report. Next subsections describe how the first four of these subprocesses were performed in this study.
4.1 Translation of the Theoretical Domain into the Empirical Domain
As described in Sect. 3, we investigated studies that defined how to characterize and evaluate agility [18,19,20,21], besides considering the definitions of the Agile Manifesto principles [28]. Our unit of analysis was the software development practitioner, as a representative of the method used inside companies.
We avoided asking respondents which methods or approaches they use for software development, as evidences from modern software development show that processes and practices are mixed and combined [7, 9]. Asking a respondent to classify its own process would lead to potentially subjective decisions when answering the questionnaire. For example, does the simple definition of sprints in a software project planning characterize the use of Scrum? An inexperienced developer could say that yes, but the reality might not be that. This is the reason we based our questionnaire in studies that characterize and evaluate agility despite of the method used.
From these theoretical and empirical references, we extracted a minimum number of items that could in a straightforward way to characterize agility and allow our respondents to quickly answer our questions. We based our definitions on the premise of creating a short questionnaire that could be answered in two minutes. As stated by Pfleeger and Kitchenham [3, p. 21], “it is important to keep in mind that the number of questions you can realistically ask in a survey depends on the amount of time respondents are willing to commit to it”. We wanted to potentially increase sample size by creating a questionnaire that could be answered by more people [2].
Section 3 showed the characteristics extracted from each author and how they were combined to create the questionnaire. Respondents were asked to place these aspects in specific moments in their software processes, using as a reference the moment when software is coded. The final questionnaire was really short, comprising:
-
1.
In which state of Brazil do you work at?
-
2.
How many years of experience do you have with software development?
-
3.
What is your educational level?
-
4.
What is your gender?
-
5.
In the software project you are currently working, please identify in which moment the following activities happen (before coding, throughout coding, after coding, or do not know):
-
(a)
Requirements definition
-
(b)
Software documentation
-
(c)
Development activities planning
-
(d)
Delivering working software
-
(a)
-
6.
Summarize the positive aspects of your software process using 5 key-words (open-ended question)
-
7.
Summarize the negative aspects of your software process using 5 key-words (open-ended question).
4.2 Design and Pilot Testing
The questionnaire was designed and pilot-tested in two steps: a focus group and a pilot study. For the focus group, the first version was created, printed and tested with 10 master and doctorate students. They evaluated language, form and response time. The suggestions were accepted and the tested version was completely changed to the final version.
This final version was created on-line and pilot-tested with 25 software practitioners in authors’ colleagues network. In addition to answering the questions of the questionnaire, we asked them to tell us whether their processes were agile, traditional or hybrid. We did it to test the clustering techniques we were planning to apply for data analysis (see Sect. 4.4). The responses were processed, and data analysis was tested. The question on which process the respondent used was removed for the questionnaire to be distributed.
4.3 Collecting Data
Sampling is a concern in surveys, as samples must be representative of the whole population. Ideally, all surveys should use random samples, as they are the only format that create statistically valid results [2]. In this study it was not possible as we do not have access to the whole population (all software developers in Brazil), thus we applied a non-probabilistic convenience sample.
Convenience samples are those that represent people that are available and willing to take part of the survey [2]. We used social networks and personal contacts to propagate the call for respondents. We made our questionnaire available on-line for two weeks.
4.4 Data Analysis
We applied three different types of data analysis: clustering, descriptive statistics and text mining. The clustering technique was applied to group respondents according to similar software processes. We analyzed the moment in which the respondent defined requirements, documented software, planned activities and delivered software. Responses were grouped using the k-means algorithm through R language (libraries RWeka and cluster). We defined three resulting clusters, and, for each cluster, we used a histogram to identify how answers were distributed in the different moments (before, throughout or after coding).
We chose to create three clusters to possibly accommodate agile processes, traditional processesFootnote 1 and a third group that could show up with different characteristics (such as the hybrid processes defended by [7]).
The text mining technique was used to analyze the two open-ended questions. The answers given by respondents to the positive and negative aspects of their software processes were analyzed using a frequency of terms analysis (by using the tm library from R language). We first analyzed the frequency of terms individually and then the frequency of bi-grams. Individual terms analysis allows us to identify most cited terms and then the analysis of related bi-grams eases the understanding of the context where terms were cited in responses.
4.5 Threats to Validity
There are four types of validity to be dealt with in survey studies. The face validity guarantees that the measure reflects the content of the concept in question [22]; the content validity, which is a “subjective assessment of how appropriate the instrument seems to a group of reviewers” [4, p. 22]; the criterion validity, which compares the instrument against one that is considered the “gold standard” [4, p. 22]; and the construct validity that concerns “how an instrument behaves when used” [4, p. 22]. In this research, content and construct validity were tested in the focus group and in the pilot-test. Criterion validity could not be measured, as we do not have a “gold standard” as reference.
Generalization is also a concern in surveys. Although [22] states that increasing the absolute number of respondents in the sample does not increase generalization, it is know that the more respondents, the lower the error rate in the results. With about a hundred respondents, we consider that the results of this study represent practical relevance, which means that it matters to practitioners [5]. This study presents preliminary results, as we wish to continue collecting data to compare with the findings here presented. This is one of the strategies that can be applied to assure practical relevance in a research [6].
5 Results
We received 129 valid responses. Respondents were 81% male and 19% female. Their educational level was 2% high school, 40% undergraduate, 11% MBA (Master Business Administration), 34% attended post-graduation courses, 11% had master degree and 2% doctoral degree. Their experience with software development was 20% up to 2 years; 26% from 3 to 5 years; 28% from 6 to 10 years; 26% from 11 to 20 years and 5% more than 20 years. Considering their location in Brazil, they are distributed in ten different states, as shown in Table 2.
Our driving objective in this study was to discover the percentage of software developers that use agile methods in Brazil. As explained in Sect. 4, we identified it by asking about some dynamics in their software processes. The responses were then clustered in three groups according to the similarity of the answers practitioners gave regarding the moment in which they define requirements, document the software, plan activities and deliver software. As a result of the clustering algorithm, we got 54% of respondents in Group 1, 26% in Group 2 and 20% in Group 3. The characteristics of each group are as follows.
Figure 1 shows the results for Group 1. The answers in this cluster reported to define requirements mainly before coding (96% of respondents). They document software mainly throughout coding (64%), but also before coding (36%). Regarding the planning of development activities, they reported to perform mostly before coding (69%) and some throughout coding (31%). Their software delivery is mainly performed after coding (60%), but also throughout coding (38%).
The second group that resulted from the clustering analysis presents a different behavior (see Fig. 2). They reported to define requirements mainly before coding (82%), and some of them throughout coding (18%). Their software documentation is performed mainly after coding (71%). On respect to development activities planning, respondents said that it is done mainly before coding (68%) and a few throughout coding (26%). For them, software is delivered mainly after coding (76%), and some reported to do it throughout coding (21% of responses).
Group 3 (Fig. 3) presents another configuration of responses distribution. On respect to requirements definition, they reported to do it mainly throughout coding (80% of responses). Software is documented either throughout coding (52%) and after coding (40%). Activities are planned also throughout coding (56%) and before coding (40% of responses). For this group, software is delivered mainly throughout coding (84%).
According to the characteristics of these groups, by comparing the different moments when activities are performed, we observe clear evidences of the essence of their software processes. Group 1 is the hybrid group, mainly because there is a distribution of requirements and planning before and throughout coding. Delivery is also performed throughout and after coding. Group 2 is the traditional group, with the evidences of requirements and planning being performed mainly before coding, and delivery mainly after coding. The agile group is the Group 3, with requirements definition mainly throughout coding, activities planning before and throughout coding, and software delivery mainly throughout coding.
As Group 1 was the one with more respondents, we conclude, then, that we have mainly software development practitioners working with hybrid processes in Brazil (54%), then with traditional processes (26%) and the least number of practitioners are the ones that work with agile processes (20%).
We also asked respondents about positive and negative aspects of their processes. We analyzed the responses for each of the groups separately so that we could then better characterize them, as shown in the next subsection.
5.1 Perceptions on the Software Process
Positive and negative aspects of software processes were pointed out by respondents through keywords. We considered the terms that appeared the most, the top-3 frequencies. Table 3 shows terms frequencies for hybrid processes, Table 4 shows for traditional processes and Table 5 for agile processes.
We can notice that positive aspects of hybrid processes are mainly related to documentation and agility/agile. In the analysis of software process activities moments (Sect. 5) this group pointed out to document software before and throughout coding, which is shown here to be positive for practitioners. By analyzing related bi-grams, we observe that practitioners value consistent and viable documentation and various aspects related to agility (projects, delivery, flexibility, quality, etc.). We also found positive key-words related to delivery, quality, customer, team and planning. The main negative aspect pointed out by the hybrid group was “lack”. In this case, the analysis of the bi-grams was important to understand which kind of lacks they feel. The main complaints were lack of communication, experience, feedback, management, staff and visibility.
For the traditional processes group, the positive aspects are mainly related to agility/agile and delivery. It seems to be contradictory that people that use traditional processes value agility. But this is probably due to the fact that people do mix processes and present some evidences of trial to be agile. By analyzing related bi-grams, we could notice that practitioners related agile and agility to collaboration, reliability, delivery, focus. Other positive aspects also mentioned were focusing at customer and quality. As negative aspects for the traditional group, we identified “lacks”, but, differently of hybrid processes, the terms that appeared were lack of empathy, capacity, knowledge, control, documentation, metrics, quality assurance, resources. The “low” term was referred to quality and resilience.
For the agile processes group, the most frequent positive aspects were also related to agility and delivery. Related bi-grams show terms as adaptive agile, agile delivery, dynamics, fast delivery, value delivery, among others. Negative terms appeared mainly related to documentation (missing of documentation, late documentation, stress related to documentation, time to document). By combining this data with the moments when they perform they activities, we see software being documented throughout and after coding, which seems to be negative for this group. There were also complaints of “lack”: of knowledge, staff, information, planning and requirements. The only group where “bugs” appeared in negative aspects was the agile one. Other terms are presented in Table 5.
6 Discussion and Conclusions
The objective of this study was to identify the percentage of software development practitioners that use agile methods in Brazil. We identified that this is the least used method, reported by 20% of participants, as opposed to traditional methods, reported by 26%, and the most used, the hybrid process, reported by 54% of respondents.
To accomplish this objective, we did not ask practitioners whether they were agile. We instead asked objective questions about activities in their software processes and inferred their characteristics based on a clustering analysis. We also searched for positive and negative aspects of different process configurations.
Our results are in accordance with evidences that software processes are highly customized [8, 9]. We saw most respondents taking part of a hybrid process that presents agile and traditional characteristics. It is an evidence that we are probably living what Boehm and Turner [23] previewed more than a decade ago, a balance and integration of agile and plan-driven methods. Despite of the process model used, agility was pointed out as a positive aspect in all of them, evidencing the willing to be agile.
Some years ago, the work by [14] showed that the usage of agile methods was rising, as also stated by agile industrial surveys [29]. With our results we consider people are using agile, but not as the “silver bullet”. Agile practices are mixed with traditional ones because software development practitioners actually focus on having the job done [24].
Our results are limited to our sample. As we stated, we consider these as preliminary results, as we wish to collect more responses for this survey and complete and compare data. Nevertheless, these findings show evidence of Brazilian software processes and provide basis for other academic studies that might wish to better understand the dynamics of the aspects we investigated in the software process. Our method to characterize the software process could also be replicated and retested in other configurations.
Notes
- 1.
As opposed to agile, traditional processes could also be called plan-driven processes, such as stated by [23].
References
Dal Forno, G.M.B., Muller, F.M.: Fatores Críticos em Projetos de Desenvolvimento de Software. In: Pretexto 2017, vol. 18, no. 2, pp. 100–105 (2017). https://doi.org/10.21714/pretexto.v18i2.5295
Pfleeger, S.L., Kitchenham, B.A.: Principles of survey research - part 5: populations and samples. Softw. Eng. Notes 27(5), 17–20 (2002)
Pfleeger, S.L., Kitchenham, B.A.: Principles of survey research - part 3: constructing a survey instrument. Softw. Eng. Notes 27(2), 20–24 (2002)
Pfleeger, S.L., Kitchenham, B.A.: Principles of survey research - part 4: questionnaire evaluation. Softw. Eng. Notes 27(3), 20–23 (2002)
Kitchenham, B.A., et al.: Preliminary guidelines for empirical research in software engineering. IEEE Trans. Softw. Eng. 28, 721–734 (2002). https://doi.org/10.1109/TSE.2002.1027796
Lee, A.S., Mohareji, K.: Linking relevance to practical significance. In: Proceedings of the 45th Hawaii International Conference on System Sciences, Maui, 4–7 January, pp. 5234–5240 (2012). https://doi.org/10.1109/HICSS.2012.416
Kuhrman, M., et al.: Hybrid software and system development in practice: waterfall, scrum and beyond. In: Proceedings of the 2017 International Conference on Software and System Process, ICSSP 2017, France, pp. 30–39 (2017). https://doi.org/10.1145/3084100.3084104
Bustard, D., Wilkie, G., Greer, D.: The maturation of agile software development principles and practice: observations on successive industrial studies in 2010 and 2012. In: Proceedings of the International Conference and Workshops on the Engineering of Computer Based Systems, Scottsdale, AZ, pp. 139–146. IEEE (2013)
Campanelli, A.S., Camilo, R.D., Parreiras, F.S.: The impact of tailoring criteria on agile practices adoption: a survey with novice agile practitioners in Brazil. J. Syst. Softw. 137, 366–379 (2018). https://doi.org/10.1016/j.jss.2017.12.012
Garousi, V., Zhi, J.: A survey of software testing practices in Canada. J. Syst. Softw. 86(5), 1354–1379 (2013). https://doi.org/10.1016/j.jss.2012.12.051
Ochodek, M., Zopczyńska, S.: Perceived importance of agile requirements engineering practices - a survey. J. Syst. Softw. 143, 29–43 (2018). https://doi.org/10.1016/j.jss.2018.05.012
Holvitie, J., et al.: Technical debt and agile software development practices and processes: an industry practitioner survey. Inf. Softw. Technol. 96, 141–160 (2018). https://doi.org/10.1016/j.infsof.2017.11.015
Garousi, V., Coskunçay, A., Betin-Can, A., Demirörs, O.: A survey of software engineering practices in Turkey. J. Syst. Softw. 108, 148–177 (2015). https://doi.org/10.1016/j.jss.2015.06.036
Melo, C., et al.: The evolution of agile software development in Brazil. J. Braz. Comput. Soc. 19, 523–552 (2013). https://doi.org/10.1007/s13173-013-0114-x
Agner, L.T.W., Soares, I.W., Stadzisz, P.C., Simão, J.M.: A Brazilian survey on UML and model-driven practices for embedded software development. J. Syst. Softw. 86(4), 997–1005 (2013). https://doi.org/10.1016/j.jss.2012.11.023
Forza, C.: Survey research in operations management: a process-based perspective. Int. J. Oper. Prod. Manag. 22(2), 152–194 (2002)
Özcan-Top, Ö., Demirörs, O.: Software agility assessment reference model v 3.0 (Agility MOD). Technical report METU/II-TR-2014-39 (2014)
Özcan-Top, Ö., Demirörs, O.: Assessing software agility: an exploratory case study. In: Mitasiunas, A., Rout, T., O’Connor, R.V., Dorling, A. (eds.) SPICE 2014. CCIS, vol. 477, pp. 202–213. Springer, Cham (2014). https://doi.org/10.1007/978-3-319-13036-1_18
Qumer, A., Henderson-Sellers, B.: A framework to support the evaluation, adoption and improvement of agile methods in practice. J. Syst. Softw. 81(11), 1899–1919 (2008). https://doi.org/10.1016/j.jss.2007.12.806
Sidky, A., Arthur, J., Bohner, S.: A disciplined approach to adopting agile practices: the agile adoption framework. Innov. Syst. Softw. Eng. 3(3), 203–216 (2007). https://doi.org/10.1007/s11334-007-0026-z
Fontana, R.M., Reinehr, S., Malucelli, A.: Agile compass: a tool for identifying maturity in agile software-development teams. IEEE Softw. 32(6), 20–23 (2015). https://doi.org/10.1109/MS.2015.135
Bryman, A.: Social Research Methods, 4th edn. Oxford University Press, New York (2012)
Boehm, B., Turner, R.: Balancing agility and discipline: evaluating and integrating agile and plan-driven methods. In: Proceedings of the 26th International Conference on Software Engineering, 23–28 May, pp. 718–719 (2004). https://doi.org/10.1109/ICSE.2004.1317503
Adolph, S., Krutchen, P., Hall, W.: Reconciling perspectives: a grounded theory of how people manage the process of software development. J. Syst. Softw. 85, 1269–1286 (2012). https://doi.org/10.1016/j.jss.2012.01.059
Softex: Software e servićos de TI: A Indústria Brasileira em Perspectiva (2012). http://www.softex.br/inteligencia/. Accessed 9 July 2018
Stackoverflow: Developers survey results (2018). https://insights.stackoverflow.com/survey/2018/. Accessed 9 July 2018
O’Reilly: O’Reilly Software Development Salary Survey (2017). https://www.oreilly.com/ideas/2017-software-development-salary-survey. Accessed 9 July 2018
Agile Manifesto Principles (2001). http://agilemanifesto.org/principles.html. Accessed 9 July 2018
Version One: 12th State of Agile Survey (2018). http://stateofagile.versionone.com/. Accessed 12 July 2018
Author information
Authors and Affiliations
Corresponding author
Editor information
Editors and Affiliations
Rights and permissions
Copyright information
© 2019 Springer Nature Switzerland AG
About this paper
Cite this paper
Cesa, L.O.A., Mantovani Fontana, R., Reinehr, S., Malucelli, A. (2019). Are We Agile or Not? A Survey on Brazilian Software Processes. In: Tonin, G., Estácio, B., Goldman, A., Guerra, E. (eds) Agile Methods. WBMA 2018. Communications in Computer and Information Science, vol 981. Springer, Cham. https://doi.org/10.1007/978-3-030-14310-7_2
Download citation
DOI: https://doi.org/10.1007/978-3-030-14310-7_2
Published:
Publisher Name: Springer, Cham
Print ISBN: 978-3-030-14309-1
Online ISBN: 978-3-030-14310-7
eBook Packages: Computer ScienceComputer Science (R0)