26 Jul Integrating user research in an agile team
Moving from a waterfall to an agile structure is now well accepted. Organisations from private to public sectors are now adopting internal scrum teams to build their new digital service from scratch or to improve and rebuild a service, most of which rely heavily on legacy products.
What is an agile team?
– Flat structure composed of experts
– Bottom up approach
– Teamwork
– Incremental approach
– Fail fast, succeed sooner (learn, build, test)
– Scrum team
– Sprints (2 weeks)
– Customer and user feedback, instead of intuition
– Collaboration
We can see new job roles come up more often, such as; an information architect, a business analyst, developers, scrum masters, delivery managers web op, front end developers as well as, designers.
How it works?
From the beginning
I have been to many agile trainings and it was difficult as a user researcher to realise that there was no room for us in the agile process. User researchers worked at a different pace and were not integrated into the scrum team.
Very often when I land on a new project, I assumed that the team knew exactly what user research was. What our role meant, how we work and most importantly, how important our feedback based on our findings was and that it could make a massive impact to the ‘end’ product.
It is, for this reason, that part of my role and our role as researchers, is to be an “evangelist” every time we start a new project or join a new team. I then organise a presentation for them, to introduce the role and the processes of how user researchers work.
This has several objectives:
– Informing the team about what a user research means
– Describing the methods that we use and to make the team understand the jargon that we use and to translate it to their jargon.
– Explaining that we also work in 2-week sprints like them except that we would work ahead of them.
– Setting expectations of what we’re going to deliver.
– Explaining how long it will take to conduct research, collect, analyse and extract findings.
– Explaining when we should get involved?
– Preparing digestible and meaningful recommendations.
– Proving that we are not just here to tick the box for the next “GDS assessment.”
Generally, UR comes into the team far too late in the process. Ideally, we should work ahead of the team. It’s necessary to work closely with the PO, BA, designer and content designers, as building a digital product or service is a great team effort.
Things have started to change in the industry – user researchers tend to be part of the team and are present at the stand-up (not always possible when we are doing fieldwork, or running lab sessions). We are also present in the Show & Tell elements, even if the calendar does not always allow research findings to be shared with the rest of the team. But, so much must be done to make sure user research is well integrated with the product development team.