Supporting Non-Tech Teams with Agile
The Supporter Insight and Testing team are a “micro hub” embedded in the Communities department. This means we’re a small team delivering technology services in a non-tech environment. The idea is that by embedding digital specialists outside of the main Technology team, we are better able to identify opportunities and user needs within Communities and provide support directly.
We also have a ‘dotted line’ relationship with some Technology teams such as UX (we have our own User Experience Designer) which has helped to create and strengthen links between Communities and Technology. We’re the first micro hub, so we are still figuring out what that can look like, but you can read more about the Technology strategy here.
We support people at Cancer Research UK to put supporters’ needs at the heart of their work, act on evidence, and deliver long-term change rather than short-term fixes.
Our work is influenced by a series of principles taken from digital transformation, lean, and agile.
These are commonly used principles in the world of Digital and Technology teams, but are less well-known beyond that. This can create unexpected challenges when working with those teams. This is what we’ve learned about working in agile with them.
1. Plan the first meeting on their terms
In the Fundraising and Marketing (including Trading) team, 89% of staff work regionally, so we always aim to introduce digital tools for working in a remote-friendly way as soon as possible. We’ve seen that remote sessions can be quicker and more efficient for getting things delivered. For example, we find that average workshop run times are shorter when running remotely, and we are able to get meetings booked in and completed much more quickly because we do not need to rely on people being in one place (for example, Angel), and it is easier to avoid distractions when calling in and all focusing on a single board (we use Mural and RealtimeBoard at the moment). It also encourages teams to flex their digital skills.
A lot of people are more comfortable working face-to-face, so we sometimes kick off new projects in person, and then shift to remote working once trust is established.
Whatever approach teams prefer, it’s worth taking the time to show people that you’re there to listen to them and learn about their world, so you can support them to find a way to implement agile that really makes their lives easier.
2. Get time booked in with the team quickly
A big blocker we faced was creating and maintaining momentum with teams with a lot of conflicting priorities; teams rarely feel comfortable pushing new ways of working forward by themselves. This led to difficulty getting time in people’s diaries, and then too much time between meetings.
We now book all meetings in at the beginning of each sprint to keep everyone on track, and always support someone else in the team to take on this role as soon as possible.
3. Get feedback early and often
Getting feedback is fairly obvious but also an area we’re always tweaking and adding to because it’s so important. In a recent project, we asked the team to write down their expectations of us and the work in a team charter workshop. We did this very early on to make sure we were addressing them in all future work.
The idea is that the team are your users and you’re giving them the power to influence and direct the work. With another team, we used their feedback to modify our experiment planning workshop template to account for more simple pieces of work. The new template has 3 options based on the level of risk.
4. Help teams to refocus on user needs early
Our experience shows that often when teams are trying to identify user needs, they’re actually thinking of business needs and a little digging brings this to light. This was particularly clear with one team we worked with who identified user needs of wanting to collaborate and share ideas. With a bit of further discussion, it became clear that this was something the project team needed, and we were making a leap in assuming that this would meet the true user needs of practical and emotional support in their work.
Focusing on this area early is a way to model good behaviour (by prioritising users) and also creates a shared understanding and re-centres the team’s thinking, setting the tone for the next stages.
5. Give people enough information to start running
We’ve found that people can feel a lack of direction with the agile approach and feel overwhelming or disconnected, which stops them from feeling ownership and being proactive with work. We started very lean and tested a purely facilitation role and found that this was not enough for teams new to the concepts. We were collecting information and planning work through workshops where we knew the context and aims but the teams did not. To address this, we wanted to add in some processes and documents that would help to join up the thinking between workshops, and help the team to check in with the project more regularly.
So far, we’ve had the most success with booking in sprint cycles and recommend doing this quickly. For example, a team we are currently working with felt like work was stalling until we began twice weekly stand ups. There was no change in the amount or type of work planned but seeing it in this format and catching up with the team regularly created a sense of progress for the team. We have also created a roadmap to give a more visual representation of their progress
We started supporting teams in this way 8 months ago and it’s been a great opportunity to learn about doing things in a slightly different way. These are the top 5 things we have learned and it ultimately boils down to working collaboratively with clear, transparent communication and mutual respect, and always prioritising learning and continuous improvement.
Being embedded within a non-tech team means we have been able to meet people where they are, understand their needs from their own perspective and upskill teams so they are able to continue the work independently. We hope that the work we’ve done so far has helped to break down some barriers and empowered the teams we’ve supported to make agile work for them.
