Releasing a toolkit for agile integration of research and design insights
Context & Contributions
This project was born out of the realization that our organization’s agile practice was not lining up with our research and design philosophy. We wanted to be talking to customers constantly, bringing new research insights back to our teams on a more frequent basis, but more importantly, we wanted a way to bridge the gap between research and design on one hand, and the engineering process on the other.
PROJECT DETAILS
ROLE: LEAD RESEARCHER
PROJECT TYPE: PROCESS & PRACTICE
TEAM MEMBERS: 5
DURATION: 3 MONTHS
The team consisted of our design discipline lead, the product owner discipline lead, two other designers, and myself. My role in this project as the research lead was to determine and influence the ways in which researchers were involved in our proposed process, to help design templates and deliver workshops to teams onboarding to the agile discovery and delivery process, and to help build and create content for the wiki space where the toolkit lives.
Problem & Hypothesis
As a research discipline, one of our tenets was for research to ‘feel fast’ — to be able to deliver actionable insights quickly is core to organizational agility. We had processes in place, but they emphasized spinning up each research project individually as needed, when the time was ‘right’. This resulted in research taking a long time to get to users and back to the teams, largely due to the time it takes to find and recruit customers.
Our hypothesis was that if we inverted the process — pre-scheduling customer contact with every sprint — and simply brought whatever research questions, prototypes, etc. to the customer, we could create a system that was more in tune with the rest of our product development practice. We would be able to speak to more customers, with more frequency, meaning more insights about the most relevant work. Fortunately, we were not forced to reinvent the wheel, as someone within Autodesk, John Schrag, had co-developed a process called ‘dual-track’ agile years before, that did just this. Our job then became to adapt it to our organization and support it with structure, artifacts, and a rollout plan — we called it Agile Discovery & Delivery (D&D).
Methods and Process
When attempting to gather organizational buy-in for a new process, especially one that changes (some) ways in which people work, a careful and structured plan and process is crucial to success. With dual-track agile as our blueprint, we sought to adapt it to how our organization was structured, and asked ourselves what we needed to do in order to have teams feel confident in adopting this new set of methodologies. This essentially boils down to three stages:
- Communication — deliver presentations to teams to help communicate our vision and intent
- Scaffolding — create supporting materials for the different rituals within the process
- Rollout — define a rollout plan for teams to onboard onto the new process
Communication
In order to get buy-in from product teams, we knew we were going to have to make it clear what we were trying to do, and how it would benefit them. We produced a video and slide deck providing a high-level introduction to the process and the toolkit, held Q&A sessions with interested teams, and most importantly, we picked a team to be the pilot and first adopter so we could test and evaluate each step of our rollout plan.
Scaffolding
From the beginning of the project we planned to make a toolkit, not just a process. The tools in this case would live on a wiki, and would be tied towards specific phases in the Agile D&D process. My responsibilities in this area focused on steps where research would be heavily involved — things like defining research questions and associated risks, taking the important questions resulting from that and turning them into hypotheses with measurable criteria for success, and devising instrumentation strategies for ensuring that teams were getting the data they needed to evaluate themselves against the metrics they created.
Rollout
We knew that simply dumping a bunch of information on a wiki was not a recipe for successful adoption, nor did we want to take a lot of precious time away from teams doing their jobs — so instead, we walk them through the entire process using their own backlog of issues and user stories. This keeps things moving forward for them, while introducing the process in a high-touch way that helps ensure understanding and consistency across multiple teams. Because of the high-touch nature of onboarding, we then ask teams who have gone through the process to help onboard 1-3 other teams.
Results
As of writing (June 2021), the process has begun rollout to 5 squads, with plans to onboard the rest of our organization (~600 people), by the end of the year. We’ve been able to present this process at several cross-company meetings, including for the entire Autodesk UX Research organization.
