Pt. 6: General Progression and Feedback (Sprints)

Pt. 6. General Progression and Feedback (Sprints).

This blog post forms a prospective reflection on the creation of digital technologies used in teaching. It is a prospective reflection, in most cases an oxymoron, because the design and creation of the materials is partially complete, but materials have not yet been delivered to students.  

The first few iterations of design have been carried out using a combination of development methodologies, picked and spliced due to the nature of the project itself.  With two analysts assigned to the project (myself and one other) and a single development officer, it was important to structure the first stages of the project using agile methodologies; this allowed for time-boxing that fit around increased workloads during the analysis and design stages.  With limited development time available for actual construction of the materials, it was/is vital that the intitial design be perfect before recording take place.

With both analysts having both delivered, and been on the end of delivery of this particular subject (and material) both have an idea of how the material will be recieved by students this coming semester.  However, no in situ testing can take place before the end of this reflection, so it was important to me to obtain further feedback from students.

To do so i approached several students that i know have recieved tuition recently, ranging from one to three years previous.  During discussion of the current, text-based ststem, all students agreed that material was dry and unimaginative; a particularly rending statement as it was myself that designed a number of the recent additions.  When proposed that some of the materials be replaces with vocal podcasts, students suggested that it would be useful to have this in addition to written transcripts, and that jolification of the materials would be a sensible way to get more involved.  Some, expectidy, enquired about whether it would be a poor attempt at comedy.

A number of the students that were questioned about the concept, were asked to read over this blog (posts 1-5), as part of the discussion.  Several of these students suggested that the blog itself form part of the teaching materials for the module in question.  This was particularly pleasing, as this was, by subterfuge, an idea that i had during the design of the blogs themselves; with the design and blogs following project management conventions itself. 

There has been great fun had designing this project, and i can see a great benefit to delivering materials in this manner.  It will allow student to have uadio description of a seminar task in advance, with, hopefully, more students approaching the materials before the discussion begins.  This is a particular problem that this module has had historically, as the delivery method has been textural, and drab.  

The project has helped me to think about delivery methods for low-level discussion, and has played upon what i see as one of my current strengths, in joining together tasks on multiple topics, in multiple formats.  These have previously been classic Lecture/Lab/Seminar links, with podcasts and blogs being an extension to this.

However i approach further projects with trepidation.  Students in the school of computing already have a range of digital technologies to navigate on the route through their degrees, and i have minor concern on adding new delivery methods to this catalog. Whilst blackboard hosted podcasts may be a suitible way to deliver official materials, the addition of official teaching through blog posts adds another channel students may be required to use, and could cause confusion about where materials are hosted.

Pt. 5: Purchase Goods and Services.

Pt. 5. Purchase Goods and Services.

Our basic requirements have been set out, and basic design initiated. Additionally a contractor has been selected in the way of an associate.

Our next stage is to aquire their services, to which end the associate was contacted, and invited to initial meetings.  Contractor resources were discussed as well as initial ideas for the project, and creative amendments were made.  It should be reiterated at this time that the selected associate specialises in this particular field of study themselves, and is familiar with the material taught on this course; so further input was discussed.

Initially the suggestion was that the analysis and design team script the material themselves, with the associate bought in to the 'organisation' as staff augmentation. However, as the meeting progressed it became clear that a total outsourcing approach would suit the project needs far better.  

In this context it was agreed that our contractor would design and implement (record) the system fully.  Given the initial spec, and creative discussion of the meeting, the associate would generate scripts, modify (after feedback) and record the dialogue.  This would not only ease time pressures on the analysis team, who have other material to generate, but also give a good measure of experience in creating teaching materials to the associate. 

Development approach

As development approaches are themselves part of the core teaching on this course, a simple agile methodology was selected (RAD).  Other agile methodologies that are discussed in the course (rapid prototyping) were deemed to be a bad fit for this project due to the nate of the product.  

Creative Discussion

During the initial contractor briefing the requirement were laid out, and contractor resources were discussed (which impressions were in their repetoire).  The following amendments were made.

The six requirements were split into two catagories, the first, on development of systems, the second on project management.

Development meterials to be created using impressions of Muppets, in a cookie factory scenario.  

1. System type case studies: Four distinct voices for different system types. The Count for Accounting systems etc.  
2. Rich-pictures: The Cookie monster (factory foreman) describing the process within the system.
3. Entity Relationships: Kermit the Frog detailing information passing around the system.
4. Development type case studies: Mixed muppets discussing issues.

Project Management meterials to use popular film characters.

1. Good-plan/Bad-plan: Bad plan script taken from 'Jingle all the way' film using an Arnie impression. Good plan as Golum in the LOTR series. Middle plan as Korg from the Avengers francise.
2. Use-case studies: Full plot of Avengers infinity-war/endgame from Korg's perspective.

Handover to Outsource Contractor

With these requirements in mind, the development details were handed over to the contractor, and fees paid.  The product is still in development at this time.