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.
First year
fundamentals;
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
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,
Assignment 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.
Tests and Exams
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.
Conclusion
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.
References
Moreno, A. M., Sanchez-Segura,
M.-I., Medina-Dominguez, F., & Carvajal, L. (2012). Balancing software
engineering education and industrial needs. Journal
of Systems and Software, 85(7), 1607-1620. doi: http://dx.doi.org/10.1016/j.jss.2012.01.060
No comments:
Post a Comment