Team Agile Methods Case Study
3.5 Implementation notes
This section describes two different implementations of the scenario described above.
A number of factors were identical in each case:-
Teaching and learning
Class level: SCQF level 9, ie Junior Honours
Class size: less than 35
Lab tutor: 1 with work experience of agile methods in industry
Topic duration: 2 weeks
Lab content: 2 labs (JUnit and continuous integration)
Assessment
Duration: 2 weeks
Student effort: 20 hours each
Group size: pairs
Group organisation: self-selection
Differences between the first (2004-5) and the second (2005-6) implementations
related to the number and content of lectures, the assessment topic and marking
criteria. As an extension to the agile experience, for example, scrum Error!
Reference source not found.[11] was introduced in 2005-6. A summary of the key
points from these sessions is given next.
3.5.1 Notes from 2004-5 session
Teaching and learning
Lecture content: 4 lectures (Test driven development, JUnit, mocks and stubs, and
extreme programming) and 2 hours of personal study.
Assessment
Topic: DVD rental system (see appendix 1)
Assessment: criteria provided (see appendix 1) featuring process not product
Marking: detailed marking scheme created by tutors only, and available to
tutors only; summary mark sheet available to students
Timetable of events
1. Introduction to agile methods, test driven development, and JUnit via lectures,
followed by JUnit lab.
2. Further work on test-driven development via lectures.
3. Continuous integration server launched, with 2 and then 5-minute build intervals.
4. Introduction to continuous integration via lab and private study.
5. Assignment issued, with broad marking criteria, and explanation of process
targets rather than product targets.
6. Students invited to organise pairs for assignment.
7. Created a source code repository account and project for each pair.
8. Created a source code repository account for CruiseControl and Ant to have
read access to each pair’s project.
9. Build scripts finalised to send results emails to tutors and students
10. Students given 6 hours of timetabled time to work upon assignment.
Acknowledgements:
1 Microsoft & HEA-ICS
Team Agile Methods Case Study
11. Students invited to spend up to 20 hours working upon assignment.
12. Continuous integration server and then the configuration management server
were closed down at 17.00 at the end of the assignment.
13. Student performance assessed (see appendix 2)
14. Mark results were issued (see appendix 3)
Feedback
Feedback was obtained via anonymous questionnaires and a group feedback session
at the end of the semester. In summary, students judged that “The module was
delivered well. The first piece of coursework was quite hard but very clear.”
Reflection
1. Students enjoyed the experience and welcomed the practical skills obtained.
2. Tutors were disappointed with students’ understanding of refactoring, their use
of mock objects, and their ability to reflect upon their learning.
3. Waiting 5 minute intervals for builds frustrated students, but they were not
making good use of local unit testing. Students needed to be reminded to create
their tests and code and getting tests to pass on the laboratory PC first, before
checking these into the source code repository.
4. A number of the failed builds experienced by students were the result of some
sort of dependency upon another file or a library on a laboratory PC that hadn’t
been checked into the configuration management server. Students should be
advised to check classes in before other classes that use them.
5. The project topic was not sufficiently demanding.
6. Students wanted to focus upon GUI aspects despite warnings not to.
7. Exhaustive marking of every version of every file was impossible: sampling was
necessary.
8. Pair programming was popular except where a pair of students was quite mis-
matched in terms of ability.
3.5.2 Notes from 2005-6 session
Teaching and learning
Lecture content: 6 lectures (Agile methods, Scrum, Test driven development,
Continuous Integration, refactoring, mocks and stubs)
Assessment
Topic: e-commerce for horticulture company (see appendix 4)
Assessment: criteria decided in negotiation with class (see appendix 5) featuring
process not product
Marking: detailed marking scheme agreed by all and used for mark sheet
Timetable of events
1. Introduction to agile methods, scrum, and test driven development via lectures,
followed by JUnit lab.
2. Introduction to continuous integration and refactoring via lectures.
3. Continuous integration server launched, with 30 minute intervals for builds.
4. Continuous integration lab.
Acknowledgements:
2 Microsoft & HEA-ICS
Team Agile Methods Case Study
5. Assignment issued, with explanation of process targets rather than product
targets.
6. Assignment marking scheme discussed and criteria agreed by class, in class
time, facilitated by lecturer (see next section”
7. Students advised to partner with someone at a similar ability level to themselves,
and invited to organise pairs for assignment.
8. Created a source code repository account and project for each pair
9. Created a source code repository account for CruiseControl and Ant to have
read access to each pair’s project.
10. Build scripts finalised to send results emails to tutors and students
11. Students given 4 hours of timetabled time to work upon assignment.
12. Students invited to spend up to 20 hours working upon assignment.
13. Final 2 days of assignment: students request for more frequent builds - interval
changed to 15 minutes.
14. Continuous integration server and then the configuration management server
were closed down at 17.00 at the end of week 2.
15. Student performance assessed
16. Mark results issued (see appendix 3)
Student-derived marking scheme
Identification of the assessment measures was a class undertaking via a “negotiation”
class before the assignment formally began. Discussion led to the identification of
products and processes to be rewarded with marks. Consensus was a collective
responsibility. Once agreed, the marking scheme could not be altered without
majority approval. As an example, students had to agree the relative importance of
(a) obtaining skill with the tool compared to (b) comprehending its contribution to the
discipline.
Feedback
Feedback was obtained via anonymous questionnaires, a group feedback session, and
a number of individual interviews at the end of the semester. Students’ judgements
were positive, for instance:
“great as we have learnt practical skills that we can apply immediately”
“course structured well with assignment work reinforcing materials covered in
lectures”
“the whole experience was a good one”
“The first assignment was very good. Using the Blackboard portfolio feature was very
good as it recorded when students made their notes as part of their ongoing work,
therefore, it was felt, preventing students from just coming up with their entire log at
the last minute the day before it was required.”
Students also appreciated having ownership of the marking scheme. They valued the
experience of judging the importance of different components such as participation,
performance, understanding and reflection. A sample of students interviewed said
Acknowledgements:
3 Microsoft & HEA-ICS
Team Agile Methods Case Study
they believed it contributed both to the success of their learning and to their
motivation. The scrum approach was adopted by one team in a subsequent project,
and attributed by them as one reason for receiving the top mark of the class.
Reflection
1. - as before with regard to students’ enjoyment and tutors’ marking effort.
2. Tutors remained disappointed with students’ use of mock objects, and their
ability to reflect upon their learning, but were pleased with their improved
understanding of other agile processes.
3. The initial and final build intervals were appropriate to the stage of the project.
4. The project topic was not very motivating and still insufficiently challenging.
5. Students’ involvement in agreeing the marking scheme led to their consideration
of (i) quality criteria, (ii) component relevance, and (iii) learning priorities
before the assignment formally begins, rather than wistfully afterwards when it
is too late to be influential.
6. Pair programming was successful and popular.
7. Scrum was successful and popular.
8. Students would have preferred a larger size of team, for example with 3 pairs
working on different user stories and having to integrate their implementations
at team level.
9. Fairness is felt to be very important: giving pairs a choice of user stories to
implement resulted in disappointment for some pairs “we were not to know that
some would have enabled greater use of certain practices and therefore receive
higher marks”.
Acknowledgements:
4 Microsoft & HEA-ICS