Reading Adrienne Clarkson’s essay on the ‘Why language matters…’ (Globe and Mail, Sept 15, 2018), reminded of one of the problems I’ve consistently had with the language of Agile as it makes it way into software development in higher education.
Agile is important development for eduction; it can bring great benefit. It codifies and defines ways of thinking and development methodologies that make the planned changes transparent and open. However, I think we need to be careful bringing ‘strict’ agile into education, and one of the reasons is language.
Ms. Clarkson illustrates the problem with ‘Referring to doctors’ patients as “clients” puts a whole new meaning on the relationship between the healer and the to-be-healed’.
I would argue a similar problem exists in Agile development in education, which uses the term ‘Product Owners’ and considers students as ‘Stakeholders’. Again, language is important.
Typically IT departments in higher ed are concerned with delivering ‘services’ to students: lists of potential courses, registering for courses, viewing a timetable, accessing course resources (typically through a Learning Management System), taking a quiz, submitting an assignment, and eventually getting grades and a transcript.
The focus here is ‘service’. This delivery of services can be comprised of many products, some off the shelf and some developed. Agile is useful in the development of in-house products (or applications) that are considered part of the overall services offered.
It’s especially important in situations, where the services provided to students are primarily from one in-house developed application, that the ‘service’ and ‘product’ do not get blurred.
Indeed, one way to look at the delivery of services to students, is that there is a ‘Service Owner’ who is responsible for products/applications that students interact with. This could include: login requirements, email accounts, supported laptop policies, how students get their content, implementing policies in content delivery etc. In this scenario, an in-house application’s ‘Product Owner’ works closely with, and provides a product to, the Service Owner who is ultimately responsible for the students’ (and other stakeholders) experience.
Some language has already started to be re-defined for education. There is a robust education definition of ‘stakeholder’. However, I’m not sure Agile deployment in education is recognizing this definition yet.
The ‘Product Owner’ term is much more problematic. There is no ‘product’ to sell. There is no place or website that customers can go to buy the product. There is no relationship between the number of products sold and the employment status of the managers, employees, and developers involved in the creation of the product.
The success of a product in education is much more nebulous. It can be gleaned from student survey results, usage statistics, and relationships with the stakeholders. The employment status of the administrators and developers is also much more nebulous and slow-moving, but it still tied to performance, user perception, and usage.
The introduction of Agile development to eduction is still relatively new. It has great promise, and with a little bit of adjustment can be a great benefit to increasing the level of service delivered by administration to students and employees, all of them as education stakeholders.