Sunday, October 6, 2013

Design Based Research and Agile Methodology


I find the parallels between Agile software development methodologies and Design Based Research quite interesting. I come from a software development background, and in a sense Agile methodologies are a formalization of the approaches software developers naturally tend to drift towards in the absence of formal project methodology. The statement in the Agile Manifesto says it well:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

Agile methodologies are designed to be more flexible and responsive than traditional software development methodologies, and have come to the forefront since the early 1990s as one of the best ways to develop software - the software is built iteratively, in close consultation and collaboration with the end user, and without a defined intended outcome (apart from "build the software the user needs") stated at the start - the software evolves as it is built.

Design Based Research also emerged as a major force in educational research in the early 1990s. It is a response to the traditional research approach of hypothesis testing by conducting experiments with as many variables controlled as possible. The real world of education is messy - people act differently in different contexts, and consequently an experimental result found in the lab doesn't necessarily correspond to an outcome in the real world. One of the ideas that absolutely blew my mind when I first started learning about educational research was the Hawthorne Effect - that people behave differently when they are being observed by experimenters. Design Based Research is an approach of testing a learning intervention in a real-world setting (a classroom or course), not just to see what effect it has, but rather to iteratively improve the intervention until it is successfully helping learners learn, but also to develop a local theory about why it helps them learn. 

 I went into my PhD with the idea that I would develop in a reasonably Agile way, and was delighted to discover DBR, and how compatible the two approaches seemed. The following table is from my Thesis Proposal:


What I've found in practice is that both DBR and Agile development are methodologies designed for groups of people. As a PhD student, I'm largely doing my research by myself, so while DBR still makes sense (though gathering and analyzing the large quantities of data involved is a bit overwhelming), Agile seems like overkill.  I'll still write about the parallels between the two approaches in my thesis, and suggest that perhaps Agile methodologies might actually provide some formal structure around the DBR process (which is rather ill-defined and non-prescriptive in the literature as far as I have read), but the extent to which I've been actually able to adopt Agile methodologies and demonstrate their effectiveness is hampered by the fact that there is only one of me, so the need for processes to manage the "team" is limited.

No comments:

Post a Comment