March’s meeting themes were Designing an Agile University Course followed by a test driven development exercise.
Agile University Courses
Trevor Adams, from the Staffordshire University, presented the group with a short talk on the challenges of teaching agile based project planning and software development techniques. He covered the motivations for including content relevant to agile development and the problems faced when trying to incorporate this content in a course that has multiple aims. The conflicting forces that drive the content for university courses are:
- Attracting students – this is why games specific courses have been more prevalent recently and Trevor pointed out that a course purely based on Agile development would be quite a niche choice and may not appeal to the mass of students
- Industry – while companies such as Agile Staffs regulars iWeb and Codeweavers can see the benefit of agile development there are plenty of employers that require different skill sets. Trevor noted that concentrating on one particular area could disadvantage students as their skill sets would be less marketable on graduation.
- Assessment – a university needs to ensure that students are learning new skills and that those that achieve a better understanding are compensated with an appropriate grading structure. Agile development requires a great deal of collaboration with things like pair programming and stand up meetings, so individual assessment can prove tricky. This, in particular, was the aspect that Trevor wished to explore more thoroughly and was the focus of a group work session he organised.
Facilitated by some well prepared worksheets we ended Trevor’s session with group work around the actual planning of a university module. We are invited to design the module through aspects of topic, format and assessment. Having to actually consider this in depth raised some important questions, some of which the people from industry hadn’t thought about. Deciding on an effective assessment technique was the most difficult part of the exercise.
The more favoured topic for each group’s course was TDD with some element of pair programming. This is thematic with the current trend in topics at Agile Staffordshire and seems important to members in terms of continuing the spread of TDD and learning techniques too.
Trevor said that while he saw it as important for the rest of us to see the challenges he faces as a course leader when designing modules with agile content he also wanted to take ideas away from the session. He promised to attempt some of the modules we’d planned and would present feedback at a later session. We look forward to hearing tales his triumph and stories of the new challenges he has faced.
iWeb also posted about this part of the session on their blog: http://www.iweb.co.uk/blog/2011/03/iweb-work-with-staffs-university-to-design-course/
Test Driven Development Exercise
As this was the first classic TDD exercise the group had attempted we started with a video from Corey Haines. Recorded at the Orlando Ruby User’s Group in 2009 this performance kata is designed to last around 15 minutes and be performed over and over again. This notion of deliberate practise is taken from martial arts but is also analogous with how musicians practise using scales. By repeating the same steps over time you can adapt and refine your technique within a simple isolated problem. You can experiment more than with production code as the kata code is discarded at the end of the process so you are free to make mistakes. It also affords the opportunity to try different design decisions.
While the Corey performed the kata in Ruby we were left to choose any language we wished. I saw PHP, C# and JavaScript being attempted and everyone made quite good progress with the problem. One set of pairs were using two laptops to view one set of code being developed, so that they could see how TDD helped the code to evolve. The PHP camp had some problems with the first, basic tests as the typing style of the language meant that the “null” and empty string of the C# most of us were used to couldn’t be used as a default. This mean we could not force the next change by coming up with a test – eventually we opted for the quickest route to green and returned an unexpected string rather than null- this meant the test went red so we could solve the problem, refactor, and get on with the next test.
We were reminded that the test driven cycle is Red – Green – Refactor and I was attempting to walk about enforcing this like the TDD police. Most people took on this pattern well though and I think everyone saw great benefit in how TDD was helping them develop this simple code.
Slides and Additional Content
As always, I prepared a few slides for this session which this time included some additional content. If we’d had time I would have covered some of the outcomes of a similar session I attended at XP Day last year. The motive for that session was to design a whole agile course, including a fourth year for MSc. I summarised the topics discussed for the 1st, 2nd and 3rd years, and those for the MSc extension. There is more information on the XP Day page.
Here are the slides: https://docs.google.com/present/view?id=dg7kxgdk_156c5bgg6hq
