Agile and Scrum

Agile is a more flexible process than earlier Waterfall methodologies that were used for projects like building construction, where it was important to pin down all of the details before starting work as changes become much harder as you get further into a project. It’s too late to make changes to lift shaft arrangements once you’ve built the structure of your tower block, for example.

With technology development, particularly software, you don’t necessarily want to pin down everything before you start, and often have too many unknowns to do this effectively. Instead, you need a project management structure that allows you to respond to what you find along the way, to results from user testing, for example. This is what Agile does.

There has been a lot written about Agile out there, as well as the Scrum framework that gives you the tools to run an Agile process, we provide some links at the bottom. We use several of Scrum tools, such as short design sprints, of which there will be several within a project. For more information about design sprints have a look at this page from GV who developed the concept.

Sprints can however be applied to any activity. See below some principles around research activity:

1. Define specific and isolated research questions for each research sprint and design the research to test them in as lean a way as possible.
2. Recruit participants either internally or externally (e.g. healthy people through personal networks).
3. Consider different kinds of participants: whether these are stakeholders (e.g. clients) or lay people will determine how you frame the research.
4. Ask people to use the product for a contained period of time.
5. Walk participants through onboarding (either over the phone or email) in as simple a way as possible.
6. Keep any interviews to maximum 30 mins: these can be conducted at the start (e.g. exploring initial expectations and understandings) and end (e.g. exploring experience).
7. Where face-to-face is not necessary, conduct remote research via email, phone and video calling.
8. Consider channels to enable people to share thoughts in real time.
9. Keep analysis concise; frame insights per feature or interaction to support decision-making within the design and development team.

Key considerations:

1. Cross-check research questions with the design and development team so that each research sprint is aligned with outcomes of the latest design/development sprint and the priorities/requirements for upcoming design/development sprints.
2. Continually coordinate with the design and development team: be plugged in to their workflow and priorities.
3. Share insights through the channels that the design and development team are using (e.g. via Confluence, Slack).

At Ctrl Group we don’t rigidly follow the Scrum process, as we have the experience to know which processes are the best fit for each project. But if you’re starting out you might find it better to follow the processes exactly for your first few projects.

It’s worth familiarising yourself with Agile and Scrum (and other related project management tools), especially if you’re used to working in a different way. It can feel daunting, but with experience you’ll get used to it!

Roles and responsibilities

Part of working as an effective team is making sure that everyone knows what their role entails and what they’re responsible for, as well as what everyone else in the team’s role is.

It’s easy to make assumptions about who’s doing what, and find out too late that each person thought the other was responsible for a key part of the process. Open, regular communication through daily stand ups and messaging or project management tools helps along the way. But you also need to be very clear from the beginning, which will also allow you to identify any potential gaps before you start.

A formal tool or process for this might be using a RASCI (or RACI) matrix, which involves setting out all the tasks involved in a project, and then for each assigning one of the following:

Responsible: Who will do the task
Accountable: This is responsible for overseeing that the task is done, and done correctly.
Support: Who else might help the responsible person do work on the task
Consulted: Who might need to be consulted on the task
Informed: Who needs to be kept in the loop on the task, but has no other role in it.

There is a task on this at the end of this module which includes a template.