Using agile methods to teach programming to 1st-year computer-science undergraduate students
Steffen Zschaler, Kelly Coate, Andrew J. Coles · Research Portal (King's College London) · 2015
Programming is widely acknowledged to be difficult to teach to 1 st -year computer-science undergraduates ( e.g., Williams et al 2013). At King’s College London, we are facing problems also experienced by others: Cohorts of newly starting students (up to 240 in our case) are extremely diverse in terms of prior knowledge and experience of programming (Pedroni et al 2009); Programming is a skill that is best learned through practice, requiring high levels of supervision and feedback, yet the size of new student cohorts is continually increasing while the supervision capacity remains near constant. At King’s, programming has been taught primarily across the first two terms of the first year of study. The provision has been structured in large weekly lectures, followed by lab sessions and small group tutorials. In addition, students were required to complete two large pieces of coursework in the second term, which required them to build a mid-sized piece of software on their own. Overall, the provision has followed a rather conventional format. One key problem of the approach seemed to be that the students did not get to practice programming enough through the year. As a result, some students tended to get lost very early in the year as their self-confidence decreased. Even when we organised a hackathon (a one-day programming competition), many students did not participate because they felt they weren’t “good enough at programming”. In order to address these concerns, we have now radically redesigned the non-lecture elements of the course, in particular in the second term. Two principles guide our changes: Students should engage in as much practical programming as possible during their time at King’s and should produce software in formats that can be used as evidence for employability; Students should benefit from tight feedback cycles for their programming work. In order to achieve this we have almost completely removed any individual programming tasks, replacing them with pair-programming in the labs (inspired by forms of agile software development, where programmers work in pairs rather than individually) and group work for the coursework. Discussions in small group tutorials have been replaced by Coder Dojos, where students collaboratively solve a programming problem: two students pair-program at the lectern computer with the entire class providing suggestions; after a short time, a new set of students takes over the computer. As a result we have been able to substantially increase time-on-task for practical programming. This is partly due to the fact that all programming tasks except for the Coder Dojos are now formally assessed, and the pairing of students also helps and motivates students to overcome the initial block when faced with a new problem, as also reported by Williams et al (2002). We are also seeing evidence of students learning from each other, implying that pair-programming and group work have also helped improve supervision and feedback cycles despite resource limitations. As part of a College-wide Changing Classrooms initiative at King’s, we are in the process of evaluating the impact of these changes, through observations, data on achievement and student feedback. This presentation will report the preliminary findings of this project.