CarFinance 247 Scrum and Lean UX working model

Article

Aligning design with Agile dev teams (inc. SAFe)

Design and research work best when they are part of how product decisions are made, not a service brought in after a solution has already been defined.

Across CarFinance 247 and Keyloop, I changed how design worked with Product and Engineering, embedding designers and research into cross-functional teams and integrating UX into Agile delivery.

From design resource to product partner

At CarFinance 247, design initially sat outside the established Product and Engineering process. As I built the team, I embedded designers alongside product managers and engineers rather than treating design as a resource requested when needed.

I partnered closely with engineering leadership to change the way teams worked. Design, Product and Engineering became responsible for identifying the problem, exploring solutions, testing them and learning from what was released.

I introduced Lean UX alongside Scrum so research, prototyping and usability testing could happen continuously rather than becoming separate phases before or after development.

Design became part of deciding what should be built and why, not simply improving solutions after they had already been defined.

CarFinance 247 Scrum and Lean UX working model
Integrating research, design and testing into the Scrum development cycle, as well documented in Lean UX.

Embedding research into the development cycle

Research needed to become part of the product development process too.

Rather than UX research being requested when somebody wanted a design validated, I integrated it into planning and decision-making. Customer evidence, behavioural data and commercial performance became part of the same conversation.

At Keyloop, I grew the design and research function from 3 to 15 and embedded designers into cross-functional teams alongside product managers and engineers.

One of the first designers I hired joined the team responsible for customer setup. Working with UX research, the team uncovered problems in the existing experience, brought those findings directly into Product and Engineering, tested new approaches and changed the roadmap.

UX research was talked about, but unlike market research it happened infrequently, usually when it fitted neatly within prescribed delivery timescales.

I took ownership of changing that. Over time, research became evidence teams used to decide what to build, ultimately teaching teams how to conduct their own research rather than relying solely on the UX team.

Dan presenting UX research findings to a Polish development team
My UX researcher Dan playing findings back to a Polish dev team.

Working with Agile at scale

The same principle applied as the organisations and teams became larger, but how we integrated design and research depended on the Agile model teams were working within.

With Scrum, the relatively short sprint cycle made it easier to integrate design and research into the development process. Research, prototyping and testing could happen continuously within a sprint or across a small number of sprints. The harder part was cultural: getting teams used to design and research helping identify and understand the problem, rather than being brought in after a solution had already been defined.

SAFe created a different challenge. The framework provides space for design thinking, but the longer planning cycles make it harder for design and research to get enough room ahead of delivery. If discovery starts within the same PI as delivery, teams can already be working against commitments made months earlier.

At Keyloop, I used a dual-track approach so research and design could work ahead of delivery and bring customer evidence, prototypes and validated direction into PI Planning. Depending on the work, that could mean looking one or even two PIs ahead.

This did not mean design and research disappearing into a separate discovery process. While working ahead, we continuously played research insights and evolving designs back to Product and Engineering teams working on current delivery. Design and research remained connected to what was being built while also creating enough space to influence what came next.

The operating model gave design and research room to influence future product decisions without separating them from Product and Engineering or from current delivery.

Scaled Agile Framework diagram showing Product, Technology and Design & Research
SAFe's typically overcomplicated diagram.

Better products, faster

The operating model is deliberately simple: Product, Design and Engineering working together around customer evidence and measurable outcomes.

At CarFinance 247, this helped move us from a sales-led digital experience towards one where customer needs and measurable outcomes shaped product decisions.

At Keyloop, design and research moved from a small central capability to a global function embedded within Product and Engineering.

The organisations were different, and their Agile models were different, but the principle was the same:

Embed design and research into Product and Engineering to deliver better products, faster.