Paper Session: Service Learning
SIGCSE’18, February 21-24, 2018, Baltimore, MD, USA
Combining Agile Software Development and Service-learning: A Case Study in Experiential IS Education Spencer Robinson, Margeret Hall University of Nebraska Omaha School of Interdisciplinary Informatics Omaha, USA
[email protected];
[email protected] ABSTRACT
1 INTRODUCTION
Experiential learning is ever-more popular with educators, industry, and with students themselves. Finding and delivering appropriate applied use cases can be challenging though, as on one hand industry partners may not willing to give insights to non-employees into their systems for creating truly meaningful case studies, and on the other hand the appropriate balance between instruction and application is ill-defined. Service learning projects are one solution for filling in the applied project gap. This case study takes place in the nexus between blended classrooms, applied software development, and service learning. Junior and senior level students partnered with a community actor to develop deployable software applying the Agile methodology. The service-learning project enabled students to engage in a full-cycle development project, from requirements gathering to hypercare. However, significant trade-offs in structure and classroom management must be made when the focus of the class is a full implementation. Blended technologies and course delivery were found to aid delivery and project management in a seamless manner. Drawing on feedback from stakeholders and students, this experience report makes a series of recommendations for implementing applied software development. Our contribution is the introduction and assessment of a method to marry (online) information systems education with service learning.
One under-addressed experiential learning approach is found in service learning [7]. In contrast to industry-directed projects, service learning is based in community needs and wants. In service learning students work directly with community partners/community to develop and implement a solution. Service learning projects contain several elements interesting for experiential learning. In particular, the content is highly applied and requires the creation of a (minimally viable) solution for and by the completion of the course(semester). Community partners engaged in service learning often (though not always) have lessstrict cooperation requirements, meaning students can take advantage of a full development cycle [7]. Service learning intersects with Agile development methods naturally in its necessity to have strong feedback loops with the community partner/community partner/client [1]. Implementing experiential learning in the classroom poses specific pedagogical challenges. In order to achieve a successful implementation, some portion of lecture time must be allocated to group activities, community partner/client-facing time or requirements discovery. This necessarily takes away from traditional lecturing. In order to convey the needed information to meet learning objectives, a compromise solution must be delivered. This is well-addressed in a blended classroom [11, 13], a time-effective course delivery mechanism which re-focusses in-class time to active learning and homework to learning the materials previously covered in lectures.
KEYWORDS Information systems education; undergraduate instruction; agile software development; service learning; experiential learning.
This article describes an experiential learning scenario employing blended classrooms technology and service-learning elements. The class worked in conjunction with a community partner specializing in ex-patriate elder care. Students were tasked with creating a study aid for seniors to study for the US Citizenship Exam. First the course and team structure are introduced (Sections 2 and 3). As in all group work scenarios, pedagogical methods to support student learning and avoid freeriding [6] were required (Sections 3 and 4). The core of the contribution is found in the Validation (Section 4) and Discussion (Section 5). Section 6 closes with an overview of Limitations and Future Work.
ACM Reference format: Spencer Robinson, and Margeret Hall. 2018. Combining Agile Software Development and Service-learning: A Case Study in Experiential IS Education. In SIGCSE ’18: 49th ACM Technical Symposium on Computer Science Education, Feb. 21–24, 2018, Baltimore, MD, USA. ACM, NY, NY, USA, 6 pages. https://doi.org/10.1145/3159450.3159564
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for components of this work owned by others than ACM must be honored. Abstracting with credit is permitted. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Request permissions from
[email protected]. SIGCSE '18, February 21–24, 2018, Baltimore, MD, USA © 2018 Association for Computing Machinery. ACM ISBN 978-1-4503-5103-4/18/02…$15.00 https://doi.org/10.1145/3159450.3159564
CASE STUDY: APPLIED SERVICE-LEARNING IN IS EDUCATION Course Format and Curriculum ‘Agile Development Methods’ is a required 3-credit course for the Bachelor of Science in IT Innovation programme focussing on third and fourth year students. This is a once-yearly Spring
491
Paper Session: Service Learning
SIGCSE’18, February 21-24, 2018, Baltimore, MD, USA
semester course with regular course meetings twice a week for 1 hr 15 per session. Additional in-person and online meetings are scheduled in-group. The course was taught in English, along with all assignments, evaluations, and course communications. The course was managed as a hybrid blended classroom [13], where assignment and course materials were hosted in the course management system (CMS) and student applied the week’s content in-classroom. In addition to a CMS, the open source platforms Slack and Trello were implemented to assist in project management.
Groupmates were guaranteed to have a minimum of two meetings per week. Project management tools like Slack and Trello were employed to enable transparency and real-time updating between and across teams, and with the professor. Within the broad specifications of the project, students were granted significant autonomy in selection of the implemented study aid mechanism, programming language, and individual role in the project. The goal of the class was to simulate an Agile software development cycle as closely as possible, requiring a higher level of autonomy than a traditional lecture-based course.
Course Content and Intended Learning Outcomes
Student Composition and Competency Profiles
The aim of Agile Development Methods is providing a coursebased environment to learn (i) rapid prototyping (ii) project management and (iii) teamwork skills (see [5, 12] for detailed information on Agile classroom outcomes). Agile courses are applied courses and must mimic an actual Agile scenario closely, lest the students gain incorrect exposure. The blended environment supported this aim particularly well, allowed course time to be allocated to hands-on activities and group planning [11]. The course is the final requirement in the course module before students undertake their final capstone or thesis work in preparation for graduation from the program.
18 students (two females) registered for and completed this course. Registered students are third or fourth year students in the IT Innovation programme. To register for the class all students must have passed or shown equivalency in Java programming (two semesters), C programming (one semester), and Management of Databases (one semester). Approximately half of the class had previous experience with Agile Development through other courses or internships. Of the 18 students in the course during the term under observation, two had migration backgrounds. Both students with migration backgrounds reported assisting family members with studying for the US Citizenship Exam. The exam was unfamiliar to the rest of the course participants.
In the first part of the course students learn the theories and techniques of Agile Development and SCRUM. They are introduced to the organization’s stakeholders, begin needs gathering, and meet with various research and practical topic experts. Students had nine scheduled in-classroom or on-site visits and three subject matter expert discussions in-class. The expert visits were in gerontology, learning science, and a recent successful US Civics exam test-taker.
Three functional teams convened (Table 1): Backend, Admin, and Quiz. Each team had one SCRUM Master, a tester and a combination of developers and User Experience roles. The structure is resultant of the project in place. One Proxy Product Owner (PPO) was also in place to centralize communication between the student groups, the community partner/client, and the professor. This was a double role with the SCRUM Master of the Backend team.
The students then break into functional teams, write software requirements, finally implementing minimally viable software in four, 2-week sprints. The course objectives were written as such:
Students self-selected into roles via ballot submitted to the professor. Fig. 1. displays the employed ballot and potential roles. In all but one case, students were placed into their top or second most preferred role.
At the end of this course students:
Have knowledge of the processes, methods, and tools that are used in agile IT application development approaches. Are able to apply agile methods and processes to small and middle-sized projects software development. Have learned how to determine system requirements and how to create a logical incremental design for an IT application. Are familiar with UML modelling techniques. Are able to utilize SCRUM methods and techniques to support agile project management. Are able to prepare and run project meetings. Are able to actively participate in the team-based analysis and design of an innovative IT application. Have honed teamwork, critical thinking, and communication skills, through active involvement in project teams and cooperative learning groups. Demonstrate the ability to make professional presentations and reports by applying learned knowledge and skills. Demonstrate professionalism, respect for others (both oral and written), and high ethical conduct. The blended classroom enabled spending class time in experiential sessions and was employed throughout the semester. Classroom time was spent clarifying, discussing the methodology and processes, and in group-based work.
Scale: 1 – 10 1 = absolutely not! 10 = Would make my YEAR ___ SCRUM Master ___ Product Owner ___ Developer, Browser ___ Developer, IOS or Android – (circle one) ___ Developer Architecture ___ Tester ___ UI Designer ___ Database Developer ___ Other – please name Figure 1. SCRUM role ballot
492
Paper Session: Service Learning
SIGCSE’18, February 21-24, 2018, Baltimore, MD, USA
Teams submitted a team contract including an agreed-upon definition of “done,” an internal accountability process and conflict management plan, and a communication strategy.
prioritisation, teams can be limited by low output. In consultation with the students, two linked processes to counter the effect were put in place. As the fundamental challenge was one of experience and not capability [4], students were encouraged to employ self-management and refer to the team contract in cases of conflict or differing performance expectations. In order to ensure mutual accountability and continuous evaluation [10], 30% of the students’ participation grade was reallocated to reflect self- and time management.
Table 1. Team Structure Team 1: Admin
Team 2: Backend
Team 3: Quiz
SCRUM
SCRUM/PPO
SCRUM
Development/ Architecture/ Database DDA
DDA
DDA
DDA
DDA
DDA
User eXperience
UX
DDA
UX
T/QA
UX
Tester/Quality Assurance T/QA
-
UX
-
-
T/QA
Big Picture ↔ Individual Skills A foundational principle of Agile development is community partner/client interaction [1]. Particularly the concept of epics and user stories (informal descriptions of software requirements from the perspective of the end user) drives all development in an agile system. Students understandably concentrated on applying their existing skill sets to the project [14]. However, a mismatch between student skills and project requirements occurred on the Quiz Team. The developers on the Quiz Team focussed on implementing the game with the Unity development platform rather than in a standard programming language (i.e., Java), with which they were less competent. The implementation delivered a smooth, game-like experience, which was a community partner/client requirement. However, another community partner/client requirement was deprioritised by this implementation, namely that the implementation be highly functional with low latency. The Unity implementation could not directly interact with the developed Cake PHP database, causing the developers to create a complicated, intensive workaround solution. In addition, the implementation was not functional on several of the work stations in use at the community centre due to the age of the machines.
10-minute standing meetings were a feature of the course. Groups were in near-daily communication, with deadlines and graded materials set to coincide with the end of the week. TRADE-OFFS AND TENSIONS IN TEAM MANAGEMENT
A chief difference in Agile methodologies compared to historical software development methods is its tolerance of and for ambiguity. While this is an attribute in fast-changing development environments, it poses specific pedagogical challenges [14]. In addition, group assignments invite free-riding problems [6]. In this course it resulted in two major trade-off scenarios: Individual vs SCRUM Master Responsibility and Big Picture vs Skill-based Thinking. These two ambiguous aspects caused the first sprint to fail, meaning that no instantiation was produced.
The challenge represented here is less of a pedagogical issue and more of a project management challenge. It however prompted a change in future class projects; students in future courses will receive a briefing on interoperability of technologies before the sprints.
SCRUM Master Responsibility ↔ Personal Responsibility Agile software development classroom environments are unique because of participants’ unfamiliarity with the agile methodology combined with unenforceable management structures along with external distractions. These combined factors can lead to failed sprints and setbacks that stack up and eliminate the possibility for an agile process because of the finite semester schedule.
VALIDATION We were particularly interested in the nexus between student and community partner/client feedback to find evidence for the effectiveness or limitations of this course. The coming section is broadly based on qualitative written and focus-group feedback received as a part of the course. As part of the university’s policy, all courses are subject to a standardized evaluation scheme that students have to complete after or during the last lecture. Due to the scheduled timing of the standardized evaluation form, extensive formal feedback is left for a future extension of the paper. In the following sections we give a short overview of feedback received from the student teams, community partners/clients and the students.
Students initially struggled with breaking down their own project section into smaller tasks, and task structuring as delivered by the team’s SCRUM Master. This is partially due to the structure of traditional classrooms: tasks and outcomes are mandated by the lecturer rather than self-organized or tasked by a peer. With many distributed responsibilities, it can be difficult for students to prioritize (as well as guide groupmates) effectively. Students were bottlenecked by their expectation of hierarchical accountabilities.
Sprint Reviews and Retrospectives Sprints were two week iterations. At the end of each sprint students presented then submitted a team-based sprint review and an individual sprint retrospective. The review established the progress and challenges compared to the sprint plan. This was scored for deviation from the submitted sprint plan and actions taken to remedy any deviations.
This problem caused the greatest detriment to group morale and seemed to be contagious. Agile is theoretically a modular process [12] but undergraduate students inevitably prioritise competing (academic and non-academic) demands [9]. When there is an uneven understanding of the development environment or task
493
Paper Session: Service Learning
SIGCSE’18, February 21-24, 2018, Baltimore, MD, USA
The retrospectives allowed each student to evaluate their group as a whole, their groupmates individually, as well as their own contribution. In addition, two sprints had an in-class conversation based retrospective covering the sprints’ overarching themes, accomplishments, and challenges.
“[…] it is a privilege to be part of such wonderful class, your students are amazing. We are very excited about this project and I am sure the outcomes will be remarkable once everything is done.” (emailed, 2/20/2017) “[We] were both impressed with the progress the students had made and their thoughtful questions to us.” (emailed, 3/20/2017)
Table 2 reflects the scoring of students in roles by all other students. Students awarded ‘points’ to each person on their team from 0-100. Self-assessments are extracted from this matrix. Note that with one SCRUM master and one tester per team there is no cross-scoring possible unless self-assessments are included. SCRUM masters were generally well-regarded across the three teams. Students generally rated their own performance well, with a high of 100 and a low of 75 across 18 students in four, two-week sprints.
“We are so lucky to have you all your students working in this project. I do believe we are the ones who have to be more thankful because you have help us to provide to our seniors an easier way to practice their knowledge to become citizens.” (emailed, 5/19/2017) The strongest positive feedback came from an ad-hoc visit by a group of developers and UX students performing user acceptance testing at the senior centre. Working directly with the senior citizens, students took feedback on the design and performance of the game. Seniors reported:
Table 3. Ratings of performance by role averaged and rounded across sprints and teams
SCRUM Master Developer UX Tester
SCRUM Master 95 91 97
Developer
UX
“[…] feeling heard and empowered because the students wanted to listen to their opinions. They were so happy to have participated in the development process.” (phone call, 3/27/2017)
Tester
87
90
92
97 83 72
91 94 79
89 75 -
A secondary positive result is that one student was offered a part-time IT administrator position for the senior centre. Student Feedback Students submitted a final reflection after project handoff. No student feedback on the blended course delivery mechanism was received. This indicates that such delivery is acceptable, if not commonplace. Overall student satisfaction with the course was high. Many students (40%) also wrote (at length) about the importance of good group work and being a good teammate in a group development scenario.
In-class retrospectives were a vehicle to discuss highs and lows as well as recalibrate classroom and/or project management strategies in a public forum. Several positive outcomes came from these discussions, including the redirected 30% of the participation score, a swarming approach to aid the Quiz Team developers in connecting the game and the database, a change in time for the standing meeting from the beginning of class to the end of class, and a unified deadline for all weekly assignments at the end of the week to better facilitate development and CMS work.
“I learned it is hard to work in a big team, it takes a lot of management to diffuse confusion and remedy apathy because of that confusion. I learned that I am not a manager type, I did not envy the scrum masters during the project duration. That being said I feel like I did gain confidence in my communication skills by being force to do it to finish the project.” (Q1)
Stakeholder Feedback Nine scheduled visits and along with several ad-hoc client visits happened throughout the semester. Two main and two secondary contacts from the senior centre staff were in contact with the student teams. The meetings were held at the senior centre (4x) and in-class (5x). Students were encouraged to use these sessions for requirements gathering, proof of concept validation, and user acceptance. The community partners/clients were likewise encouraged to push back on implementations, question features, and guide future development cycles.
Students overwhelmingly preferred the hands-on aspect of the course (Q2). “I liked the pressure this project brought. Having actual clients, and an actual quiz that needs to be delivered provided a different viewpoint than other classes. It gave more real world experience than simply learning through lectures and papers. I was able to adapt quickly throughout this project, being a tester was the foundation of development, and constantly being prepared to run changes in the game was important.”
Whereas the student groups had significant autonomy in implementing the game section of the artefact, the administrative section received considerable feedback and was re-developed over several iterations. This is due to strict requirements for reporting that are in place from various granting agencies funding the work of the community centre. From a simple interface listing individual students and last scores, the administrator’s page gained group analytics, ability to alter questions and answers, a leader board, player progress scoring by quartile by week and month, as well as individual player progress tracking.
“I like that we were able to work on a real life problem and that there are people that need this product and they will be using it. I also like that we did not waist (sic) our time developing a product that will never see the light or no-one will use it.” It must however be noted that several students wished that there had not been an actual client as it added undue pressure (Q2). This could be a reflection of the added vulnerability of the user population at hand. “I think we should participate in activities without the stress of creating a product for someone who actually needs it.”
The three quotes (from emails between the main contacts at the senior centre and the instructor) below illustrate the relationship between the student groups and the clients:
494
Paper Session: Service Learning
SIGCSE’18, February 21-24, 2018, Baltimore, MD, USA
style submissions) due to its more infrequent meetings times. This level of oversight seems contrary to Agile methods as it requires committed software much more frequently than the sprint allocates. However, this is both fairer for students in the grading process as well as easier for the staff in case of implementation issues. Each timeboxed item should be submitted to the lecturer for evaluation. This need not be graded exercises; but will assist in transparent feedback with individuals and groups [16].
While most enjoyed the team environment (Q6): “I liked that I could work with a group. This is something that I could put on my resume or tell a potential employer about when I apply for a job. I could communicate effectively and ask for help when needed. I completed some tasks within a day and helped speed up development.” fissures were also apparent (Q7). “Sometimes my team would not communicate with me, so I did not know what needed it to be tested, and sometimes when I tested something and it was working, so I would record my results but the developer would make some changes without telling me what changes they made so I could test it one more time, so I had to figure out myself what need it to be test it.”
Best Not Easiest While students understandably want to develop and implement in their most familiar programming languages, full autonomy is not optimal inside of a semester-based course. Students may lack the foresight of interoperability challenges (see Sprint 0), have a limited time scope for implementation, and in contrast to employees in a similar situation, cannot be available at the end of the project (semester). In this case, a client-focussed ‘best’ standard is critical for project success. Even in cases of an individual being able to implement something “better” another way, a spike considering the delta between global best and individual better must be carefully analysed.
Though perfect harmony should not be expected in a (student) group project, so some amount of discord along with the learning process was expected. Issues such as above are more likely indicative of individual dynamics than a broad coursebased issue. DISCUSSION AND RECOMMENDATIONS Reiterating, the goals of this class are (i) rapid prototyping (ii), developing project management as well as (iii) teamwork skills. To this extent several pedagogical tools were employed. Concentrated group work and development time was enabled by the application of blended classrooms. Additional tools and approaches to support a successful outcome included expert guidance, community partner/client visits, and online project management tools. A series of recommendations and proposed and discussed below.
LIMITATIONS AND FUTURE WORK Classroom environments have the greatest chance for students to learn an approach as well as the technology being used to develop. Via service-learning projects, student developers will have already worked in similar environments and have years of experience building systems. This is particularly valuable for future corporate or entrepreneurial endeavours: while the students in this course had passed several programming classes, no classes had undefined goals. In this instance, ambiguity led to hesitation, which quickly led to a failed sprint, putting the entire project behind. In addition, students enjoy working with and for their communities (see Student Feedback).
Implement Sprint 0 A significant amount of stumbling blocks can be avoided by implementing a preparation Sprint (Sprint 0). Sprint 0 contains standard preparation aspects like finalizing requirements and preparing the burn chart, but also gets students ‘used to’ the agile process. Sprint 0 can contain sections like effective standing meeting management, conflict role-play, tech crash courses, communication planning, or best practices like interoperability in software design. Though students may come to class with some knowledge of the Agile process, students reasonably need a standard starting point [2]. The value of a leadership and a communications plan cannot be overstated [3].
For students to truly process the experience of performing agile roles, students are necessarily in the roles of SCRUM master and product owner. These members manage the backlog, assign tasks, and resolve productivity issues. However, students are unable to hold fellow students accountable. If a student SCRUM master finds someone continuously slowing development, their best option for reprimanding the offender is reporting the issue to the instructor so that they receive a lesser grade; This is not ideal as it still puts the accountability and management responsibility into the professor’s hands rather than the SCRUM master’s or product owner’s.
Spread the Accountability With interlocked artefacts, if single items fail, the entire software fails. Even in graded situations [6, 14] established that students are still likely to rely on a small group of dedicated students to implement the project even in the best of systems. An interesting approach from behavioural economics was proposed in the 1970’s [15] to situate the class as a social choice function experiment, but few follow-up works exist to validate the results in a modern classroom.
To fix agile implementation in a classroom environment, a team must be able to first develop a network of trust [8]. Sprint planning and backlog prioritization is addressed as a result of stakeholder meetings, but implementing them requires the full cooperation of all team members. This requires common accountability standards to enforce performance requirements. The most effective way to do this in a classroom environment is to implement the tools necessary to make SCRUM masters the primary reporter to the lecturers. In this way, an inexperienced SCRUM master is not deciding the academic fate of an inexperienced developer, but they are the ones providing insight. With well-enforced deadlines, developers will feel more obligated to finish on time and get through sprints in a timelier manner.
Trust but Validate It has been shown that trust must be present in agile processes [8]. To support trust development students and lecturers should embrace more frequent iteration validation than the standard sprint review process allows for. The classroom-based exercise necessitates more frequent showing of progress (homework-
495
Paper Session: Service Learning
SIGCSE’18, February 21-24, 2018, Baltimore, MD, USA
Future work has several directions. Minor changes in content delivery must be made to more fully support the development process. It is worth considering employing a Teaching Assistant to fill the role of Product Owner in order to maintain student autonomy while keeping a strong validation process in place.
[7]
This course is an ongoing, required course and observed and qualitative classroom data exists in full for +3 years. This will be analysed in full. In future iterations of the course, the data collected will be moved from qualitative to quantitative (which is a current limitation of the approach in place). This will allow for statistical analysis of student outcomes.
[9]
[8]
[10] [11]
REFERENCES [1] [2] [3] [4]
[5] [6]
Beck, K. et al. 2001. The Agile Manifesto. Boehm, B. et al. 2002. Balancing Plan-Driven and Agile Methods in Software Engineering Project Courses. Computer Science Education. 12, 3 (2002), 187–195. Cervone, H.F. 2014. Improving Strategic Planning by Adapting Agile Methods to the Planning Process. Journal of Library Administration. 54, 2 (2014), 155–168. Chen, C.S. 2002. Self - regulated Learning Strategies and Achievement in an Introduction to Information Systems Course. Information Technology, Learning, and Performance Journal. 20, 1 (2002), 11–23. Devedzic, V. and Milenkovic, S.R. 2011. Teaching Agile Software Development: A Case Study. IEEE Transactions on Education. 54, 2 (2011), 273–278. Hall, D. and Buzwell, S. 2013. The problem of free-riding in group projects: Looking beyond social loafing as reason for noncontribution. Active Learning in Higher Education. 14, 1 (2013), 37–49.
[12]
[13]
[14] [15] [16]
496
Hoxmeier, J. and Lenk, M.M. 1999. Service-Learning in Information Systems Courses: Community Projects that Make a Difference. Journal of Information Systems Education. 14, 1 (1999), 91–100. McHugh 2012. Agile Practices: The Impact on Trust in Software Project Teams. IEEE Software. 29, 3, 71. Mehl, M.R. and Pennebaker, J. 2003. The sounds of social life: a psychometric analysis of students’ daily social environments and natural conversations. Journal of personality and social psychology. 84, 4 (2003), 857–870. Moskal, P. et al. 2013. Blended learning: A dangerous idea? Internet and Higher Education. 18, (2013), 15–23. Napier, N.P. et al. 2011. Transitioning to blended learning: Understanding student and faculty perceptions. Journal of Asynchronous Learning Network. 15, 1 (2011), 20–32. Read, A. et al. 2014. Developing entrepreneurial skills in IT courses: The role of agile software development practices in producing successful student initiated products. Proceedings of the Annual Hawaii International Conference on System Sciences. (2014), 201–209. Rutherfoord, R.H. and Rutherfoord, J.K. 2013. Flipping the classroom: is it for you? Proceedings of the 14th annual ACM SIGITE conference on Information technology education (2013), 19–22. Umphress, D.A. et al. 2002. Software process in the classroom: The capstone project experience. IEEE Software. 19, 5 (2002), 78–85. Walker, H.M. et al. 1976. Deviant classroom behavior as a function of combinations of social and token reinforcement and cost contingency. Behavioral Therapy. 7, 1 (1976), 76–88. Wormeli, R. 2006. Accountability: Teaching Through Assessment and Feedback, Not Grading. American Secondary Education. 34, 3 (2006), 14–27.
