Agile course design and development: Dam[n]ing the waterfall

In my previous role I was responsible for the development of distance education courses in an institution exploiting Agile project management for its software development work. Note the capital 'A'; this was Agile as a noun, not as an adverb! Before I left, we had several important internal conversations about how Agile methodologies might apply to course design and development across what was a classically industrialised process. At the time we were working within the Scrum methodology, and we had successfully experimented with scrums, t-shirt-sizing and regular stand ups within our existing course development workflows.

 In my current role I've maintained this interest in how Agile might be applied to course design and development. Module design here at the Open University continues to partner academics with TEL, editing, media development and project specialists. The multiple people involved lends things nicely to a team-based Agile approach.

Both Open Polytechnic and the Open University are characterised by Otto Peters's classic concept of industrialisation, featuring a division of labour. A division of labour requires participants of particular specialisations to be effectively coordinated so that their efforts are combined into a course suitable for effective distance learning. Naturally, in an academic environment, such coordination can be complex - as multiple, sometimes conflicting perspectives of those involved clash, combine, and create. Consider this insight from an edited book about the Open University, discussing the role of the academic:

In any task needing division of labour it is important to have a clear delineation of spheres of responsibility... The relationship... is defined as an 'educational partnership'. The academics provide information for students, the [media team] convey it. Suspicion and conflict can sometimes arise... (p.116) 

...the massive division of labour implicit in the Open University creates a number of problems for student and academic alike. The former is surrounded by a plethora of specialized roles, whose respective functions may in the early days be difficult to comprehend. The latter is shorn of many of the functions to which [their] role as an academic in conventional institutions of learning may have accustomed [them]. None the less, role specialization is a concomitant of the division of labour which makes the Open University possible at all (pp.118-119, emphasis added; I'll give the source shortly). 

Note the emphasis I added; it's the division of labour that makes the OU possible. All of my research and experience assures me that, for effective online distance education, this is still the case. Yet, even though these quotes date back to 1974(!), the tensions described in the 'educational partnership' that is course/module development in both Open Polytechnic and the Open University remain. Tensions across course and module teams are perennial, yet working together is a requirement for developing effective distance education courses. Academic subject knowledge, and the core skills of effective development (learning design, editing, media development, peer review), do in the main remain discrete areas of expertise. There is a mutual dependence across academic and development skillsets if a distance student is to succeed.

When I was head of faculty at the OP I had this conversation with the then head of the course development team (paraphrased):

• Me: One issue we have across many faculty is that they feel disempowered in that they're not able to develop 'their' course in 'their' way. 
• Response: My team feel constantly under pressure to accommodate what faculty want. 
• Me: So, my team have a sense that they lack ownership, and yours does, too? 
• Response: My team don't have a sense of ownership, but they still take pride in what they do. 
• Me: Wow. Mutual dis-empowerment. No wonder we're finding this hard! 

This conversation made a big impact on me. When I later became responsible for the Polytechnic's course development team before starting with the OU I worked hard to improve things. I was conscious, though, that the required tension of the division of labour would not go away. We could clarify responsibilities and improve processes, but the ultimate mutual dependence remained - in many cases with the associated suspicion and role conflict still in tow. Don't get me wrong; I'm aware of course and module teams where a wonderful synergy is discovered, as a genuinely learning-centred team exercises the mutual submission, and as rich conversation-as-exploration behaviours have their inevitable effect. But I've also seen behaviour that might be considered myopic, independent, and dismissive of the other's expertise. Course and module development teams work under financial and time constraints, often alongside other pressing responsibilities. It's truly a wicked problem.

Enter Agile. with a capital 'A'. Before exploring Agile further, some reflections on the status quo.

In both Open Polytechnic and the Open University team specialists tend to work in their own physical spaces, surrounded by their own specialised colleagues. A separate role, that of project manager, is responsible for time frames and budget; each member takes responsibility for their own particular piece of the overall outcome. These characteristics lend themselves to a waterfall development approach, which in turn requires careful scheduling and alignment of resources. Subsequently, contributions are planned in terms of interchangeable hours, rather than dedicated people. Adding to the situation, the inevitable pressures on each individual as they work alongside other projects and responsibilities also tends to lead to delays, which the project manager is expected to deal with. Such scheduling and non-dedicated contributing reinforce the requirements of a waterfall approach to project management, and remove any sense of team and mutual support. Critically, this also undermines any real sense of shared responsibility.

So, could Agile solve all of this? I believe it can - provided it's Agile, and not agile.

The DSDM (Dynamic Systems Development Method) seems the most appropriate Agile model for course/ module development, mainly because it treats quality as a variable determined by priority-setting. To be frank, it's difficult for me to discern fully between Scrum and DSDM; the two use very similar concepts and workflows, though what they are called is different. A 'sprint' becomes a 'timebox', a 'Scrum Master' becomes a 'DSDM coach', etc. One of the main differences, though, is DSDM's use of 'MoSCoW' instead of Scrum's 'Product Backlog'. The MoSCoW framework places the emphasis on features, rather than working prototypes and minimum viable product.

DSDM's appropriateness for course or module development rests on various characteristics, drawing here from Carroll and Morris's Agile Project Management. DSDM:

• focuses on project management moreso than software development; 
• recognises that people issues are usually the main ones faced by project teams; 
• acknowledges the 80/20 rule, whereby 20% of the effort gives 80% of the result; 
• allows for changes in priority as a project unfolds; 
• urges that the maintenance, not just the initial development of a solution, be considered. 

Critically, DSDM also emphasises the importance of effective communication throughout the development process. 

As a team-based approach, DSDM has the potential to break the classic assembly line process industrialisation requires. In a future post I'll reflect more on the benefits that might come from a DSDM approach to course/ module development.

Reference: 

Castle, F. (1974). Divide and teach: The new division of labour. In Tunstall, Jeremy (ed.), The Open University Opens. Amherst: University of Massachuasetts Press, pp.115-19.