The evolution of agile software development in Brazil

Abstract

Agile software development methods have been increasingly adopted worldwide and became one of the mainstream software development approaches. Agile methods have also had an impact on software engineering education with universities adapting their courses to accommodate this new form of software development. Software engineering research has tried to evaluate the impact of agile methods in industrial projects and discover in which situations it is beneficial to apply such methods. However, there are almost no studies focusing on the progress of the agile movement in Brazil. In this paper, we present an overview of the evolution of the agile movement in Brazil, outlining the history of its first advocates in academia and industry. We describe existing educational initiatives, discuss the impact of the agile development on the national research, and present a report on the agile state-of-the-practice in the Brazilian IT industry.

1 Introduction

The birth of the agile movement around the year 2000 has strong roots in the history of software engineering. The agile ideas echoed previous works such as The Mythical Man-Month: Essays on Software Engineering by Brooks [8] and the concept of rapid prototyping by Naumann and Jenkins [45]. They were a consequence of a variety of factors, ideas, and proposed best practices that arose mainly in the context of the object-oriented programming community. Even though being a remarkable change in software development thinking, these ideas have been around since the 1970s or even before as explained by Abbas et al. [1]. Because they were not treated seriously enough, it took about 30 years for them to be recognized as an effective way to develop software.

Multiple researcher and practitioner groups gathered in larger communities, such as the one around the ACM International Conference on Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA), and produced the ideas that led to the development of the concept of agile software development. The role of the Smalltalk programming language community was also fundamental. Three important points from that community led to changes. The first was Smalltalk’s minimal syntax that let programmers write code that looked like natural language sentences. The first was Smalltalk’s minimal syntax that let programmers write code that mimics natural language sentences [23]. For example, well written Smalltalk code can look like a sentence in English, e.g., Clock display Time now. The second was its dynamic typing that provided high flexibility. Lastly, a powerful programming environment centered around its dynamic and flexible class browser that influenced modern IDEs. Due to these characteristics, Smalltalk fostered the development of the technology and the spirit that enabled a different way of developing software.

During the 1990s, a combination of factors produced a fertile land for the growth of agile ideas [1]. First, there was a reaction to heavyweight, prescriptive approaches to software development. Second, the increasing level of change in the business environment urged practitioners to handle complex and unpredictable requirements in systems development. Thus, practitioners started to revisit old alternative ways of developing software such as the iterative and incremental development and close customer involvement proposed by Winston [51], test-first development and continuous integration used by NASA’s 1961–1963 Project Mercury described by Larman and Basili [35], and rapid prototyping defined by Naumann and Jenkins [45].

In the second half of the 1990s, research and practical results in the fields of OOP, design patterns, automated testing, refactoring, and the like, produced a common mind-set that drove the definition of multiple software development methods that had the core agile principles in common [13, 28]. These methods include Extreme Programming (XP), Scrum, Dynamic Systems Development Method, Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming, and others.

In early 2001, a group of independent practitioners with a strong link with the software industry and a weaker, but still relevant, link with research groups from academia, decided to join forces and founded what was later called the agile movement. To make these ideas more concrete, 17 software experts met from February 11th to 13th in the mountains of Utah, USA, to collectively craft the agile manifesto¹. The goal of the manifesto was to bring attention to the idea that to produce high-quality, valuable software, development teams must focus on values and principles such as (1) individuals and interactions, (2) working software, (3) customer collaboration, and (4) responding to change. Those points were presented as more important than emphasizing processes and tools, comprehensive documentation, contract negotiation, and following previously-defined plans.

Agile methods are, thus, concrete approaches to materialize the manifesto’s values and principles towards agility. Agility can be interpreted as the capability of “rapidly or inherently creating change, proactively or reactively embracing change, and learning from change while contributing to perceived customer value (economy, quality, and simplicity), through its collective components and relationships with its environment” [15].

A year before the manifesto, some of the ideas from the agile movement were already making their way into the Brazilian software development community. Initiatives in São Paulo, Rio de Janeiro, and Curitiba appeared around 2001 and grew to a conference in 2002 (Extreme Programming Brasil’2002). A couple of years later, academic courses, conferences, as well as industry adoptions, were starting to create a community of agile practitioners. Nowadays, that community has expanded enough to make agile methods a widely accepted software engineering alternative in Brazil, with a strong industry market in training and a growing demand from both the private and public sectors.

After more than 10 years of the agile manifesto formalization, the agile methods relevance and community in Brazil continue to grow. In a preliminary study [18], we presented an overview of the evolution of the Agile Movement in Brazil, described existing educational initiatives, and reported the agile state-of-the-practice in the Brazilian IT industry. In the current paper, we extend and refine that work. Our study aims now to provide a better understanding of the agile software development evolution in the country, particularly in education, research, and the industry. This research focuses on the following research questions:

• RQ1: How agile methods education has evolved in Brazil?

• RQ2: How agile methods research has evolved in Brazil?

• RQ3: How agile methods practice has evolved in the Brazilian IT industry?

The rest of this paper is organized as follows. Section 2 describes the first agile methods advocates in academia and industry. Section 3 describes an experience reported about a pioneering education initiative on agile methods and also gives an overview of other courses conducted since 2001. Section 4 presents the impact of the agile movement in research, and Sect. 5 presents a recent comprehensive study of the agile methods impact in the Brazilian IT industry. Section 6 discusses the main findings and implications for research and practice, as well as limitations of the current work. The last section concludes the paper and describes future work.

2 The genesis

Agile methods and the agile movement itself became known worldwide in 1999, the year in which Kent Beck’s XP book [4] was published and released during the ACM OOPSLA conference in Denver, Colorado. In 2000, the 1st International Conference on eXtreme Programming and Agile Processes in Software Engineering (XP’2000) took place in Sardinia, Italy. At this time, a few Brazilian software developers and researchers from academia and industry got in touch with the movement. Some of these people attended XP’2000 and met key figures from the movement, such as Kent Beck, Alistair Cockburn, Martin Fowler, Ron Jeffries, and Robert Martin. Others were at ACM OOPSLA in 1999 and 2000, attended Beck’s talks and got involved with the big frisson that XP and agile methods made during those conferences.

In early 2001, Brazilian professors and practitioners started to give talks about extreme programming in universities, government IT departments and in companies related to the software industry. In that year, the first full-semester university courses on extreme programming started to be offered. In this courses, students would develop real software projects using all the XP practices rigorously. Evaluations made with the students showed that these were among the most popular elective courses in the curriculum. Dozens of these students went out to work in the software industry shortly after the courses and often started to disseminate agile methods in their new organizations. Some of the advanced students with more leadership skills started to act, after their graduation, as consultants and project leaders and helped to introduce agile methods into even more software development companies.

In the few years after 2001, the members of this initially small agile methods community (including academics such as Vinícius Teles, Fabio Kon, and Alfredo Goldman and practitioners such as Klaus Wuestefeld) gave tens of lectures and short courses on extreme programming and agile methods throughout Brazil to both the academic and industrial audiences. Events in 2002 and 2003 in São Paulo, Rio de Janeiro, Recife, Florianópolis, Sao Carlos, and Brasília were fundamental in disseminating the practical use of these methods in real software development projects in Brazil.

By that time, the private sector organized Extreme Programming Brasil’2002, the first agile event in Brazil, which featured Kent Beck’s first and only visit to the country. It was held in São Paulo during 3 days at the beginning of December and had Scott Ambler and Rob Mee along with Kent Beck as international guests giving lectures to around 200 participants. Brazilian professors presented their experience teaching XP in the universities and practitioners described their first experiences with the new methods in the national software industry.

Two years later, Extreme Programming Brasil’2004 was attended by 300 people and brought Mary and Tom Poppendieck with the support of several companies. In the subsequent years, events at the University of São Paulo brought world class speakers from the field such as Frederick Brooks, Linda Rising, Richard Gabriel, Jutta Eckstein, Joe Yoer, and Brian Foote. Agile methods were starting to gain strength both in the academia and in the industry.

In 2010, graduate students and industry professionals organized the first edition of Agile Brazil at PUCRS, in Porto Alegre. Since then, each year, the conference has been attracting over 800 attendees from all over the country. Agile Brazil has become the most important Brazilian conference on agile software development. It brings not only a series of talks and workshops for the industry, but also an academic workshop, an executive summit, and a marathon with training courses to disseminate knowledge on agile methods.

3 Agile methods education

There were several educational initiatives on promoting agile methods in Brazil within the Academia and Industry. To answer our RQ1: How agile methods education has evolved in Brazil? we first describe an experience reported from the course “XP Laboratory”, the oldest course about agile software development running in the country. Our report includes details about the context, techniques, and the course development throughout the years. We illustrate some specific results by referring to published papers regarding the projects. After that, we describe some other Brazilian educational initiatives based on our research group knowledge. Despite our description not being complete, we aim to contribute by adding anecdotal evidence from some of the first education courses given in Brazil.

XP Laboratory at IME-USP. The oldest and still running course on agile software development in Brazil is probably the course XP Laboratory at IME-USP, which became a space for developing several real projects. It occurs once a year for Computer Science undergraduate and graduate students, during a full semester. The first edition was in 2001, when three professors taught a dozen students. Since then, the course has evolved and scaled up to over fifty students in eight concurrent projects and teams.

To support such growth, beyond the teacher’s role, there are some very experienced students that assume teaching assistant roles and work as meta-coaches during the courses. Meta-coaches are supposed to serve as experts for all groups providing feedback, supervising the practices and helping with the adoption of new practices. Also, former students or experienced students are encouraged to assume a coaching role in the following editions, and the other enrolled students work as developers.

To set up a closer to real environment, IME-USP course customers are chosen from several university requests or open source projects². All the systems developed are available as free software. The course starts with three weeks of theoretical classes, when the basics of agile methods and XP are introduced; then, the students can choose the projects they are willing to work on. Usually, each project gets from four to eight participants. If there is no experienced student in the group, a coach is elected among the volunteers. The groups without an experienced coach receive more attention from the meta-coaches.

The IME-USP course requires 8 h per week of dedication by students. The initial practices adopted at the start of the projects are the 12 from the first edition of the XP book; in addition, daily stand-up meetings and informative workspaces are also used. All teams have to carry out retrospectives at the end of each iteration. Once a week, there is a meeting involving coaches, meta-coaches and the teacher for project reviews, sharing of issues or solutions, and requesting support. The teacher and meta-coaches monitor teams’ agile practices, evaluate their informative workspaces and progress, and also collect students’ feedback on the course to adapt it according to the students’ learning needs. To grade the students, an average of grades for attendance, pro-active participation, tracking, customer satisfaction, along with personal, coach, and meta-coach evaluation is calculated.

In order to accommodate the entire class, physical and technological infrastructure is provided. Thus, the current learning environment is composed of two laboratories as working areas for the teams, material for making the informative workspaces³ [4], planning poker decks for estimations [79], two rooms for planning, technical and customer approval meetings, and retrospectives [20]. This way, the XP Laboratory course at IME/USP replicates a system similar to the industry and is of great value to students, as a student stated: “the course gave me much opportunity to learn how to manage a team and negotiate projects with a client”.

In a recent endeavor to improve the course continuously, once a week there is a 1-h class during lunchtime with lunch afforded by the course for scrutinizing XP topics through mini-lectures. The topics are previously chosen by the students. and through other practices applied to gather feedback on the course, and enhance interaction among the members of the course. The applied practices were Coding Dojo [56], whole-class retrospectives, and other meaningful dynamics commonly used in agile methods conferences, known as Lightning talks⁴, Birds of a feather sessions⁵, Starfish diagrams⁶, Brainwriting⁷, and workshops.

Considering the success of the first editions of the IME-USP XP laboratory, a presentation on its concept was given in the Brazilian Quality Symposium in 2002, a forum where good teaching ideas and techniques are spread among different Universities, during the annual congress of the Brazilian Computer Society (SBC). Later on, using the course as a test bed, several scientific publications were produced, addressing multiple topics, from working software such as Archimedes [17], Mezuro [37, 71] and Mico [66] to experiments on teaching XP [28] or XP related techniques [7]. Three recent studies on tracking [47], continuous improvement [54], and organizational learning [55] have also used the XP lab environment.

Other academic courses. On the second semester of 2011, a semi presencial (on site) setting was tried on an XP laboratory course given on a different Brazilian state. In this special edition, the course was given to 15 PhD students in the period of 2 months. After the initial lectures on XP practices, the professor visited the students two times during the development process and one last time at the end of the project. To overcome distance problems, some approaches were taken: an environment was set up to allow a distributed tracking of the projects, each student was responsible for reading, and possibly sharing, some agile methods related material, and all the discussions were done (or commented on in the mailing lists). The feedback provided by the students was very positive, as a student reported: “The general set up of the course was very good: a theoretical introduction on XP, auxiliary reading requests about related topics, and lots of practice (...) I learned a lot in these 2 months, but still, I learned more about my personal and team experiences”. Also another student outlined: “The discipline is very practical, which is very stimulating. I enjoyed dealing with customers and systems that would be actually used”.

A similar initiative on teaching XP was carried out at the Federal University of Rio de Janeiro (UFRJ) starting in the second semester of 2002. The approach used in Rio was different. There were two parts for each lecture: first a theoretical one in which the students had to answer questions orally based on the material provided earlier. For the practical part, instead of having a project for each team during the whole course, several short exercises on each practice were proposed. The motivation was to reinforce the learning of each practice, always practicing pair programming. Each day, the pairs were randomly chosen. The grades were mainly given based on the attendance and on the answers.

It is interesting to observe that another prominent center on agile research, Federal University of Recife (UFPE), used a different approach. Instead of having an initial focus on education, they started from the beginning with research. In 2003, two Masters thesis related to agile methods and one term undergraduate paper were presented. Since then, there has been an increasing number of graduate and undergraduate works, including those from other universities in that state, such as the Federal Rural University of Recife (UFRPE).

In addition to the initiatives described, we also identified several other initiatives on teaching agile methods that were developed in the last 3 years within many universities in Brazil. At PUCRS, for example, in the south of the country, there is a three-course program on agile methods that is offered every year by the School of Computer Science. The courses involve an introductory course, agile project management with Scrum and agile business analysis. More recently, PUCRS has engaged in another initiative, which involves the creation of an agile laboratory financed by CNPq (the Brazilian funding agency) to develop high performance software development teams, based on agile methods.

On the industrial side, a few companies provide training on agile methods. For example, Caelum is a Brazilian company whose business includes both training and software development. Caelum has several short courses on Java and object-oriented development. The company started to offer courses on XP and Scrum in 2007. However, the XP course was shortly discontinued since the industrial demand at that time was not enough. Later on, in early 2010, the Scrum course was reformulated to address agile methods in general, focusing mainly on the management practices. By the end of the same year, a new course was created to cover more technical practices such as unit and acceptance tests, test-driven development, and refactoring.

In 2006, as agile methods started to gain wide acceptance, some professors and students at IME-USP decided to offer a summer course to promote those ideas beyond the limits of the university. It was a 20-h theoretical course spread along 5 days with two instructors each day. The result was a success and all teaching material was published at the Agilcoop website⁸ to be used freely under a Creative Commons license. In the following 3 years, the team of instructors continued to offer the course, adding topics such as an XP Laboratory to offer a more practical approach and a testing course to study that subject more deeply. During this time, over 200 people attended the theoretical course, over 60 attended the practical course and around 50 were in the testing course. Most of this 300 participants were from the industry and helped to disseminate agile practices in their companies.

Scrum [62] was also a very important player in the agile methods growth. Although it has its origins earlier than XP, it became widely known only around 2006 when the Scrum Alliance⁹ (a nonprofit organization) became a corporate entity and started a certification process to gather professionals that met their criteria. The alliance offers several certification stamps that can be given only by certified trainers. Initially, all certifications given in Brazil were offered by foreign trainers in English. Since August 2008, though, the first Brazilian Certified Scrum Trainers were recognized by the Scrum Alliance and courses started to be taught in Portuguese. The certification filled an important gap for the industry as it presented a way to prove the knowledge of companies on agile methods. Since then other Brazilians obtained the CST certificate and the demand for certified scrum courses never stopped growing. Recently, a discussion regarding the certification led to the creation of another foundation (Scrum.org¹⁰) separating Ken Schwaber (Scrum.org) and Jeff Sutherland (Scrum Alliance), and provoking a rupture in the Scrum community. This new association also offers a certification program under a different label (Professional Scrum Certifications).

More recently, Project Management Institute (PMI) also launched an agile certification, called PMI-ACP (Agile Certified Practitioner)¹¹. The PMI-ACP recognizes knowledge of agile principles, practices and tools and techniques across agile methodologies. As stated by PMI, “individuals with experience working on agile project teams can apply”. The pilot of PMI-ACP occurred from Sept 15th 2011 to Nov 30th 2011, with more than 500 tests. So far, 29 Brazilians have passed and now earn the PMI-ACP certification. The fact that certification systems are a success in industry is undeniable and many people got in touch with agile through these certification programs.

Another initiative to foster the adoption of agile methods was done in several editions of the Encontro Ágil workshop¹². In the first editions, the main focus was on tutorials and panels to teach or provide working evidence on agile methods and related techniques. To provide interesting information for a broad audience, the workshops were divided in three main categories, Keynote talks are usually with an invited speaker, there is an advanced track, and an introductory track. However, in the last edition in 2010 there was a major change. Instead of providing talks, a larger emphasis on open spaces and lightning talks was given while only workshops with more interactive possibilities were allowed as long sessions.

Finally, in 2003, a tutorial on agile methods and XP was presented at SBES. This was the predecessor of a new tutorial held at CBSOFT-SBES on 2011 about agile methods. The new tutorial’s main motivation was to present evidence on the effectiveness of agile methods after 10 years of their use in Brazil and to show the current challenges.

Worldwide, there are several studies pointing out the adjustments in curricula on software engineering education to conform to this new paradigm [9, 30, 38, 44, 49, 76]. These studies propose ways to accomplish this, but most of them consider it a challenging endeavor, since it requires theory and hands-on experience, real projects, time for the development work, a place for building the agile environment, and the presence of several roles (like customer, coach, developer, and mentor).

4 Agile methods research

To the best of our knowledge, the first review of Brazilian academic papers on agile software development was published in the Brazilian Workshop on Agile Methods (WBMA’2011) [27]. Here, we extend those results adding research papers published until December 8, 2011. As in the original paper, we aim to answer RQ2: How agile methods research has evolved in Brazil?

4.1 Review process

To focus the design of the review process, we divided the RQ2 into three sub-questions:

• SQ1. How many thesis and dissertations related to agile software development are in progress and have been concluded in Brazil?

• SQ2. How is the collaboration and cooperation among researchers in Brazil?

• SQ3. How many bibliographical, technical productions related to agile software development were elaborated in Brazil?

Our review process encompasses four stages:

• Stage 1. Identify researchers. The first part of the review process consisted in identifying Brazilian researchers working in fields related to agile methods. The search strategy included a list of contacts of researchers and manual searches on national conferences proceedings such as WBMA [60], ESELAW [58], WDRA [61] and SBES [59], and international conferences such as Agile [22] and XP [65]. For each identified researcher, we sent a personal email communication for validating the data. We also asked them to invite their research contacts related to agile methods to help validate the data. Using scriptLattes [42], an open-source knowledge extraction system for the Lattes platform, we conducted a literature search in the Lattes Curriculum¹³ on December 8th, 2011 to extract scientific productions and ongoing/concluded thesis supervisions. We chose to use the Lattes Curriculum because most national publications have not been indexed in other electronic databases, as in the ISI Web of Science.

• Stage 2. Identify relevant work. Papers were included in the review if their focus was agile software development or if they were focused on single related techniques or practices, e.g., pair programming, test-driven development, or refactoring. The inclusion of papers was not restricted to any specific type of intervention or outcome measure. This review included qualitative and quantitative Brazilian research papers. To identify the papers to be included, we did a snowballing (recursive) search of the papers published by each researcher we found in the previous step [31]. For each identified researcher, we searched for the following types of productions.

  • 1. Papers in scientific journals;

  • 2. Complete papers published in conference proceedings;

  • 3. Extended abstracts published in conference proceedings;

  • 4. Abstracts published in conference proceedings;

  • 5. Journal papers accepted for publication (in press).

  We excluded books published or organized, book chapters published, articles in newspapers or magazines, and other kinds of bibliographic production from our search. This search strategy resulted in a total of 2328 unique papers between 1997 and 2011. To describe how many PhD theses and MSc dissertations were related to agile software development, we used the scriptLattes tool [42] to extract ongoing/concluded supervisions. This search strategy resulted in a total of 550 supervisions.

• Stage 3. Exclude studies on the basis of titles. We analyzed the titles of all studies, including thesis and dissertations, from stage 2, to determine their relevance to the review. At this stage, we excluded studies that were clearly not related to agile software development. For instance, as our search strategy included all the publications from the Lattes Curriculum, we got several “hits” on unrelated topics, e.g., Distributed Systems. Papers with titles that indicated clearly that the work was outside of the scope of this review were excluded. However, titles are not always clear indicators of what a paper is about. In such cases, the papers were included for review in the next stage. At this stage, 2080 studies were excluded.

• Stage 4. Exclude studies on the basis of abstracts and keywords. Studies were excluded if their abstract and/or keywords were not related to agile development, which left 128 publications. Among them, 112 were papers in conference proceedings (87 %) and 16 were journal papers (13 %). Theses and dissertations were also excluded using the same criteria, resulting on 26 MSc and PhD works on topics related to agile methods.

Figure 1 summarizes the review process, including the number of researchers and papers identified at each stage.

Fig. 1

Stages of the selection process

4.2 Results

We describe below results from our literature search, focusing on answering RQ2 and all sub-questions posed in Sect. 4.1.

4.2.1 Number of thesis and dissertations related to agile software development

We identified 37 researchers on agile software development. From 1997 to 2011, they advised 26 MSc and PhD students on related topics. As we can see in Table 1, there seems to be a substantial increase in the interest of graduate students in the topic of agile methods.

Table 1 How many theses and dissertations are in progress and have been concluded?

With respect to the agile methods subtopics that have been studied by the graduate students, we see that most of the studies identified were on agility in general (12 of 26). Studies on XP come next, with seven works. Most studies were short, 6 months at most, completed in small teams, with up to seven team members and conducted in a university setting. Four themes were recurrent across the studies: (1) how agile development methods are introduced and adopted in companies, (2) comparison of agile development against an alternative, (3) human and social factors related to agile development, and (4) investigation of specific agile practices.

4.2.2 Collaboration and cooperation among researchers

An examination of the state of origin of the publications shows that most studies are from São Paulo and Pernambuco. The University of São Paulo has the highest number of publications, followed by the Federal University of Pernambuco. Figure 2 presents the institutions that are more frequently occurring in the search and their co-authorship. The productions with equal or similar titles, within the same type and year of publication, are considered to be collaborations/cooperation among researchers.

Fig. 2

How is the collaboration/cooperation among researchers?

Another interesting finding from our literature search is the most cited papers on agile development. In Table 2 we list the top four most cited papers according to Google Scholar on December 8th, 2011.

Table 2 The four most cited Brazilian papers on agile software development

4.2.3 Brazilian Research on Agile Software Development

We found 48 Brazilian scientific publications on agile software development published in national venues, such as SBES, WBMA, WDRA, and ESELAW. Figure 3 illustrates the trend in publications between 2003 and 2011.

Fig. 3

Publications on Agile Software Development in the WBMA, ESELAW, WDRA and SBES

The number of Brazilian authors and the number of Brazilian publications in the international scientific literature have grown substantially during the last 4 years. Figure 4 illustrates the trend in international publications between 2003 and 2011. Prior to 2003, no publication was found. Table 3 gives an overview of the studies according to publication venue¹⁴. We see that the International Conference on Agile Software Development (XP), Conferência Latinoamericana de Informática (CLEI) and ESELAW have the largest number of papers.

Fig. 4

Brazilian publications in international journals and conferences

Table 3 Distribution of Brazilian publications per publication venue and occurrence

To categorize and analyze Brazilian studies, we adopted a similar classification scheme as Dybȧ and Dingsøyr [24]. The papers fell into three main groups:

• Introduction and adoption: several studies addressed how agile development methods are introduced and adopted in companies. Most studies discussed how the development process was changed and treated agile development as something “new”;

• Use of tools and practices: several studies have investigated specific tools and practices in isolation, like pair programming, or test-driven development. Most studies reported that agile development practices are easy to adopt and provided good results;

• Perceptions of agile methods: several studies have investigated how agile methods are perceived by different groups. Some addressed how satisfied customers are with agile methods and some focused on the collaboration between a customer and the development team.

Experiences from the usage of agile software development can be identified mostly in commercial settings. Using these findings as a basis, we identified serious limitations, e.g., it is difficult to introduce agile methods into projects with heterogeneous groups [67].

This review also shows that many promising studies on the use of agile methods have been reported suggesting that it is possible to achieve improved job satisfaction, productivity, and increased customer satisfaction [5, 40, 52].

We also can notice an increasing adoption of empirical-based methods in Brazilian research in collaboration with industry, such as surveys [2], grounded theory [53], and multiple-case studies [40].

The main finding from this review is that there seems to be a substantial interest in agile software development amongst research environments. From the presentation of the most cited papers, we are able to observe that most highly cited papers are published in conferences. Furthermore, we found that the number of Brazilian authors and the number of Brazilian publications in the international scientific literature have grown substantially during the last 4 years. These results are very similar to an international analysis of literature on agile software development done by Dingsøyr et al. [21]. For instance, the four most cited Brazilian papers presented 22, 16, 16, and 12 citations, respectively. In the list of 20 most cited papers on agile software development worldwide, Dingsøyr et al. [21] found papers whose number of citations varied between 61 and 14.

5 Agile Methods in Industry

Despite the fact that agile methods have been increasingly adopted and have rapidly joined the mainstream of development approaches [77], their adoption in the Brazilian IT industry has not been studied much in the technical literature. We aim to investigate the inception, growth, and establishment of agile methods in this community through RQ3: How agile methods practice has evolved in the Brazilian ITindustry?

For this purpose, we conducted a research divided into two phases, adopting a sequential mixed method approach [19]. First, we performed a survey in Brazil to gather quantitative data regarding the agile state-of-the-practice. After that, we designed a qualitative study aiming not only to verify whether our survey findings were valid or not, but also to interpret better the statistical relationships.

5.1 Research design

5.1.1 Phase 1 - Quantitative study

Our main goal was to take an initial step towards understanding the agile methods state-of-the-practice in the Brazilian IT industry. To better focus our data collection and analysis, we divided RQ3 into six sub-questions:

• SQ1. What are the characteristics of agile practitioners?

• SQ2. What are the characteristics of agile companies?

• SQ3. What were the companies context when they adopted agile?

• SQ4. How agile methods are being adopted?

• SQ5. What are the perceptions after agile adoption?

• SQ6. What are the main challenges when adopting agile?

To answer these sub-questions, we developed a Web-based survey¹⁵ consisting of 19 questions, most of which were based on a previous global survey on agile methods conducted by VersionOne [73]. Table 4 presents all 18 variables, scale types and their relationship with the research sub-questions. Each variable is related to one survey question (Appendix A), except the last question regarding the respondent contact. The survey uses a Likert scale structure, that requires choices between values in the scale.

Table 4 Research sub-questions, survey variables, and scale type

Data collection When conducting research based on surveys, probabilistic sampling of participants allows making inferences about population characteristics based on sample data. However, achieving a random sample of Internet users is problematic, if not impossible [63]. Thus, we used non-probabilistic sampling techniques, recommended for exploratory research [69]. We combined non-probabilistic sampling techniques, such as convenience and snowball methods to draw out our survey participants. For instance, convenience methods recruit respondents from online communities and discussion forums. Snowball sampling is based on the practice of asking participants to refer someone else to the survey, and so on.

We piloted the survey with five agile practitioners for checking its consistency and face validity [63]. Then we drew out possible survey participants from several databases, such as mailing lists, attendees of past agile conferences, and AgilCoop¹⁶ business contacts. We sent them an email invitation to participate in the survey, and also invited their business contacts. We collected data over a six-month survey period.

Data analysis The survey data analysis was performed by two researchers and revised by all co-authors. Since the sample is not probabilistic, we cannot statistically generalize the results. However, we can perform statistical analyses to explore data and generate propositions. Thus, we prepared the data to perform three statistical analysis: descriptive analysis of all variables, Chi-square measures of association between categorical variables and contingency tables, and Spearman’s Rank Order correlation between the ordinal variables. We adopted operational definitions provided by Cohen [14], one of the most widely known guidelines for interpreting the magnitude of correlation coefficients. Survey data supported interesting analysis such as the participants profile, the most adopted agile methods and practices, the main reasons and worries when adopting agile methods, who were the champions, the most important challenges and benefits, as well as barriers and causes of failed agile projects.

5.1.2 Phase 2 - Qualitative study

Information gathered in qualitative studies can assist in the analysis, clarification, validation, and interpretation of survey data in several ways [64]. The qualitative study protocol was, therefore, designed to further explore the survey most relevant findings. These encompass: (1) main reasons for agile methods adoption by company size, (2) most adopted agile practices by company experience, (3) perceived benefits from implementing agile methods, and (4) barriers or challenges for agile methods adoption by company size.

Data collection. We collected data from seven semi-structured interviews with open questions [36] in seven Brazilian companies. The selection criteria considered companies in Brazil with different sizes, business areas, locations, and agile methods experience as a way to enhance data triangulation. Tables 10 and 11 describe companies and interviewees profiles respectively. We preserved their identity by identifying companies and their interviewees with letters. The interviews lasted from 40 to 90 min and interesting expressions were transcribed.

The Phase 1 (quantitative study) results highlighted interesting aspects, such as the above mentioned four topics, to explore in the interviews. This helped us to develop the interview protocol, which also included a topic about the future of agile adoption in Brazil, as described in the Appendix. Thus, we performed qualitative data collection to deepen the understanding concerning main reasons, barriers or challenges for agile methods adoption, most adopted agile practices, and perceived benefits from implementing agile methods.

Data analysis We carried out the qualitative data analysis through the identification of interesting expressions for each interview transcribed by the interviewer. After that, following [26], we applied pluralism in qualitative research by crossing the individual findings from each interviewer with the other interviewers to identify meanings that could be grouped into thematic concepts. Our first aim in the data analysis process was to confirm or refute our survey findings. Then, we tried to recognize patterns to search for particular aspects that could provide tendencies or valuable explanations for the statistical relationships.

Qualitative rigor criteria. We followed the Guba and Lincoln’s trustworthiness criteria for validity [29] trustworthiness criteria for validity criteria. We tried to provide a detailed description and relevant quotations to enhance transferability. To strengthen credibility, we checked and rechecked the collected data and the co-authors discussed the findings among themselves. By presenting our judgments about potential for bias or distortion, we improved dependability. Lastly, we collected data from multiple sources of evidence to increase confirmability.

5.2 Phase 1: results from the quantitative study

We describe below our quantitative main findings based on the survey data.

5.2.1 Survey sample

We began the survey data collection in May, 2011 and finished in October, 2011. In this period, we had 471 complete responses. To check our sample representativeness, with respect to geographical distribution, we compared it to the number of Brazilian IT professionals [68]. Softex has investigated the Brazilian IT industry, triangulating a large body of information and data from different government agencies¹⁷. Based on this mapping, Softex has proposed the PROFSS (formal software and IT professionals) concept. PROFSS can be IT managers; network, systems, and database administrators; computer systems designers and analysts; and related occupations such as computer assistants and operators. We used the most recent PROFSS statistics to compare it to our sample, as shown in Table 5. Our sample covers better the Southeast and Midwest regions. However, we consider the sample representative of the other Brazilian regions, since its distribution was not far from the PROFSS distribution.

Table 5 Distribution of Brazilian IT companies by region and respondents region distribution

5.2.2 Participants profile

To characterize the survey participants, we collected data about their experience with agile methods, current position, and exposure to agile development. Figure 5 summarizes the participants profile. The participants experience in practicing agile development methods is mostly between three and 5 years (29.5 %), and then between 1 and 2 years (28.5 %). The results show that more than 50 % of the practitioners have already moved to agile methods, having at least 1-year of experience.

Fig. 5

Participants personal profile

The participants current position (Fig. 5) varied widely from developer to product manager roles, ensuring diversity in our survey. Developers and senior developers account for 35.1 % of participants. Team leaders and Project managers account for 23.6 %. This result points out that more than half of respondents play a developer or a manager role. In the option “Other”, which represents 11.5 % of our respondents, there are roles such as systems analyst, business analyst, requirements analyst, researcher, and trainer.

Finally, Fig. 5 depicts the participants current level of exposure to agile development. Most participants are currently members, leaders, or coaches of an agile team.

5.2.3 Participants companies profile

We characterized the participants companies profile by describing the company IT team size, their experience with agile methods, location, and business area. Figures 6 and 7 illustrate our results.

Fig. 6

Participant’s companies profile—IT size and experience with Agile methods

Fig. 7

Participants companies profile—location and business area

Most participants companies (Fig. 6) are small or very small organizations, having an average IT department size smaller than 20 people. However, 23.6 % of the companies employ 21–100 people and 22.7 % employ more than 100 people in the IT area. Company experience in practicing agile development methods is mostly between one and 2 years (31.4 %), and then between three and 5 years (24.8 %). The results point out that more than half of the companies are experimenting or effectively using agile, having at least 1-year of experience in this endeavor.

Figure 7 frames the organization main activity. Most of them are related to the Internet, Government or to Office/Business. In the option “Other”, many of them are associated with software factories, information technology (IT) in general, and research and development (R&D) segments. Figure 7 also presents the organizations location. São Paulo, Rio de Janeiro, Distrito Federal and Minas Gerais host most of the companies.

5.2.4 Agile methods adoption

Our survey describes the companies context when adopting agile methods, focusing on who was the champion, the main reasons they find relevant for adopting agile development methods, and what worries companies have at that time. Figure 8 summarizes the main findings.

Fig. 8

Champions, worries, and reasons for adopting Agile

Our results point out that the most frequent champions of agile methods in the companies were Developers, Team leaders, and Project managers, accounting for 63.7 % of our respondents. The initiative seems to come mostly from the development teams, not from top management, corroborating our impression that, in Brazil, the vast majority of IT managers and CTOs are not up-to-date with advances in software development.

Figure 8 illustrates the main reasons that led companies to adopt agile methods. Our results show that the most important reason was Increase productivity (91 %), followed by Managing changing priorities (86 %), and Enhance software quality (83 %). There were other expectations, such as Simplify development process and Accelerate time to market. The reasons, therefore, are aligned with the agile mentors claims [4, 62]. Surprisingly, 53 % of respondents do not consider Reduce cost as an imperative reason to adopt agile.

When adopting agile methods, companies were also worried about the change, as shown in Fig. 8. The most frequent worries were Lack of documentation, predictability, upfront planning, and management control. Some respondents (12.5 %) reported no worries regarding agile adoption in their companies.

5.2.5 Agile methods practices

After the first analysis on participants and company profiles, and their context when adopting agile, we investigated to what extent companies embrace agile methods. Figure 9 shows the percentage of companies’ projects adopting agile methods, and if companies are using agile with distributed teams. Many respondents (30.4 %) indicated that all of the company projects adopt agile. This is probably due to the large amount of small companies in the sample, where it is easier to deploy new development methods. There are also young companies that were born in the agile way. However, summing up answers, we found that more than half of the respondents (51 %) are using agile methods in less than 50 % of their projects. This result shows that Brazilian companies are still migrating to agile methods, or possibly using it in certain types of projects.

Fig. 9

Agile usage in companies

We also explored the geographical distribution of agile teams. Despite that the majority of teams are not distributed (68.8 %), a significant portion of the respondents (31.2 %) are experienced in distributed environments. This result points out that distributed software development teams can be agile. However, in this research phase, we did not explore the agile strengths and weakness in distributed teams.

In addition, we investigated the most adopted agile methods and practices by the companies. Scrum was considered the most followed agile method, accounting for 51.2 % of participants (Fig. 10). It was succeeded by the combination of Scrum and XP, accounting for 22.5 %. Hybrid methods, such as Custom hybrid and Scrumban, account for 12.1 % of participants. A small group (4.2 %) is employing Lean development [48], an adaptation of lean principles for the world of software development. In the option “Other”, most respondents stated Test-Driven Development (TDD), FDD/Scrum Hybrid, and the use of XP/Scrum with PMBOK.

To evaluate agile practices, we borrowed a list of practices from surveys carried out by VersionOne [72, 73] due to their large impact running worldwide agile surveys. Figure 10 shows that Iteration planning, Retrospectives, Unit testing, Daily standup, and Refactoring are the five most adopted practices, according to our respondents. These practices represent management, continuous improvement, quality, and architectural valued aspects in teams. However, it is not clear whether those practices are more adopted than others or if there is any relationship between practices and other variables, such as company size or experience. This motivated us to explore in detail possible explanations, as shown in Sects. 5.2.8 and 5.3.2. In the ‘Other’ option, respondents stated practices such as Storymaps¹⁸, Niko-niko¹⁹, QA checklists, and “productivity sensation” board.

Fig. 10

Most adopted Agile methods and practices

5.2.6 Perceived benefits from adopting Agile methods

With agile adoption, organizations may benefit in many ways, Fig. 11 discloses the perceived benefits. The heat map illustrates trends about companies’ perceptions. Our result shows that Productivity (69.21 %), Ability to manage changing priorities (67.94 %), Team morale (66.87 %), Simplified development process (60.93 %), and Quality (60.29 %) have improved or significantly improved after the adoption of agile methods. The bottom-ranked benefit was the ability to Manage distributed teams (24.84 %). However, most respondents do not experience distributed development, which diminishes this result relevance.

Fig. 11

Perceived benefits from implementing Agile practices

Regarding the effective project speed obtained from implementing agile methods, as shown in Fig. 12, most respondents (67.1 %) indicated that agile projects provide faster time to completion. For 13.2 % of respondents, agile projects have the same time to completion. A smaller group (0.8 %) found agile projects slower to complete. Finally, the other respondents (18.9 %) have not yet finished an agile project to answer this question. The overall result points out that agile leads to better project speed.

Fig. 12

Project speed after implementing Agile practices

5.2.7 Main challenges of agile methods adoption

The last questions of our survey aimed to explore causes of failed agile projects and significant barriers to further adoption in the companies. Figure 13 summarizes our main findings.

Fig. 13

Causes of failed Agile projects and barriers for further adoption

An expressive group of respondents (36.3 %) stated that their agile projects did not fail. However, the other 63.7 % of respondents indicated some causes for agile projects failure. Lack of experience with agile methods was the most frequent answer, accounting for 16.3 % of respondents. Company philosophy/culture at odds with agile core values and External pressure to follow traditional waterfall practices were also important reasons leading to failure. In the “Other” option, respondents indicated lack of Product Owner and customer training, poor expectation management, lack of scope control, and trouble to manage external dependencies, specially with non-agile teams impinge on the projects, leading to failure.

At the present time, a wider agile adoption is harmed by barriers presented in Fig. 13. The three most frequent barriers cramping further agile adoption were the Ability to change organizational culture (50.7 %), Availability of personnel with necessary skills (43.3 %), and General resistance to change (41.4 %). In the option “Other”, the main concerns were about adaptation to institutionalized processes in the organization (e.g., PMBOK, Mps.Br),lack of discipline and belief in agile methods, interpersonal issues, and employee turnover.

The overall result points out that ability to change culture and learning are, definitively, major players in the companies complete transition to agile methods.

5.2.8 Relationships between companies experience, size, and Agile adoption factors and perceptions

We also analyzed associations and correlations between all survey variables. In the following, we describe the most important relationships we found.

Relationship between company experience and agile practices adoption. The Chi-Square value ($\chi ^2$) for the association between agile practices adopted and company experience varied for each practice, as shown in Table 6. The relationship between most practices and company experience was higher than 40 with five degrees of freedom (df) and a significance probability ($p$) less than 0.001—i.e., a very significant result at conventional levels. On the evidence of this data, there is an association between the practices adoption degree and the company experience.

Table 6 Contingency table showing Agile practices adoption percentage by company experience

Therefore, we can interpret that more experienced companies tend to adopt more agile practices. However, this tendency changes as the function of each practice. We highlighted in boldface, in Table 6, the experience range in which each practice was most adopted. Each percentage represents the relative frequency of practice adoption in the range. We can observe that, on the one hand, there are practices most frequently adopted when companies have more than 5 years of agile experience. On the other hand, there are practices most frequently adopted when companies are between three and 5 years using agile, such as Iteration Planning, Retrospectives, Daily standup, Unit testing, Burndown, Release planning, Kanban, Automated builds, Velocity, On-site-customer, and Continuous deployment. In some cases, the difference was not significant if we compare both frequencies between the ranges. For instance, Continuous integration is adopted by 74.5 % of companies between three and 5 years of experience, and adopted by 75 % of companies with more than 5 years of experience. However, there are significant differences in some cases. Why did some companies abandoned some agile practices after 5 years of experience? This result has puzzled us and led us to design the third phase of our research to better interpret the statistical relationships (see Sect. 5.3.2).

The relationship between Agile adoption factors and Company Experience and size. A Chi-Square test was executed to determine the association between project speed, worries when adopting agile, barriers to further adoption, causes of failed agile projects, and company size and experience with agile methods. Table 7 presents the test results.

Table 7 Chi-square association between Agile adoption and company experience and size

The relationship between agile project speed and company experience was 118.16 (df = 15, $p<$ 0.001), a high association. This evidence points out that companies with more experience in agile methods tend to report faster project speeds. We also found an association between worries around Regulatory compliance and company size ($\chi ^2 =$32.86, df = 5, $p<$ 0.001), indicating that larger companies exhibit an inclination to worry more about regulations when adopting agile. Finally, we found an association between the management skills barrier and company experience ($\chi ^2 =$22.93, df = 5, $p<$ 0.001). The trend is that more experienced agile companies perceive management skills as an important issue to fully spread agile practices throughout the organization.

The relationship between reasons for Agile adoption, perceived benefits, and company experience and size. A Spearman’s Rank Order correlation was executed to determine the relationship between reasons for agile methods adoption, the perceived benefits, and company size and experience, as shown in Tables 8 and 9. There was a very weak correlation between some reasons that led to agile adoption and the company size or experience with agile. For instance, there is a very weak and negative relationship between company size and maintainability (r = $-$0.017, $p<$ 0.001). The overall result denotes that the reasons for agile adoption (such as increasing productivity, or improving team morale, etc.) are not associated with the company size nor the company experience with agile methods.

Table 8 Spearman’s correlation between reasons for Agile adoption, company size, and experience

Table 9 Spearman’s correlation between Perceived Benefits adopting Agile, Company Size, and Experience

However, there was a moderate, positive correlation between some perceived benefits, as visibility, quality, cost, change management, time-to-market, risk management, and alignment between business and IT, and company experience, which was statistically significant (see Table 9). This evidence points out that such perceived benefits tended to be higher for more experienced agile companies. The more experienced an agile company is, the more likely they will perceive the aforementioned benefits. Our results also point out a strong correlation among the most perceived benefits, as shown in Table 9. Hence, the perceived benefits tend to be achieved together in the companies, regardless of the company size or experience with agile methods.

5.3 Phase 2: results from the qualitative study

In this research phase, we aimed at confirming, extending or refuting the results gathered from the quantitative study. We highlight that, as a qualitative study, the results presented in this section are based on the interviewees’ perceptions towards the statistical relationships found about the agile methods state-of-the-practice in the Brazilian IT industry. To characterize the companies in this second study, we collected data about company size, business area, location, company’s experience with agile methods, as well as interviewees’ characteristics, as experience and roles. Tables 10 and 11 describe companies’ and interviewees’ profiles.

Table 10 Companies profile

Table 11 Interviewees profile

5.3.1 Agile methods adoption

The main reason for the agile adoption was to cover the basics on software development, such as delivering value often and avoiding rework by investing in technical quality. Then, the companies began to realize that agile methods could also help with strategic alignment, productivity, and social aspects such as communication, corporate climate and environment, technical leveling, and motivation. Table 12 lists the companies intention when adopting agile methods.

Table 12 Main reasons for the agile methods adoption

These findings are in line with our survey results regarding reasons for agile adoption as presented in Fig. 8 (Sect. 5.2.4). Our qualitative results confirm that the reasons for agile adoption are not related to the company size or experience with agile methods, but for the essential need to improve the software development approach.

Another interesting aspect most interviewees reported was the successful bottom-up initiatives in the beginning of the adoption of agile methods. Most companies presented bottom-up initiatives on agile methods adoption that were raised by professionals acting as agile champions. For instance, an interviewee stated “In 2006, there was a pilot case using XP in a problematic system. This was one of the most successful projects at that time, we had working software with tests passing and the team got a good delivery pace”.

After perceiving the good results from preliminary initiatives, they reported that top management engaged mostly on Scrum, as an interviewee said “Top management said ’this pilot worked out very well (...) so let’s try to bring agile methods to the company as a whole’. Then they [top management] demanded agile methods from top-down, with everyone adopting Scrum officially in 2007”.

Especially for large companies, this top-down approach to agility has affected the actual transition to agile, which should be rooted on establishing the core agile values and principles. This can be noticed in the statement, “Not everyone understood exactly what it was, thus, after a while, many people were doing it just because they were told to do it”.

Today, a great concern of agile companies is employing the agile philosophy to actually take advantage of the agile practices. After this exploration, we found out that it is still a challenge to companies thriving when getting mature on agile and it is discussed in the corresponding following section.

5.3.2 Agile methods practices

As seen in Fig. 10 (Sect. 5.2.5), our survey results point out a broad adoption of Scrum and of the Scrum/XP hybrid. Conversely, interviewees reported an easy adaptation of XP, Scrum, and Lean software development. Interviewees reported they employed practices such as Kanban, Unit Testing, Test-Driven Development (TDD), Open Work Area, and Whole Team (cross-functional and/or multi-functional teams). However, given their level of maturity on agile methods and size, we observed different kinds of commitments to other agile practices. Companies with 5 years of experience or more usually employ practices such as refactoring, continuous integration, continuous deployment, and automated builds.

A common approach reported by companies is to adapt agile practices from different agile methods according to their context, especially after a level of maturity on agile adoption. The adapted practices by the interviewed companies are presented in Table 13, which encompass technical, management, and collective knowledge sharing categories of practices. In the technical category of practices, we identified adaptations on adoption of Pair Programming, tools usage for metrics, and automated acceptance tests. Likewise, practices for improving knowledge sharing were also promoted in the companies, such as mentoring, lectures/technical lunches, Dojos, and team member rotation. These companies employ these knowledge sharing practices due to seeking for improving their long-term business strategy and their professionals’ technical excellence.

Table 13 Adapted agile practices

Comparing with the survey results, management practices (Fig. 10), such as iteration planning, retrospectives, and daily standup meetings, were mostly adopted by companies considered mature on agile methods. As in the survey we might not know if they are adopted “by the book” or adapted, the adaptation shall be an important aspect to be considered. For instance, Company A stated that they do not employ daily standup meetings anymore, due to the proximity of team members. Daily meetings were not aggregating value to them, so they employ it in a weekly basis and replaced it by using Kanban boards and a task management tool. When it is needed, they schedule a meeting.

As a way to search for improvements in agile adoption, we identified attempts to apply Lean software development practices. In company B, they reported the use of user story maps instead of Sprint backlogs for better understanding the system as a whole and cumulative flow diagram to analyze the kanban flow. In company G, the goal for 2012 was to leverage agile methods to the organizational level, having Lean software development as the main guidance.

On the other hand, the on-site customer practice was raised by the interviewees as shortly adopted, and it occurs mostly for internal customers. External customers presence and involvement is not fully provided, product owners (PO) end up bridging the customer needs to the team and vice-versa.

Another neglected practice by experienced companies is the use of estimation techniques, such as planning poker. Actually, they often simply establish a high level task estimation (e.g., small, medium, large), in which large, or even medium, implies that they should consider breaking the story into smaller ones.

Behavior driven development (BDD) is another practice not fully implemented by the teams. First, because Product Owners find it hard to write the scripts. Second, they were not perceiving the value back to the project, because, depending on the story, the script remained broken for a long time, as an interviewee explained, “It is a script that you write in the beginning, but it keeps broken for a long time. Until you do the model, the controller and the view, the script is broken there for days, weeks”.

5.3.3 Perceived benefits from adopting agile methods

Even though the visibility of the benefits is different from team to team within companies, the overall perception is that agile methods have brought several advantages to software development in these companies. In first place, customers became more satisfied with the frequent deliveries of value, as interviewee B stated: “We are delivering what the customer needs and reducing the feedback loop”. This benefit is in line with the sense of time-to-market and productivity pointed out in the survey results. Another benefit is the customer collaboration along the software process as a shared responsibility. Regarding this aspect, company C outlined the bad experience of customer collaboration on government, “In the end, the collaboration was of no use and all apparently flexible scope with which we were dealing with. What was valid for government was only what was determined in the contract”.

As companies become more experienced in agile methods, the benefits of software quality, project visibility, and team morale were confirmed by the interviewees as being increasingly perceived since its implementation. The quest for continuous improvement has increased technical excellence of team members. As a consequence, software quality has enhanced in their perception, as interviewee A outlined, “The issue of quality: now we have a defined cycle and the feeling of more collective ownership and more internal code quality”. Also, job satisfaction and visibility are other aspects raised by the interviewees when getting mature in agile methods. For instance, interviewee B stated, “People are happier, people understand what they are doing, the corporate climate is coolest”. In Company G, the perception of benefit is similar. The project is owned by the team. Some people became more motivated with agile methods. People are more creative and deliver what makes the difference for the client. These qualitative evidences reflect on the strong correlation found between the most perceived benefits and company experience raised in the statistical analysis (Table 9).

In Company F, everyone thinks they are on the right track now by using agile methods. The company has 7,000 employees, and the high level management says that the next step is to influence all the company with the culture and benefits of agile methods.

Interviewee C reported an important concern related to company growth: they learned different benefits during the time of implementation, “The benefits were better perceived when we were smaller”. After their growth, scaling agile to the company became a challenge, “Now we are in a moment of reflection”.

5.3.4 Challenges of agile methods adoption

Our qualitative results confirm the survey results on challenges for further agile adoption presented in Fig. 13 (Sect. 5.2.7). Interviewees revealed limitations for a full agile adoption in their contexts. Because of the human-centered approach of agile methods, the social aspects are considered the most complicated factor for a wider adoption, especially in growing and dynamic environments. These findings are aligned to what we found in the statistical analysis (Sect. 5.2.8), experienced companies are realizing that social and management skills really matter to fully spread agile throughout the organization. Also, interviewees reported the difficulty in employing long-term cultural change, and they are questioning themselves whether it is worth investing. Some report that it is due to low employees’ maturity and the poor recruitment process. Others state that it is due to company’s growth and the difficulty of scaling agility.

For instance, company C is facing problems with employees’ commitment, responsibility, and freedom. Now they are reflecting on their way of dealing with people, “We did not verify consistently the positive results of long-term freedom and a network structure. We realized that people are not willing to take a charge proportional to their activities (...) I’m reviewing a lot of things in this sense and I am directing the energy of convincing people to establish control mechanisms within the company. It is a kind of reverse way, because we went to one extreme and now it is in the opposite direction”.

They also report improvements on communication after employing agile methods, however they understand there is a long way to efficient communication; as interviewee B declared, “I would say that communication is always the complicated issue. We invested in creating a safe environment where people could talk. However, there are always people that do not follow, so I think the hardest part is people and communication between them”.

In the statistical analysis of Sect. 5.2.8, the following question was presented: “Why did companies abandon some agile practices after five years of experience?”. In the qualitative exploration, an interesting finding was highlighted by some of the experienced companies. They state technical barriers, like technological issues within projects, affecting a wider adoption of agile practices like continuous deployment, automated builds and continuous integration. Thus, experienced companies sometimes leave practices due to project’s context variables, not because practices are useless. Conversely, companies with three or less years of experience find it hard to get discipline in adopting practices such as refactoring. An interviewee stated, “Continuous Integration, 10 minute build, automated builds are not practiced today. We know we should do so. Refactoring is done occasionally. It should be more frequent”.

In the future, companies focused on products or services innovation like A, B, and C expect to invest more in Lean Startup [50] initiatives. Lean Startup means a set of practices for helping entrepreneurs increase their odds of building a successful startup, which is a human institution designed to create a new product or service under conditions of extreme uncertainty. The referred companies assume that to establish an agile reasoning for business innovation, as interviewee B describes “One thing I’m considering very cool is that with the rise of this wave of Lean Startup, people are not only concerned in making a product that works, but to make a product that people want to use it. It’s of no use having a perfect software that nobody wants to use. I think it adds another dimension to agile methodologies, which means knowing the customer and not being afraid of changing the business direction. This is something that should mature in the next decade”.

However, after employing several tests and hypothesis validations for the customer development process, interviewee A criticized the Lean Startup thinking of focusing on creating an overall solution to users, “Lean Startup tries to think more globally. Our insight is that the website is not good for everybody, it’s good for one person. So we do not want to find out the best page for all my customers, but the best page for a customer. The system must adapt itself dynamically to show what enhances the product use for my customer (...) by taking metrics at runtime and providing customized solutions”.

Company C, which develops products mainly for government, praises Lean Startup as the new wave of developing innovative products with agile and lean concepts, but interviewee C states that “Government and startups do not quite match”, so they are making their tests in parallel within a new business area.

Another fundamental future challenge the companies expect is to engage the core agile values and principles in different contexts and implement enterprise agility to take real advantage from agile methods. This is illustrated by a quote from Company G, by saying that “The use of agile methods is different among all teams. For this reason, 2012 is the year of agile culture. We will work based on lean principles and try to implement enterprise agility across the organization”. Continuous delivery was also mentioned during the interviews as a fundamental challenge for the future.

This qualitative exploration was conducted to improve the validation, interpretation, and clarification of the survey’s most relevant findings. This was achieved by the depth and richness of the data provided by the interviewed companies reinforced with their statements and war stories.

6 Discussion

The results presented in this paper show important characteristics of how agile methods are being applied by companies, IT professionals, and universities in Brazil. In this section, we discuss our major findings based on the three perspectives presented in the paper: education, research, and industry.

Education. There is a growing number of initiatives on agile education in Brazil. Several universities and companies are offering innovative training and classes for both students and IT professionals. The need for education on agile software development is corroborated by the empirical results (both the survey and the interviews), and the lack of training is perceived by the companies as one of the main barriers for agile adoption. Training initiatives are also very important for students. In a recent systematic review on agile software development, Dybȧ and Dingsøyr [25] presented experiences on the student perceptions of agile education. In one of the studies reported, the students found that working in agile teams helped them to develop professional skills such as communication, commitment, cooperation, and adaptability. The students also believed that XP improves the productivity of small teams [39]. In addition, as reported by Goldman et al. [28], teachers seem to have the same perception: “each of us have had enough development experience to believe strongly that we produced more higher quality production code in this environment than the old cubicle style of developing software”. Most of the initiatives on agile education are based on individual efforts from several research groups nationwide, and companies interested in applying agile methods. For this reason, we believe that there is an opportunity for discussing how to include agile methods in the Computer Science curricula in Brazil. Based on our results, this means providing courses closer to marketplace context, so students can experience all the fundamental issues of agile software development.

Research. Regarding the scientific research, the results showed that agile methods research is growing in Brazil. More papers are being published, both in national and international conferences, also there are several universities and research groups conducting research in different topics.

The topics being investigated by Brazilian research groups are partially aligned to what Dybȧ and Dingsøyr [25] found in their systematic review. They classified the studies in four thematic groups: introduction and adoption, human and social factors, perceptions of agile methods, and comparative studies. The Brazilian research community has concentrated the research in three groups: introduction and adoption, the use of tools and practices, and perceptions of agile methods.

Agile software development teams are complex adaptive socio-technical systems [78], relying on multifaceted team members equipped with a broader range of technical, social and leadership skills [46]. Our findings confirm previous results that the technical side of agile methods helps the teams becoming more productive, increasing the quality of the final product. However, we found that dealing with social factors for building agile teams is still challenging. For example: how people can be effectively prepared to work in agile teams? Agile methods emphasize the importance of developers’ greater autonomy, teamwork and decision-making [46]. However, forming such teams takes time and resources [43], and requires significantly more social skills [3, 70] and experience [6]. Thus, our findings indicate that there is an avenue for further research on the necessary skills and training for agile teams.

Another very important question is how do we adapt agile methods for different contexts? Recent research has shed light on models and methods for agile methods tailoring. Kruchten [33] explores the topic by presenting a contextual model for software-intensive systems development to guide the adoption and adaptation of agile software development practices. This models could be investigated and evaluated for different contexts. Conboy and Fitzgerald [16] interviewed 16 expert XP practitioners to investigate the effectiveness of XP tailoring methods and provide a set of recommendations for Software Practitioners and researchers regarding tailoring XP. Our findings indicate that Brazilian companies are also adapting agile methods such as XP, Scrum and Lean within their contexts as they become more mature. They are also using new agile practices for different domains, such as Lean Startup. For this reason, research involving companies from different sizes, business domains and agile experience should be undertaken to help understanding and providing evidence on which methods or practices are more suitable for each different context.

There is also an opportunity to extend the systematic literature review conducted by Dybå and Dingsøyr [25] in order to include up to date evidence of the research that is being developed about agile methods worldwide. As an example, most of the empirical studies found by Dybå and Dingsøyr [25] are related to XP (76 %), while our survey indicates that most of the companies from our sample are using Scrum as the main agile method (51.2 % use Scrum and 22.5 % use Scrum/XP hybrid). This result is also corroborated by the results reported in the annual state of agile survey [73]. The survey data includes information from 4,770 participants from 91 countries. Scrum is also the most followed agile method (58 %), followed by Scrum/XP Hybrid (17 %). For this reason, there is a difference in what academics are researching and what many companies are doing in terms of agile methods and this could be investigated in the future. Lean Software Development was also mentioned in our interviews as an agile method used by companies, and the investigation of how this method is applied is an opportunity for future research.

Industry. Agile methods are being widely adopted by companies worldwide [73]. The main reasons for this adoption are: to accelerate time to market, to enhance the ability to manage changing priorities and to increase productivity. In Brazil, our results are very similar (Fig. 8). When we triangulate the survey results and the interviews conducted, the change in organizational culture appears as an important element to facilitate agile adoption within companies. In a review of definitions on organizational culture presented by Cameron and Ettington [11], in a majority of cases, it has been treated as an enduring set of values, beliefs, and assumptions that characterize organizations and their members. As Cameron and Quinn [12] state, changing organizational culture is a challenge, because it requires the identification and a long-term strategy for changing underlying attributes, including the management style, strategic plans, climate, reward system, means of bonding, leadership, and basic values of the organization.

In most of the interviews conducted, the alignment between the companies G values, mission, with the principles of the agile manifesto was the key aspect to facilitate the organizational cultural change. But the question is: how many companies are ready for this change [75]? Changing organizational culture is a long-term strategy and certain companies are not willing or even prepared to cope with this deep change. For this reason, some companies might not see this strategy as profitable and give up on engaging core agile values and principles to the whole company as they previously believed in the beginning of the agile implementation. Some companies have invested a lot in the recruiting process and internal training to achieve a good staff. Therefore, the understanding of the human factors and organizational change are main challenges to strengthen and sustain agile methods in industry.

The exploratory study raised the point that companies usually start the agile adoption within a single project, and then extend it to the organizational level. In the survey results, the initial champions of agile methods are developers and team leaders. However, most of the companies worldwide have senior leaders (VP / Director of development and development manager) as the champions of agile methods [73]. While in Brazil we have a bottom-up strategy, it seems that there is a top-down strategy worldwide. This is an opportunity to be investigated in the future.

When we compare the results between Brazilian and worldwide surveys [73, 74], we found very similar results about the benefits raised from implementing agile methods, the agile methods most closely followed, and four of the top five practices most adopted. But different practices are used based on company size and maturity on agile methods. Companies with more than 5 years of experience use practices such as refactoring, which is not the case for companies with less than 3 years of experience. A linear adoption of technical agile practices focused on enhancing software quality, such as TDD, refactoring, continuous integration and others, have been applied rigorously in companies more experienced in agile methods. However, management practices are the subset of agile practices undergoing major adjustments and even being abandoned, like the estimation techniques. This may indicate an important field to start research from, as a means for building a body of knowledge on tailoring agile practices.

6.1 Limitations

Regarding the literature review developed about research on agile software development in Brazil, we did not follow all the steps recommended to conduct systematic literature reviews, because of the strategy adopted to identify relevant literature. For future work, we plan to conduct a systematic review on agile methods, extending the review reported by Dybȧ and Dingsøyr [25], and comparing it to what we have found about the research on agile methods in Brazil.

In this study, our main goal was to present a big picture of the agile movement in Brazil, analyzed from different angles. The results we found are valid in the context of our sample and can not be generalized at this time. We believe that our results can be used in the future for comparison with other countries.

We also have limitations related to the bias of the researchers. Our main action to reduce the limitation of the results was to triangulate all the data, analyzing quantitative and qualitative data in a mixed method approach. We have also implemented peer review among all researchers involved in this study.

Finally, although our survey results date from December/2011, it still sheds light on under-researched questions pertaining to the agile state-of-the-practice in Brazil. As answering to this kind of survey demands significant time from respondents, we plan to conduct the survey every 2 years and report the results to the agile community as we have done in this pioneer initiative [41].

7 Conclusion

In the early years of agile methods in Brazil, in the early 2000s, talks on the subject were received with great skepticism both by researchers in academia and managers in industry. Better acceptance was found with experienced developers, who often got enthusiastic about the new vision and perspective on software production. Many times, a few members of the audience in a lecture about XP would become aggressive against the ideas presented by the lecturer. Nowadays, this scenario has changed completely. Most companies involved in software development claim that they follow at least some of the recommendations of the Agile Manifesto. Young developers are now educated with some contact with agile practices such as automated tests and continuous integration. Some even say that agile methods became mainstream [32].

Nevertheless, the culture and tradition of plan-based development and documentation-based evaluation of progress is still very strong in Brazilian universities and companies. Thus, there is still a long way to go before agile methods become, in fact, predominant in Brazil. Educators can help in that direction by modernizing university curricula and researchers can help by conducting experiments and evaluations of the quality and productivity of software developed with agile methods. However, as Thomas Kuhn states in The Structure of Scientific Revolutions [34], it might be necessary that a whole generation of managers and leaders retire before the new paradigm of agile development become, in fact, widely used and mainstream.

Appendices

Appendix A

1.1 Survey protocol

• Which role below best describes your current position in your company?

• How long have you personally been practicing agile development methods?

• What situation below best describes your current level of exposure to agile development?

• How large is your total software organization?

• What is the main activity of your organization?

• Where is your company located?

• What were the reasons for adopting agile within your team or organization?

• How long has your company been practicing agile development methods?

• Which agile method do you follow most closely?

• What percent (%) of your company’s software projects use an agile method?

• What is/was the champion of agile adoption in your company?

• Do you work in a company with distributed development teams?

• What is the most followed agile method in your company?

• What value have you actually realized from implementing Agile practices?

• What is your perception regarding adoption of agile in your company/team?

• What are the barriers to further adoption of agile in your current organization?

• What are the agile practices adopted in your company?

• What were the main reasons for failed agile projects (if any)?

Appendix B

1.1 Interview guide—Brazilian companies personal and company profile

• What is your current role in the agile team?

• How long is you experience with agile methods?

• What is your company IT size?

• What is your company business area?

• Tell us briefly about your company context (structure, strategy, culture, etc).

• What is the size of your agile team?

• How long was the agile team composed?

• Tell us about your experience in software development.

• What were your recent projects in software engineering?

• Tell us about your first contact with agile methods.

1.2 Reasons for the agile methods adoption

• What were the reasons your company decided to adopt agile methods?

• In your opinion, what is the company level of support on the agile methods adoption?

• How did the top management and the team members start to adopt or agree on the agile methods adoption?

1.3 Adopted agile practices

• Which agile method(s) does your team implement?

• Which agile practices does your team adopt?

• Is there any agile practice that you needed to adapt? If yes, which and how did you adapt?

• Is there any agile practice that you adopted and gave up adopting so far? If yes, what are the reasons?

• Is there any agile practice that causes different opinions about the adoption in the company?

• Is the any agile practice that the team intends to adopt in the future?

1.4 Realized benefits from implementing agile methods

• Can you tell us about a problem which no longer exists after adopting agile methods?

• What is your perception of the main benefits brought by the agile method(s) adopted?

• Over the time of adoption, how have you perceived these benefits?

• In you opinion, is the benefits visibility the same in the teams level and in the organizational level?

1.5 Barriers, challenges and future of agile methods adoption

• Can you tell us an episode where an agile practice hindered more than helped in the project?

• In your opinion, what has been more challenging in the agile project that you are participating in?

• Do you realize limitations for a deeper adoption of agile methods in your team and/or in your company? What?

• Which perspectives for the adoption and evolution of agile methods can you point out to companies in the next 10 years?