Photo by Rawan Yasser on Unsplash
Nightingale's CRO, Michael Brown talks about what he’s learned from his extensive experience of working as a researcher on Agile teams.
If you are a junior design researcher looking for your first role or a seasoned full stack developer, the chances are ‘experience working in an Agile team’ will come up when you’re looking for your next gig. Having worked as a researcher in a few very different Agile teams I’ve found that the marriage between Agile and truly user centred design isn’t always a harmonious one. Here are some of my thoughts on important things to consider when the two worlds collide.
A T-shaped design researcher doesn’t mean they are a designer, or a business analyst.
Common to most Agile teams is the notion of T-shaped team member, i.e. people who are really good at one thing but still competent at many others. The importance of T-shaped team members is that they give the team both resilience and the flexibility to focus many team members on a particular problem. The danger is that those in charge of forming and developing the team can overlook the need for specialists in important team roles, in the hope that other team members can make up for the missing skills. For example: “we don’t really need a designer, since our researcher is T shaped and has done some design work before”. Not only does this attitude compromise the resilience and flexibility advantages of building a team of T-shaped people, it is also likely to reduce the quality of the deliverables as members are forced to take on dual roles and spend most of their time working outside their area of expertise.
Everyone should be involved in discovery.
Common understanding and transparency are important Agile values, but they often get overlooked during discovery or pre-development work. I’ve seen many organisations form specialist discovery teams around non-technical staff (researchers, designers and business analysts) and then add developers to the team later, or worse, hand the project over to an entirely different team. These approaches mean that some or all members of the team miss out on understanding the how and why of user needs/requirements that they are asked to deliver on. In the Agile world of keeping documentation to a minimum, team knowledge is vital for ensuring delivery is truly focused on the needs of users.
Continuous delivery means cut-throat prioritisation of design research goals.
While product owners and developers often love to see product releases going out at break neck speeds, it puts a lot of pressure on researchers (and QAs) to perform research, analyse it and feed it back to the team very quickly. This pressure means you rarely have the time to work with large groups of users for a given interaction or to indulge in broad-focus research activities. You need to have confidence in the experience of the design researcher to focus studies on very specific questions and get them answered sufficiently to feed the development cycle. Understandably, this can be intimidating for junior researchers who will need oversight from an experienced mentor to help them focus on the most important questions that will actually influence development. Agile means you don’t have time to collect ‘vanity data’ to show management how great the project is; if a piece of research isn’t going to affect the design and development decisions, why are you doing it?
Like all roles in a team it’s important that researchers understand how Agile working changes the priorities and goals of delivering with your team. Nightingale can help with the formation of truly research-driven Agile teams or embedding research in existing teams. Get in touch to find out more.
