Deconstruct to reconstruct: building a research approach for growth

30 Jan 2019 | Written by Al Mathers


When should we change?

Maybe the question is, why do you change? And what do you understand that change to be?

I've been committed to research that leads the way for social good my entire professional life. On the basis of evidence, research can pull apart hierarchical decision making in a way that is hard to ignore.

It's not there as a nice to have, it is a need to know. Credibility, ethics and strategy are all strengthened from the ground up by knowing that the change you're calling for, is rooted in the reality of experience and context. Taking a data-led approach that objectively helps us to demonstrate this is what good research should always strive to do.

Research used to be just the mainstay of academic intuitions, but its move out into the world of practice has seen it evolve. Those who research in practice have a real responsibility to those they're listening to, to understand and reflect back through their work, and ensure it has maximum impact.

This can make practice research incredibly engaging and powerful. It's the reason for someone with the purse strings to sit up and listen. It's a means through which we can spotlight the work of people, organisations and approaches that help individuals, communities and society, day-in, day-out, as well as to ensure that this is celebrated and shared.

But it has its limitations.

Time, budgets, methods and access all play a part. Living through continuing austerity, where people have increasing and competing demands for their attention and resources, practice research needs to work differently and in an agile manner to ensure its viability.

Agile Practice and Agile Research

Agile as an approach came out of the software development field, but has begun to seep into other areas. At Good Things Foundation we have been slowly moving towards working in a more agile manner for the last couple of years.

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:

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.

Stepping back, I think we are beginning to recognise that research for growth requires structural and methodological changes also, and as such:

We look differently as a team.

We're not just the same core set of people we once were. We flex far more. Roles are not rigid. How we describe ourselves in relation to our work, our job descriptions, what we see as our core skills is shifting.

We think differently.

We no longer follow a linear path, constrained by assumptions, and as difficult as it is, open challenge has made us better, more creative, more analytical, more understanding and less precious.

We're faster.

We work together to refine, reshape and improve that which working in isolation we might have been happy to put up with. We've moved from being comfortable with our established approaches, following set methodologies to deliver outcomes for one project purpose alone, and now iterate our methods in live manner to learn more.

These things are helping to challenge us in a positive way, and give us new energy. It is about being agile, but it's more than that we have changed and will continue to do so.