What happened at the Bootcamp?

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.

Tagged with: