In a previous life, I used to teach an object oriented programming unit to university students. I would have been quite happy to continue doing that for the rest of my life, but for various reasons, I had to go and get a “real” job. These days I do a little part time teaching and I’m a student again myself; consequently, I still hang around university teachers quite a bit. Recently, an ex colleague from my teaching days asked me, “How would you teach it now?” His question was from the perspective of my professional and academic interest in Agile and my response was, “Well, I would teach Agile approaches from day one of first year and by third year I would run the unit as an Agile project, of course”. He questioned me a bit further and reminded me about some of the challenges this kind of teaching holds. This got me thinking about how I would teach it now and how I would respond to some of those challenges. A quick literature search reveals that there has been some research on the topic by the CS education community but not as much as I would have expected. So what follows is a combination of some of what I learned as a teacher and some of what I have learned as an IT professional.
One of the key challenges for teachers of first year programming students is managing the range of existing skills amongst the cohort; some students have never written a line of code, whilst some may have already made money by developing and selling Apps. This means you have to be able to hold the interest of the latter, and ignite a spark of interest in the former. You know you will get a high drop-out rate, since previous programming knowledge is not required, some people will quickly find that they would rather drink bleach than learn programming and disappear. For these and other reasons, it’s really hard to do group work at this level, and most introductory courses avoid it; As a result, it’s also hard to develop an approach to lab and assignment work that results in something more than an individual portfolio of unrelated code snippets.
These things matter, even in first year, because the ability to not only work in a team, but to work in a cross skilled, self-organising team, is as fundamental as being able to code for a software engineer and each should receive equal attention as an educational outcome. Graduates who cannot (or do not want to) work as a member of a team are, at best, significantly less employable than those who can, and at worst, a liability to their eventual colleagues and employers. (Moreno, Sanchez-Segura, Medina-Dominguez, & Carvajal, 2012) (Vivian, Falkner, & Falkner, 2013). This means that the task at hand is to find a way to give students an opportunity to develop their practical skills and to experience the synergy that results from great teamwork. Happily, since both object oriented programming (OOP) and Agile are principle driven, there is a ready-made framework which can be put to use.
Borrowing from a very successful approach to teaching OOP principles using tools like BlueJ
and detailed in a 2004 evaluation
; I would choose to introduce Agile principles by example. I would build on each principle week by week, introducing concepts as needed. At first year level I wouldn’t try to teach a particular methodology or approach such as scrum, but would introduce ideas where they were most appropriate. For example; introducing the idea of Personal Kanban
provides a nice introduction to lean principles
and is of real practical value for students struggling to manage an undergraduate workload. Since most early programming tasks are by necessity, discreet examples of a given construct such as iteration, techniques such as user story writing could help students understand what is required of them as well as providing a very natural way in which to break down assigned programming tasks into objects and methods.
Addressing the teamwork issue from the get-go
In my imaginary unit, I would use the concept of pair programming to introduce students to the idea that software development is a team based activity from class one. Given the expected range of skills and experience among the cohort, the first one hour tutorial class presents as an opportunity to gather some experiential data from the students. Using this data, the teaching team would be able pair students for first lab class each pair would comprise one experienced student and one with less experience. At this level, the skills being taught are basic software development concepts, such as the use of variables, selection and iteration, depending on the tool being used, you may also have teach students how to work with an integrated development environment (IDE). Working as a pair, the students should help each other with the weaker student at the keyboard and the stronger student guiding the process. Subsequent theory sessions would then take the form of a mini retrospective on the previous week’s lab class, as well as a joint planning session for the next lab class. The pairs could be switched around so that each student had an opportunity to work with each of their colleagues over the semester. This reflects the practical workplace reality that you don’t get to choose who you work with.
Assessment is another tricky area for the educator; and is usually a key item of interest from the student perspective. At first year level, students are typically assessed against each other in terms of their skill development (or other assessable criteria); consequently they have no reason to be particularly interested in helping others, or contributing to a team effort. This is where educational design meets academic administration, quality frameworks and the need for nice bell curves. Unfortunately, this puts students at odds with Agile values, where it is the competency of the team which is assessed. So whilst it makes sense to try to align the assessment approach with Agile values, this is likely to be a challenge.
One way this can be approached is to ensure that the tutorial work described above forms a hurdle aspect of the overall assessment; the basis of the assessment should be the student’s participation in the process rather than completion of specific exercises. Marks for each tutorial component should be awarded equally to the pair and the overall marks awarded should be a worthwhile amount. The idea that pairs should change each class would go some way towards managing pairs where one student does all the work,
A common pattern for assignment work is for students to be asked to submit two or three individual programming assignments in the form of working tested software. Each assignment should build on the previous one eventually delivering a simple, but complete and working application. Generally, a student who has completed all the activities from the tutorial sessions should have had an opportunity to work with all the concepts required to complete the assignment work. Each delivery component would be marked individually, and be demonstrated to the tutorial group, allowing the practical introduction of the concepts of the sprint and iteration review, which would have been introduced as part of the lecture material.
Another common pattern is to require students to sit a mid-semester test and a final exam. Both the final exam and the mid semester test could be run as a coding dojo. Students could receive a brief prior and would be expected to arrive having designed a solution which they then implement within a time-box. Assessment could take the form of a review of work conducted with the tutor in order to assess student understanding, code output could be assessed via a range of automated tools including test harnesses. This approach to assessing first year programming students is not new and has been shown to work well see this paper
for more information.
This essay is by no means a fully fleshed out unit design, but proposes an approach to introducing Agile concepts to beginning programming students as an integral part of how software development works. This approach could be used to build towards a third year elective in Agile software development using scrum, where tutorial groups form self organising teams and where tutors act as scrum masters with requirements of the unit representing the product owner.