• Skip to primary navigation
  • Skip to main content
  • Skip to primary sidebar

Tech For Good Hub

Comic Relief's Tech for Good programme for charities and social enterprises etc

  • Start Here
  • Sign up
  • Blog
  • Funding Programme
  • I’m a Funder
  • About

billy

What was learned at Camp?

May 6, 2017 By billy

Eve from Snook, one of our evaluators, shares her views about the learning from camp. 

Applying the agile methodology (see our last blog post here) to their various projects, the Tech For Good teams arrived at valuable insights, new problems and, in some cases, some healthy confusion. In this post, we outline some of the key learnings from the camp.

Agile ways of working

Most fundamentally, teams used the camp to better visualise their project plans. This was particularly important for teams that would be working remotely and to different schedules, such as WESC’s multidisciplinary team. A Disrupt Disability team member said that the degree of structure he gained through the camp to relay to the wider project team would not have been possible without the exercises. The Shelter team refined what they felt was possible in a four-month timeframe, and built contingency into their plans, as a result of the various planning exercises.

Shifting assumptions

The second key theme in this regard is the identification of new assumptions. This is not surprising, given identifying assumptions is a key tenet of the agile methodology. Some teams struggled to pick assumptions to focus on that they can reasonably close within the 4 months programme.

Team Oxfam saw their core assumption shift: from the assumption that food banks offer little ongoing financial resilience support, to the assumption that services want to build financial-resilience support to the assumption that, given financial resilience is key to food security, food-bank staff should refer users to Quidsin.

Other teams gathered more specific insights, relating to a particular assumption. The Shelter team, for instance, realised they had paid too little attention to testing the assumption that the simple intervention of a digital button would solve the problem. This, in turn, had led to an inability to fully articulate why – or whether – their intervention was needed. Similarly, the Women’s Aid team realised they had not tested the assumption that young women would indeed use their service and the context around it. For their part, one of the assumptions the Alexandra Rose team identified was that their voucher printers could print barcodes. Finally, the Bristol Braille team shifted their focus from the physical design of their Canute e-reader to user need, realising they had failed to test assumptions relating to demand.

From assumptions to prioritising things to test

This points us to the third grouping of lessons: the need for more user research. Bristol Braille and Oxfam both decided they needed further user research, around user demand and user experience before using the QuidsIn card, respectively. The Shelter team went one step further and decided they needed a UX designer and user researcher.

Understanding key problems

The fourth key theme in terms of what the teams learned during the camp was a clearer sense of the key problems and potential obstacles they faced. This arose largely from the journey mapping exercise. The WESC team, for example, identified problems around data permissions as a critical juncture – one with the potential to hinder further checkpoints. Similarly, they identified a key collaborator who had the potential to become a bottleneck.

The teams learned all manner of other lessons – some pronounced, some subtle. The aim of this blogpost has been to outline the key themes and to note the way they followed from the tenets of the agile methodology, outlined in the previous blogpost, that ran throughout the camp.

 

What happened at the Bootcamp?

April 10, 2017 By billy

An essential, early part of Comic Relief and Paul Hamlyn Foundation’s Tech For Good programme is a two-day bootcamp at which all the 10 projects and the support team gather in one place to meet one another, learn and plan. This year, the event was held in Manchester and facilitated by James Boardwell, Emily Webber and Dan Sutch. This blog post gives an overview of what we got up to.

It goes without saying that a key dimension to the camp is the opportunity for the different project teams to meet, swap stories and generally collaborate throughout the sessions. Working as a team is, of course, valuable but working between teams allows people to temporarily break free of any habitual ways of working and thinking – to freshen things up.

Bootcamp Day 1: teams introducing each other

The focus of the Bootcamp included:

  • Prioritised assumptions and risks;
  • Tools for working in an iterative and agile way;
  • Outline initial backlog of work;
  • Agree on way of sharing your progress;
  • Identify research plan to test that work done is meeting the needs of the users.

Fail fast

An introduction Camp session focused on the agile working methodology. This is one of the primary methodologies preferred by startups all over the world. Its central aim is the ability to work, learn and, if necessary, pivot fast as a team. The focus is on refusing to waste valuable time and resources moving in the wrong direction when the team could instead “fail fast” by testing as early as possible. The teams brought with them various degrees of familiarity with agile working. It was pleasing that throughout the session, people from across the teams contributed their experiences and inputs in helping elucidate and explore agile working in different ways.

Teams working together

Don’t assume

A key aspect of agile working is the rapid testing of assumptions and quick iteration based on the results. Identifying core assumptions, to then be tested, was, therefore, the next exercise. Central to identifying core assumptions is the word “why”. Techniques such as the Five Whys – asking “Why?” five times in a row to delve deeper into an answer to a given question – might seem faintly ridiculous, but are invaluable in forcing teams to demonstrate to themselves that they truly understand the reasoning behind their work. Each team was asked to identify one core assumption, and to work out how they could test that assumption as quickly as possible to permit them to continue their projects in confidence. In reality, of course, all of the teams identified more than one assumption to be tested. But beyond the fact that the exercise was designed to be replicated beyond the camp, it also makes sense to begin with the most fundamental assumption – that which most influences the others.

Prototype quickly

One result of identifying assumptions is identifying the need to test. For this, prototyping is often required. Indeed, a key tenet of the agile methodology is the ability to prototype quickly and effectively, even if crudely. Teams, therefore, spent time working out how they could prototype tests to some of the key assumptions. Many of the teams had experience with quick prototyping and knew the value of seemingly low-tech methods, such as paper designs used to replicate app UX layouts.

Team DePaul

Another consequence of delving into assumptions is the necessity to think from a user perspective. Asking why repeatedly – and identifying assumptions more generally – often illuminates the presumption that a person or group of people or users will behave in a certain way. However, to determine this in a reliable way, user research is required. This, in turn, encourages user-centred design – not design based on the untested assumptions of the designer. These were key themes that ran throughout the camp: teams were repeatedly encouraged to approach their assumptions and design from a user perspective. More fundamentally, this meant that teams were encouraged to view the digital tools they are producing as services – not just as back-end efficiency gains.

An essential exercise was journey-mapping. Teams spent a healthy amount of time mapping both their own journey as a team designing a product and the journeys of their users in using the product. This holds a number of benefits. First and foremost, it helps generate a clear map of the project. This, in turn, helps identify problem points: it helps identify bottlenecks, linkages and collaborators who might become “blockers”. Therefore, it helps to identify key tasks and questions around how to negotiate potential obstacles.

Camp discussions

The camp was not all spent putting the teams through their paces. It also featured presentations from previous Comic Relief Tech For Good projects. Umesh Pandya, of Wayfindr, gave an incredibly slick presentation of their work to serve as inspiration, motivation and best practice. He also stayed to take questions from team members on both the programme and social innovation more widely.

Finally, of course, everybody got to hang out. It’s amazing to gather people not only with similar priorities and passions but people at the similar points of exciting projects. Between and after sessions, people could be found discussing ideas and plans enthusiastically and fruitfully, setting the tone for the next four months.

Tech for Good longlist

March 25, 2017 By billy

tech for good-snook photo

In October 2016, Paul Hamlyn Foundation and Comic Relief joined forces to support the best use of tech for good in the UK. We asked applicants to submit a project summary, a two-minute video and infographic.

Here you can find our top 50 applications, of which ten were awarded funding.

We are sharing these to celebrate their ambitions, inspire others, foster collaboration and encourage more funding in this space. The ten projects funded were announced in April 2017. They received up to £50,000 (including access to tech experts, mentoring and support) to deliver a tangible development in their Tech for Good project, over four months.

Explore the applications

Read our applications analysis

Find out more about the funded projects

Download Tech For Good longlist spreadsheet

If the button above doesn’t work, click here to download the spreadsheet.

Primary Sidebar

Use this website responsibly

There’s a ton of useful stuff here. But you gotta know that all views and opinions are those of the Tech for Good programme support team, not Comic Relief and the Paul Hamlyn Foundation.

Privacy policy

Creative Commons License
This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.

  • Blog
  • Funding Programme
  • I’m a Funder
  • About
  • Contact

Copyright © 2021 Comic Relief