Since Agile Methods formalization, software engineering education has also been impacted. Universities had to adapt their courses as a way to suit these new software processes. At the University of São Paulo (USP), in Brazil, a course called XP Laboratory was created in 2001. Although the name refers to eXtreme Programming, the discipline aims at teaching agile methods in practice, considering several elements that are crucial for providing the student with real knowledge and experience with agile methods. We have adopted practices inside and across teams, such as rotation of team members to solve project problems, mini-lectures or lightning talks at lunch, and whole-class retrospectives in fishbowl format, among others. We present our experiences of more than 18 years on teaching agile methods and how we have evolved and improved the course based on student feedback.
1. INTRODUCTION
Teaching agile methods in academic environments is challenging and complex, because it needs to consider a mixture of theory and practice. We need to provide students relevant knowledge and experience with agile values, principles, and practices. At the University of São Paulo, in the Computer Science Department there is a discipline called XP Laboratory for undergraduate and graduate students. The discipline is an opportunity to learn agile software development methods on real projects. The discipline provides an agile environment similar to that found in industry as well as a proper infrastructure for developing agile projects. The presence of diverse roles in addition to instructors, including mentors (experts in agile methods or former students who have already been through an edition of the course that, along with the instructor, provide agile mentoring to all teams), and coaches (experienced students on software development or students that already know agile methods), is important. Students as developers interact with actual customers and spend time devoted to development work for real projects. Additionally intra-team, inter-team and whole class learning techniques ensure a broad and continuous learning experience for students.
Professor Alfredo has a more theoretical background. After a masters of science and PhD in Parallel Computing his interests were not so close to Software Engineering. However, as a programmer, after his first contact with Agile Methods, everything made sense. After working and publishing the first papers on agile methods, he used to say, I do not work on software engineering, but on agile methods. In contrast, Professor Viviane has a more practical background, working for several software development companies before getting her masters and doctorate in Software Development Processes. She was one of Alfredo’s doctorate students from 2010 to 2013 and also worked in the discipline as a mentor in three editions. Her doctoral research inquired about the use of knowledge management and organizational learning techniques for agile teams’ continuous improvement. For her, XP Lab became an environment to evaluate these aspects on real projects. We have come a long ways in the past 18 years at XP Laboratory; but first, let’s take you back to the beginning.
2. THE INCEPTION
Professors Alfredo Goldman and Fabio Kon and two other colleagues started the course in 2001, in the year in which the Agile Manifesto was declared. The catalyst for it was the previous year’s OOPSLA conference Fabio attended. A keynote by Kent Beck at the Symposium on Education for Change addressed some reasons for failure of teams. One of the causes was lack of team goals. We felt that at our university, something had to be done about this problem. So we created a course based on teamwork and the original XP practices. Eighteen years later, we are still conducting XP Laboratory. But we have come a long way in our approach. About five years ago the discipline was renamed to Agile Methods Laboratory. Today’s course is composed of an instructor, mentors, lecturers, researchers (when possible), meta-coaches, coaches and developers (Figure 1) that conduct real projects with real customers.
Meta-coaches are coaches of coaches (former students or professionals who come from industry), i.e. they are teaching assistants who are experts in agile methods. Along with the instructor they provide agile mentoring to the coaches of all teams. Students experienced in software development or students that already know agile methods assume the role of coach while others work as developers. We explicitly differentiate the meta-coaches from the coaches as their commitment is to the success of the overall course and not any specific project. We also have the sporadic participation of mentors (agile methods experts) in a practice called “Clarify your doubts with an expert”. See Figure 2 where Joe Yoder is serving as a mentor. For several years he has participated in the discipline.
Figure 1. An XP Laboratory team.
Figure 2. Joe Yoder, a mentor of the XP Laboratory.
The course requires 8 hours per week of dedication by students. We provide lunches to incent them to save this time for the project and to be fully engaged in its activities. These 8 hours have to be spent programming by groups of 2 or more students. In some exceptional cases we allow remote pair programming or code review.
In the early days of XP Laboratory we were more inclined to provide a safe environment to teach only agile methods for students. However, after trying hard to provide the perfect conditions for students and not being successful, we became aware that the students just needed an environment and the support to work on real projects applying agile methods. If we provided that environment, they would learn how to face the challenges of actual work in the marketplace. So, our initial thought of focusing only on agile methods, changed to a broader scenario where the students also learn other abilities or techniques, such as, adapting to change, considering all the concerns involving web software development (i.e., technologies, programming languages, frameworks, and others, making apps, using microservices, etc.). This learning experience is also part of a work in a real environment. Now we focus more on providing the necessary conditions, physical and technological infrastructure, and a learning environment for the students to get in touch with agile methods in a context similar to professional context. This means three laboratories as working areas, material for making the collaborative workspaces and estimating with planning poker, two rooms for planning, technical and customer approval meetings and team retrospectives. From 2005 to 2015, the course got financial resources for offering lunch every Friday, after that the course has relied on the clients to pay for some lunches. So, now during a semester there are about 2 to 4 lunches. Many students engaged their research by undertaking relevant XP studies and work in this course.
In the first classes, the instructor presents the course objectives, structure, schedule, evaluation criteria and available projects. Each student elects the three most desired projects to compose the teams. In addition, the coaches are chosen, usually we pick up volunteers who feel comfortable enough to auto-declare themselves as coaches. However, usually the teams starts doing coach role rotation after the first few releases. Then, in the next classes, XP is explained to the students. Separately, meta-coaches teach coaches how to lead agile projects. Then, students are presented to their respective work environments, projects, customers, and coaches.
XP practices within teams, such as standup meetings, planning meetings, customer meetings, team retrospectives, tracking tasks and collaborative workspaces are carried out to identify teams’ context, challenges, issues, and adherence to agile values and principles. Since 2015 as the number of potential clients increased and due to the importance of having the best possible match between teams and clients, we expend more time on client presentations. Each client has five minutes to do his elevator pitch, and then students have time to ask questions. In the last edition, in 2018, we had 23 clients, so this took two whole classes.
We had 500 students enrolled in this course, being 349 undergraduate students and 151 graduate students, according to Table 1. A student is allowed to follow the course up to three times, once as an undergraduate student and twice as a graduate student. Each experience is unique: different team, new client, distinct conditions. Also, there were 36 professionals/scholars (some of them former students) that have participated as meta-coaches, mentors, lecturers or researchers. The number of projects and teams composed in each edition is presented in Table 1, some supported by industry. There was no XP Laboratory in 2005.
The projects are diverse. Some are brand new, others involve legacy code. So, the development challenges are different on each team. In 2018, we had an exciting novelty, a project dedicated to the Linux Kernel. It worked fine. Now we have a group of students dedicated to it (flusp.ime.usp.br). Other projects were on games creation, a food delivery app, a project to help persons with disabilities, and a web page to show how our representatives vote (radarparlamentar.polignu.org). Previous years we also had great diversity, from CAD for architecture (www.gnu.org/software/archimedes/) to collecting source code metrics (github.com/mezuro).
Table 1. Number of students and projects per edition
In the timeline below (Figure 3), we present major events that happened in the XP Laboratory. The mentioned events are updated, when repeated, and are cumulative, occurring until now. In 2006, we started to provide a wiki repository in Portuguese (ccsl.ime.usp.br/wiki/LabXP) to register all related data about the discipline and projects, including teams’ composition, activities agenda (lunch, mini-lectures, coding dojos, test day, refactoring day, etc.), lessons learned, best practices, evaluation criteria, grades, and others.
Figure 3. XP Laboratory timeline.
Figure 4 presents the number of empirical studies conducted in the XP Lab, as well as the number of resulting publications. The studies involve exploring metrics to support agile tracking [1], learning of agile practices using Coding Dojos [2], the relationship between Open Source and Agile Methods [3], a retrospective of the agile movement in Brazil [4] [5], recommendations for building an informative workspace [6] [7], practices for continuous improvement of the XP Lab [8], agile usability patterns [9] [10], inter-team knowledge sharing [11], the interdisciplinary use of agile practices [12], technical debt awareness [13], and software development practices patterns [14].
Figure 4. Empirical studies and publications of the discipline editions.
Some former students work on Agile Methods all over the world, for example DS working at ThoughtWorks since 2008, HC at DigitalOcean since 2016, AF who worked at IndustrialLogic for 6+ years, MB and MVS who work at Amazon, DB who organizes AgileTrends, CC works at Xero, RO at Genios, among many others.
3. THE TURNING POINT
In 2006, the course started to offer students lunch every Friday as a way to freely socialize their experiences and also to stimulate them to arrive in time for the development work. As a consequence, in 2010 the agile practices were not being sufficient to stimulate and support agile methods learning, a broader improvement of the course was a subject in several debates.
As an example, at the Friday lunchtime, for several times, we have witnessed students exchanging valuable experiences, such as solving project problems or even adapting an agile practice to their project characteristics. During the weekly coaches’ meetings, the meta-coaches generally advise coaches on how to deal with problems perceived in their projects. Also, the other coaches provide their solutions for similar problems or suggest solutions based on their own knowledge or experiences. In the end, students were facing problems that were being solved collaboratively, but the course was lacking a systematic approach to raise the level of learning.
Then, we started wondering how we could disseminate their experiences in a systematic way to all students. So, we began to apply agile methods in the discipline itself as a way to fulfill these needs.
For this reason, we started to use the lunchtime on Fridays as a one-hour class to improve inter-team learning and interaction. The practices applied are detailed below. Consequently, in this class, students started to share and learn about technical knowledge, projects, agile methods, and skills.
Whole-class retrospectives were carried out with Starfish diagrams three weeks before the retrospective with all students and then we employed Fishbowl discussions. The students had previous time to think about the course and how to improve it. They paste notes in the quadrants to offer early feedback and provide an anonymous preliminary view of the course. These feedbacks were used in the final retrospective as we categorized and discussed all of them, as well as specified actions for improvement. After getting a preview of the themes to be considered in the retrospective, we applied Fishbowl discussions with the entire class to gather feedback from the students about the course.
Mini-lectures and Lightning talks are short presentations with the purpose of leveling knowledge about software development at the class. After the initial overview of XP, lunchtime at Fridays was accompanied by mini-lectures. The themes are mostly about agile planning, agile estimation, story writing, tracking, TDD, refactoring and continuous improvement. The students suggest and analyze the themes for further voting.
Rotation of team members across teams is used with members of other teams that are experienced in specific technologies who can help solving technical problems in a team that is struggling in their project.
Brainwriting across teams is used for solving project issues. With this dynamic we encouraged cross-team interactions by making circles of chairs, being one for each project, and separating five story cards, pens and adhesives of red and green dots for each circle. Before this, the lunchtime had been considered an opportunity for learning in a passive way. The details of the dynamic and its images are presented in [8]. Most teams used the results to improve their project.
Coding dojos are used for levelling technical knowledge when teams lack similar knowledge. We select challenges, define a list of participants and start training code programming and skills through a coding pair (driver and copilot) trying to solve the challenge within a timebox of 5 minutes, using TDD and BabySteps. While the tests are failing, the audience may not interact. After succeeding, the audience may help the coding pair in refactoring the code. At the end of the timebox, the driver goes back to the audience, the copilot becomes the driver and the next one of the list steps up to be copilot. Two meta-coaches of the course conduct the Coding Dojo as a way to optimize the one-hour class learning.
Regarding the dynamics, it is important to consider approaches to work efficiently in a one-hour class, since the time in this discipline is too scarce. Dynamics have to be focused and coherent to most of the audience. That is why we started to use more Starfish diagrams to stimulate participation and anticipate discussions.
Besides these, we also have added two other practices: Test Day and Refactoring Day. In the Test Day, for instance, we start with a mini-lecture explaining the importance of testing, how to test and its impact on the project, then we set the day for working only with tests on the project. The same happens for the Refactoring Day, which also adds technical debt concepts. With both activities set in the XP Lab agenda, the students understand the relevance of them and start to create a culture of testing and refactoring for their careers. It is interesting to point out that even when the teams do not consider that they need to perform more tests or to refactor, when we force them, after it they do think it was useful (we still need to write a paper on this). We also added recently a stand-up meeting for coaches; it is a lighter activity that happens every week. It is a very effective way to support the coaches’ activities and to provide more confidence to them.
4. STUDENT TESTIMONIALS ABOUT THE COURSE
From February to May, 2019, we sent a questionnaire to the email groups of all XP Lab editions. The questions covered their profile (student, professional or scholar), their first contact with agile methods, their participation in the course, their opinion about the course, their perception of the learning and its practical application, and the impact of the course in their professional lives. The number of respondents was 26, the actual respondents’ profile is illustrated in the Figure 5, most of them are now professionals (16) and scholars (3). There were also two undergraduate and five master and PhD students.
Figure 5. The actual respondents’ profile and their first contact with agile methods.
Their participation in the course starts as a developer in the team (Figure 6), but 13 of them acted as coaches in subsequent years. Four of them served as meta-coaches. One of them later became a customer, another one became a researcher in the course and three of them were lecturers during the lunchtime.
Figure 6. Respondents’ participation in the course.
4.1 XP Laboratory Opinions
All respondents understand the importance of the discipline to their labour market training. They consider their experience an excellent opportunity to get more confidence to reach their career objectives, since they get in touch with all the elements of software development work in real projects inside the university. Most claim it should become a mandatory discipline. Below, are two relevant testimonials.
“I believe it was the most significant course I had on my bachelor degree. Learning those practices by doing them made a huge difference in my professional and personal lives, since I discovered it was possible and very fun to work as a software developer. The opportunity to take talks from professionals during the classes gave me insights of how we can make the most of what is out there. It could be a mandatory discipline, have more credits and be extended further: LabXP I, LabXP II, Scrum, Kanban, Working with legacy code, Working with legacy code II, Lean Startup, Holacracy, and so on.” (Developer in 2012)
“I consider the recurring offer of the course as a relevant and admirable activity, since the adoption of agile practices becomes essential for the development of more coherent and higher quality software systems. Despite the relevance of teaching the agile approach, unfortunately few Brazilian educational institutions have initiatives similar to the IME/USP. So I see this course as a quality and pioneer initiative in Brazil. In addition, it is worth mentioning that during the course students have the opportunity to live in a scenario similar to a real environment, having to deal with different challenges related to technology, development process, communication, among many others.” (Coach in 2018)
4.2 Perception of main course topics
Most students interviewed say that the course fulfills its purpose of training agile values, principles and practices. However, students that acted in more than one role, such as developers, coaches, meta-coaches, and/or lecturers, point out that its topics embrace wider activities that involve dealing with customers, teamwork and communication; deciding project technologies and tools; and reducing the distance between the university and professional environments. We have selected some testimonials depicting that perception.
“Pair programming, refactoring, automated testing, teamwork (not work in group), evolutionary design, short iteration planning, stories writing.” (Developer in 2003 and Coach in 2004)
“TDD, retrospectives, plannings, daily meetings, agile dynamics, kanban, lunch, open-source code, coding.” (Developer in 2011 and Coach in 2012)
“Agile Manifesto, XP methodology practices, agile practices of software project management, project refactoring, proactive/collaborative/self-Management Work, efficient and transparent communication process, software testing, emerging software development tools/technologies.” (Coach in 2018)
“Team development, a software project with real impact on society and companies, applying agile methodologies.” (Developer in 2018)
4.3 Perception of the learning and its practical application
It is the consensus that the course learning and its application in the labour market is effective.
“This was one of the disciplines most connected with the market reality. Currently the use of agile methods is even greater in companies, so its content is essential for training students of Computer Science.” (Developer in 2003, Coach in 2004 and Customer in 2011)
“(…) I use the knowledge acquired and replicate the discipline format in disciplines of Software Engineering II, Entrepreneurship and Software Quality, where students need to solve real problems, with real clients and following agile methods. In relation to the content itself, I use both for teaching and consulting, and for the organization of the tasks in the board, the approach with the client, the clear and respectful communication of the involved, the teamwork, the development through the agile mindset, the rapid testing of the solution and validation of small parts with the customer.” (Developer in 2012, Coach and Researcher in 2013)
“A great lesson I have learned in the discipline was design decisions. Both during discipline and in other academic and personal projects, I learned to think (and much) before writing code. Also, since the discipline is very focused on teams, I learned how to brainstorm collectively.” (Developer in 2018)
4.4 Impact of the course in the students’ professional lives
Given that not all respondents have professional experience, because some of them did not complete the computer science course, not all answered this question. However, for the respondents that are working in software, we got comments such as the ones presented below.
“It was decisive. It impacted the choice of my masters subject. Influenced my area of expertise in the market. Until now, more than 16 years after the discipline, I remain heavily involved with agile methods and have a company that offers services on agile methods.” (Developer in 2002, coach in 2003, meta-coach in 2005 and lecturer in 2011)
“These were important experiences that gave me confidence to get on well with my initial jobs.” (Developer in 2006 and Coach in 2007)
“XP was pivotal in my professional life. I came to the conclusion in my first two years of work that most of the difficulties of teams and organizations were not code, engineering, technology – but people, processes, and the whole context surrounding them. LabXP brought me these other elements very early in my career and allowed me to generate much more value as a professional in the teams and companies in which I worked, besides making me learn and expand my range of knowledge in a fantastic way. Not to mention the fantastic people I met through this community. Many, many thanks!” (Developer in 2009)“LabXP shows that the side that allows an absurd increase in productivity when developing software is the people side. The better, more fluid and more predictable are the processes agreed upon among participants, the more adaptable/agile the project is. If I were not a student of this lab, the willingness to understand more about how to minimize disagreements and increase code quality would not exist and consequently would not be where I am today, even though I have evaded the IME/USP.” (Developer in 2017)
5. WHAT WE LEARNED
In this section we briefly list advice on how to start a course like this:
- First of all, there is no closed formula that should be applied over and over again, we had to adapt to several different situations, and this was good;
- It is important to provide the environment and the support to the teams to work on real projects;
- Apply agile practices to improve the course itself;
- Associate the learning environment not only for teaching Agile Methods, but also for providing a space to do empirical software engineering experiments;
- After all these years, the most important value of Agile Methods, is Continuous Improvement, we always have to keep seeking ways to be better Tomorrow than Today.
Speaking for me, Viviane Santos, the XP Lab provided me a number of experiences and learning, but the most important one was to take a step back when we witness a problem and think based on agile values and principles. For instance, all the course improvements were primarily based on following carefully the agile principle of “Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done”. That is what we challenged to do in this course. In the beginning, it was not easy. I saw students and Goldman trying to control everything, but now we observe more and have a systemic view of what is happening to then decide what to do. It is a more organic and natural approach that has worked fine and the same can be applied to other environments where students learn and produce.
On my side, Alfredo Goldman, during all this journey, I can attest that the Agile Values made more and more sense. The Agile Mindset became somehow not only a way to teach but also my life philosophy. Another important aspect is related to the increasing importance of human factors, many times looking for the root cause analysis I found issues that were not technical at all. So, I am getting more interested on topics related to psychology and human interactions on software development.
6. FINAL REMARKS
There are many takeaways from this amazing learning experience about trying to share our passion for Agile Methods. Maybe the most important is about our relationship with Agile, we cannot just teach it, we have to be committed with them and truly believe on all the values behind it. This commitment did not appear right away, but it was part of an evolutionary process, with it we started to see the problems faced during the course not as obstacles, but as challenges to be solved, using the Agile values. Moreover, by showing how to deal with them somehow we were improving not only our adaptation skills, but also showing to the students that they could also do the same. One of the most gratifying experience preparing and writing this experience report was to be aware that we helped to spread the Agile mindset to many people who are also sharing their experiences.
7. ACKNOWLEDGMENTS
The inception of this paper was at Agile Brazil, when our Shepherd Rebecca Wirfs-Brock noticed the influence of our course on the agile community in Brazil. She convinced us that this was a history worth to be spread. Without her, we would not have written it! We also have to thank the professors involved in the first edition of the course, Fabio Kon, Carlos Ferreira and Paulo Silva and Silva. We also thank all meta-coaches that made this course possible: Hugo Corbucci, Mariana Bravo, Renan Mello, Claudia Melo, Daniel Cukier, Thiago Colucci, Graziela Tonin, Diego Camarinha, Rafael Manzo, Thiago Nunes, Ian Carvalho, Diogo Pina, Wilson Mizutani, Paulo Meirelles. A special thanks to Joseph Yoder, Danilo Sato, Maurício Aniche who shared their knowledge with our students. We also have to thank all the students and clients that helped us during all these years!
References
[1] Sato, Danilo T., Bassi, Dairton , Bravo, Mariana V., Goldman, Alfredo, Kon, Fabio “Experiences Tracking Agile Projects: an Empirical Study” J. Braz. Comp. Soc. 12(3): 45-64, 2006
[2] Bravo, Mariana V., Goldman, Alfredo “Reinforcing the Learning of Agile Practices Using Coding Dojos” XP 2010: 379-380, 2010
[3] Corbucci, Hugo, Goldman, Alfredo “Open Source and Agile Methods: Two Worlds Closer than It Seems” XP 2010: 383-384, 2010
[4] Corbucci, Hugo, Goldman, Alfredo, Katayama, Eduardo T., Kon, Fabio, Melo, Claudia de O., Santos, Viviane A. “Genesis and Evolution of the Agile Movement in Brazil – Perspective from Academia and Industry” SBES 2011: 98-107, 2011
[5] Melo, Claudia de O., Santos, Viviane A., Katayama, Eduardo T., Corbucci, Hugo, Prikladnicki, Rafael, Goldman, Alfredo, Kon, Fabio “The evolution of agile software development in Brazil – Education, research, and the state-of-the-practice”. J. Braz. Comp. Soc. 19(4): 523-552, 2013
[6] Oliveira, Renan M., Goldman, Alfredo “How to Build an Informative Workspace? An Experience Using Data Collection and Feedback” AGILE 2011: 143-146, 2011
[7] Oliveira, Renan M., Goldman, Alfredo, Melo, Claudia de O. “Designing and Managing Agile Informative Workspaces: Discovering and Exploring Patterns”. HICSS 2013: 4790-4799, 2013
[8] Santos, Viviane A., Goldman, Alfredo, Santos, Carlos D. “Uncovering Steady Advances for an Extreme Programming Course”. CLEI Electron. J. 15(1), 2012
[9] Bertholdo, Ana P. O., Silva, Tiago S., Melo, Claudia de O., Kon, Fabio, Silveira, Milene S. “Agile Usability Patterns for UCD Early Stages”. HCI (8) 2014: 33-44, 2014
[10] Bertholdo, Ana P. O., Kon, Fabio, Gerosa, Marco A. “Agile Usability Patterns for User-Centered Design Final Stages”. HCI (1) 2016: 433-444, 2016
[11] Santos, Viviane A., Goldman, Alfredo, Souza, Cleidson R. B. “Fostering effective inter-team knowledge sharing in agile software development”. Empirical Software Engineering 20(4): 1006-1051, 2015
[12] Gren, Lucas, Goldman, Alfredo “Trying to Increase the Mature Use of Agile Practices by Group Development Psychology Training – An Experiment”. QuASoQ/TDA@APSEC 2016: 50-57, 2016
[13] Tonin, Graziela S., Goldman, Alfredo, Seaman, Carolyn B., Pina, Diogo “Effects of Technical Debt Awareness: A Classroom Study” XP 2017: 84-100, 2017
[14] Kattan, Herez M., Goldman, Alfredo “Software Development Practices Patterns”. XP 2017: 298-303, 2017
