As a charity focused on supporting the most digitally and socially excluded in society, this is quite complicated. It means thinking differently at a number of levels, about how we work with our network of community partners (Online Centres), how we can best support the work they do, but also taking a good look at how we do things internally at Good Things Foundation.
Bringing together a great and experienced in house team of Service Designers is helping us do this, and we realise what a luxury this is. Other teams at Good Things Foundation, such as our Digital Team, have also been a step ahead in embedding an agile approach to their product and platform development (when working with Learn My Way and English My Way for example).
However as a research team it has felt that we have only really dipped our toes in agile, and that's been in the form of the easy stuff, adopting behaviours that complement rather than challenge our existing practice. In part, this comes down to a perception of the core values of research - rigour and methodology, interrogating assumptions from every angle possible to get as close to the (or a) truth as possible - and that these are not won fast or easily .
It might seem that the fast and light touch approach of agile contradicts these attributes, yet seeing the translation of the 12 principles of Agile Software Development into Agile Research Principles by InfoQ, some immediate tensions and concerns are dispelled:
|Agile Research Principle
||Agile Software Development Principle
|When research is the "product", the "customer" is either a) the editor of the peer-reviewed journal you submit your paper to (representing the journal readership) or b) the committee examining your thesis. Your advisor should act as the perfect proxy for these customers. Prior publications of partial and intermediate results will increase probability of success.
||Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
|Organize your work around the draft of the final product paper, research proposal or thesis. Achieve an "almost publishable" product every couple of months, more or less, even when there are not enough "features" to actually submit the draft.
||Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
|Welcome critique from your advisors, reviewers and peers. Welcome changes in the research direction even when the deadline looms closer–they may improve the final product.
||Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
|Update your advisors very frequently, seek valuable advice, and don't be afraid of looking foolish (you don't) or unprofessional.
||Business people and developers must work together daily throughout the project.
|A researcher is inherently motivated. Research assistants may not be so eager. Assign them valuable and exciting research tasks, give them the environment and support they need, and trust them to get the job done. If you perform your research alone, motivate yourself by alternating exciting tasks with routine ones, and don't overstretch the boring periods.
||Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
|Meet with your advisors, peers and assistants face to face. Meetings are better than the phone; the phone is better than e-mail, Google docs or Dropbox.
||The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
|Evolving drafts are the primary measure of progress.
||Working software is the primary measure of progress.
|Try to maintain a constant pace – don't procrastinate or rush. Create some kind of Kanban-like system that will help you keep work-in-progress at a manageable level. Finish tasks; don't let them linger and weigh on your conscience.
||Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
|Writing style is not a luxury. The ability to write clearly and organize your research workplace and notes enhances the quality and the agility of the research/
||Continuous attention to technical excellence and good design enhances agility.
|Focus on your research goal and research questions.
||Simplicity–the art of maximizing the amount of work not done–is essential.
|Discuss the methodology and results with your peers and colleagues frequently.
||The best architectures, requirements, and designs emerge from self-organizing teams.
|Learn to reflect. Write yours reflection down in your journal. Discuss your insights with your advisors and peers. Your self-improvement as a researcher is no less important than the progress of your research.
||At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
Laid down in this way, agile research feels quite comfortable and familiar. A point echoed by Ron Sellers Green Book blog which encourages us to re-examine our own research practice and recognise the agile elements that already exist.
However, the principles of agile research are just a start. They still speak more to a world of academic or market research, than the world practice researchers, like our team at Good Things Foundation, find themselves in.
Further translation and evolution was needed, to take the best of agile working and blend this with innovative practice research and evaluation methodologies. Overall the last year, our team has made that shift.
A shift that underpins research for growth.
Research for growth
We are now a global charity (working not only in the UK but also Australia and Kenya), and as such we need to be flexible and accountable to a degree many of us have not had to think about before. We have partners who work on an international level and expect us to be able to deliver to this standard. And we have a responsibility to the three million lives we have said we will change for the better through digital by 2020.
Blending agile research with a socially responsible (and people focused) approach has taught me lot, and not always been straightforward. But we are now working differently, unconsciously. This is manifest in our day to day practice where we:
- Think bite-sized: breaking large tasks into discrete pieces that gives everyone a chance to lead and to everyone else a chance to input before the research product or even methodology is too hard wired to be challenged.
- Recognise the importance of humility: skills and experience are great but fresh and external viewpoints help us to improve and challenge the safe world we've built for ourselves.
- Are reflective: without this we don't know what we've missed and how to do it more effectively and in as lean a manner as possible.
- Draft and draft and draft: to work through all the stages, from the sketched outline, through layers of tracery to something that begins from angles to feel solid.
- See the fork in the road and take it: being brave and speaking to partners and colleagues when something isn't working, calling it out then and there. Rather than parking it as a could have done, could have been better, might do next time.