As I blogged about earlier this month, I’m currently working with the OER Research Hub team helping them to evaluate their progress, outputs and future developments.
The project is taking a collaborative research approach which includes practitioners/teachers from a number of different educational sectors and countries as well as the “core” team of researchers based at the OU. Given the global spread of project fellows a key challenge for the project is to ensure that the team are able to share their findings and experiences between themselves effectively and provide the basis and data for the OER Research Evidence Hub.
One of the approaches the team has been experimenting with is taking the premise of agile programming and adapting it to a research project (see Patrick’s post about the first research sprint for a bit more detail).
Now, when I heard about this I was intrigued. Typically educational research “products” don’t really lend themselves to anything particularly agile, particularly some peer reviewed journal outputs. Any research based on actual teaching practice does need more than a few sessions to generate meaningful results. Agile programming tends to have very specific, pre-defined outputs, it’s actually often not the most creative of approaches. Whereas academic research (particularly in the education domain) tends much more open ended. Hypothesis are there more to be broken as well as to be proved, the unexpected is embraced.
Bringing researchers who form part of a globally distributed team together for set periods to focus on certain aspects of research project does make sense. As does having some kind of structure, particularly for focusing “group minds” on potential outputs (products), adaptation of peer programming could be useful for peer review etc. However implementing “proper” agile programming methodology to research is problematic.
But if we stick with the programming analogy and stop thinking in terms of products, and start thinking of research as a service (akin to software as a service) then maybe there is more milage. A key part of SaS approaches are APIs, allowing hooks into all sorts of sites/ services so that they can in effect talk to each other.
I noticed earlier this week a post from Brian Proffitt on readwrite talking about the need for personal APIs to help organise individuals interactions, but what I’m thinking of in this context is quite the reverse. I’m thinking of researchers seeing themselves as APIs. They need to be the hooks providing entry points into their research which create effective, interactive dissemination or more accurately communication (as described in this Is it time to ban the term ‘dissemination? post by Caroline Cassidy).
In any research based on teaching practice as is the case with the OER Research Hub, there is always (imho) a tension between research and practice. Sharing effectively lessoned learned with actual teachers and at the same time producing the empirical data that qualified “proper” research requires is challenging and can actually create a gulf between research and practice. I think Learning Design suffered a bit from this. For example, as a teacher I really want to know quickly and easily what people did with OER, where they found it, how it actually changed things for them in the classroom, the pragmatic stuff, not the “science bit” with all the statistics. I probably don’t have time to read an academic paper. As a researcher I may well be more interested in the quantitive data, and reading a “proper academic paper”. As a funder I really want to know what you’ve done with my money, what difference have you made? I don’t need you to regurgitate in several different ways the original project proposal. Equally in all cases I might be interested in more “lite” reflection such as a descriptive blog post, video interview etc, or a combination of them all.
The key thing therefore is for the researcher to think of themselves more as the interface between their work, the data, the findings, the “what actually happened in the classroom” bits and focus on ways to allow as wide a range of stakeholders to easily “hook” into them so they can use the outputs meaningfully in their own context.
In many ways this is actually the basis of effective digital scholarship in any discipline and of course what many researchers already do. In the context of open collaborative research into OERs and wider open educational practice in particular, I wonder if the research as API analogy could help focus development of sharing research outputs and developing really effective interactions with research data and findings?
The team have already identified a number of key challenges for next year including measuring impact -v- attitudinal data, the validity of comparing diverse contexts as well evidence for critical reflection and its relation to OER so have lots of potential hooks and the project blog is filling up with some really useful reflection and early findings from the research to date.
I’m joining the the team next month for their next sprint so will be getting lots more insights into how a ‘research sprint” actually works, but in the meantime I’d love to hear any views you may have.
Hmm … with my ethnographer’s hat on, I’d say the issues spread out on three dimensions.
The first one is the notion of the Project, which is common to research and IT. A project has a goal, which is to deliver something finished, to a sponsor, in line with the terms you agreed at the outset. But the journey is as important as the destination, and lots of important stuff happens on the journey. There are lots of useful ways to disseminate work in progress.
The second idea is Agility, and the notion of sprints. I don’t agree with you about pre-defined outputs. Where I’ve seen these done well, the approach was to get a group of people to commit to intense, focused effort on a problem with a view to improving the groups understanding and producing some artefacts that were worthwhile, interim steps towards our destination.
Software development has evolved its own rituals and genres for performing Agile development, but the benefits are very similar to the age old practice of researchers corresponding with one another and attending conferences – gettting fresh, intelligent minds to look at your work in progress.
The third notion is the API. In my PhD I made use of Bowker and Star’s notion that an API has an inside and an outside. A lot of effort goes into the rules governing what (or who) is allowed to come inside, but the once you get inside, everything that was allowed in gets treated by the same set of rules.
So for me, the idea of research as a service, and research projects as having APIs, is brilliant, because it’s a novel interpretation of an ages-old social truth about how researchers get research done.
Thanks Gordon, really useful points you raise.
I’d very much say that successful agile development is very strongly dependent on learning that happens over the life of a project. Yes, there is a goal, but there is also a realisation that a solution that satisfies the goal is to be developed (and be revised) in the light of accumulating knowledge about the goal, the problem space, users and their needs, organisational needs, the developing solution….
In this sense I see very strong parallels with (computer science) research I used to do where we had a near-term plan and looser plans for longer-term research; as near-term results accumulated over time, longer term goals game into closer focus and could be refined in the light of current play. In this sense I’d draw strong parallels between agile development and research.
Perhaps more contentiously, I also differ a bit on unsuccessful research, it can be as important to report success as failure, but generally particular research projects fit into a larger scheme, an ongoing research programme that a researcher or group of researchers has. I posit that in such circumstances, successes are valued more than failures; funders certainly like to see successes, and successes help researchers play the next game in the ongoing funding pinball challenge.
But yes, I like the API idea as an analogy , and as you say, with outputs not only for researchers (standing on the shoulders of giants etc) but for other stakeholders. But surely you are only (much hidden in that word) speaking for open results that appear in forms accessible by multiple stakeholders? In an agile view, the multiple stakeholders would be involved in the project from the start and would help shape those outputs. This may be what Gordon is getting at with ‘inside the API’, but I know nothing about Bowker and Star, for us developer types an API is in general nothing that we want to see the inside of.
Thanks Mark, yes I think failure is crucial to report too as is involving multiple stakeholders. In a sense, in the OER Research Hub, I think the fellows and their extended communities of practice are the start of this, as will be the Research Hub itself. However I think in this context the human element is could be more powerful than the data alone.