She started her career when the waterfall process dominated product development. In the years since, she’s practiced multiple forms of Agile.
We sat down with Laura to explore the best practices she’s learned along the way.
For more advice and case studies from 10 UX practitioners, download the Definitive Guide to Integrating UX and Agile.
How do you see Agile and UX working together?
Agile was created for engineers, so it originally didn’t address UX – and honestly, that’s kind of fine. We’ve learned to adapt.
The saying is that “Lean helps you build the right thing. Agile helps you build the thing right.”
Lean Startup is about constantly making sure that you’re working on things that customers will use. Agile is about delivering those things to them quickly and efficiently. They’re both about helping you learn quickly and adapt.
I would argue that any kind of user-centered design contributes to all of that, especially the learning. If you use all three of them together it’s easier to build the right thing, and it’s easier to build it the right way, and that is helpful.
But I’m not religious about it, the only thing I don’t love is building things without talking to users.
Could you help walk us through how you’ve seen that Lean/Agile/UCD hybrid process play out successfully in projects?
The Lean Startup process is very much about understanding what you want to build by testing your assumptions with customers. You’ll see that overlaps with UCD methodologies, since customer development is a form of user research. We’ve been observing users in the UX community for many years already, so the two work very nicely together.
On the other hand, Agile is a way of organizing your engineering team to release features faster and deliver customer value more quickly.
I’m a big fan, not just of the Lean and Agile philosophy, but also the related discipline of Extreme Programming which includes things like test-driven development, pair programming, and continuous deployment.
Continuous deployment helps deliver the hybrid process – Lean Startup, Agile, and User Centered Design -because we can be talking to users, observing them, studying their problems, coming up with solutions for them quickly and getting them out in front of users and then measuring the results within a very short period of time
This can be a very Lean Startup, hypothesis-driven process: “If we make this change, we predict it will have this effect. Now let’s test to see if we were right or wrong.” A great advantage, of course, is that we can complete the whole process from hypothesis to validated solution in a matter of hours or days rather than weeks or months.
The key is to always drive your process based on a clear hypothesis. You want to design a small complete thing (not an under-designed thing) as a quick experiment. You can then use Agile processes to break down that complete thing into bite-sized tasks for engineers.
If you involve engineers in the user research, you also gain a greater shared understanding of the problem, which always helps with efficiency. So we come up with our experiment, build it, ship it, measure it, and all of a sudden we’ve gathered meaningful results in a very short period of time. That’s a great cycle to follow, and how I’d combine the different processes.
Now you’ll notice that I didn’t say things like, “Well you always need two-week sprints, and you need a planning meeting, etc”. Daily standups and Scrum are not the point. Those are tactics. They’re not bad! In many cases, they’re incredibly helpful tactics. But they don’t define the process.
The strategy behind Agile is being able to focus on small chunks of work that you can quickly get in front of people to learn if you need to change direction. Continuous integration and continuous deployment help you figure out very quickly if things are broken. You don’t find out 6 months later and then cycle back into the process again.
Agile is not specific tactics. Just like Lean Startup isn’t only A/B testing or customer development and user centered design isn’t just writing things on post it notes or making wireframes. Those are just tools. Occasionally using a hammer doesn’t make you a carpenter.
Know the strategies behind your process and adapt the tactics and tools to your team.
How do you fit user research into an Agile process?
Companies newest to Agile struggle most with fitting user research into the process.
They worry about design teams working ahead of engineering, which is really tough at the very beginning of the Agile transition, because it means that engineers are sitting around waiting for people to finish designing the stuff that they’re supposed to start building. So, people try to dramatically shorten the design process.
You end up with a collection of tiny waterfalls.
Of course, you can’t avoid that altogether. I don’t believe teams need to do everything together. Not everyone needs to do user research together or sit around and create wireframes together. Designers will need to do some work ahead of engineering so that engineers have something to work on. But they don’t need to design everything ahead of time.
Also, don’t think of user research as something that only happens at the beginning of a project. Certain types of user research does tend to happen early – the generative stuff where you’re learning a lot about your prospective customers and their needs often gets frontloaded – but we need to stay in constant contact with users throughout the project and involve everybody on the team in some of the regular research activities.