When you hear the word “agile” is it just a trendy buzzword to you? Do you find it flexible but risky? Too short-sighted and an excuse not to think ahead? Does it conjure up images of sticky notes, cult-like devotion, and taking itself too seriously?
Or are you just bored hearing teams wave the banner of agile as a weapon against “corporateness” only to turn the “process” into the same rigor and rote behavior it claims to be the savior of? (Take a moment to do an eye roll.)
You are not alone. If you’re on an agile team or working towards it as a product owner, user experience (UX) practitioner, or developer you probably suspect “we’re doing it wrong.” (Or possible worse, that you’re doing it 100% right.)
And when you add the relatively new discipline of UX to the inherent complex life sciences domain into an agile team — the result can range from chaotic to confusing to frustrating.
We can also relate. As we started discussing our experiences working to integrate agile and UX in our life sciences companies — it was remarkable how similar our challenges and evolution was in working towards what “really works in the real world.”
So we’d like to share some of what we learned to help you possibly avoid some of the pitfalls and mistakes we made along the way and provide you with perspective on what “doing it right” means to us and many of our teams.
Rethinking the role of agile
It has been said that the first step to recovery is acknowledging there’s a problem, so start by asking yourself this simple question:
“Are we getting the most out of the investment in our team’s time working together every two weeks?”
If the answer is anything but “1000% yes… #agile… kumbaya!” there’s room to improve.
For many of our “real world” teams, common challenges that often made the answer “no” included issues like:
- How do we design and develop at the same time and what is the priority of the items we’re working on?
- Where do we capture and incorporate user, customer, and stakeholder feedback and ideas?
- How do we get stakeholder buy-in without constant disruption?
(sorry, refocus 😉 ) - How do we communicate with the team (often global and distributed) what exactly it is that we’re building?
(Re)defining the backlog
The key to overcoming these issues in agile is the backlog. Like the term “agile”, this concept comes with loaded expectations based on people’s roles and experiences. For many agile technical teams, the backlog is simply a list of increments of work for developers defined by a product owner consisting of defined stories that should provide the maximum value to an organization.
So how do UX people, customers, stakeholders, and users fit into this typically narrow definition? Let’s simply expand our definition and how we communicate and use our backlog. The backlog is now:
- The plan for risk-averse executives
- The roadmap for customers / clients / buyers
- The vision for product marketing / owners
- Our list of planned experiments for scientists and subject matter experts
- What to research / ideate / create for UX teams
- What problems we want to solve for users
- What we’re building for development teams
To make this change simpler, we recommend dividing the effort into two types of work and two agile tracks:
- Discovery: Ideas and items not fully fleshed out, described, designed, documented, estimated or tested to the level the team feels confident moving them in to development. These raw plans and ideas can come from any of the roles we mentioned above but it is the sole responsibility of the product owner to add and prioritize what work gets done when.
- Development: Items the team decides meets their definition of “ready to develop” as they work through Discovery items.
Because agile teams are self organizing the details of how this process exactly works and what specific artifacts are required may vary by team. (Although ideally some consistency helps make it easier for people to work on other teams and teams to coordinate their activity with other teams.)
The type of work we are doing varies in these tracks but the team should not. Any team member can and should be involved in either track where and when appropriate or necessary.
Since the development track process is familiar to most people, we’ll focus on how our teams use the Discovery process.
Designing in cycles
Just like in any agile exercise the goal during the Discovery track is to iterate through increments of work — but instead of releasable software we are producing releasable design artifacts again, that meet the team’s definition of “ready to develop.” That definition often includes standards like estimation, heuristic evaluation and usability testing.
The artifacts can include any set of typical UX deliverables the team agrees provides the “minimal viable documentation” to effectively break down and move into active development.
For example, one feature needing to be designed may be very straightforward and require a simple sketch or wireframe and a user story to describe where another risky or complex set of functionality may require the team to do research, prototyping, testing or technical research spikes, etc to deliver.
In life sciences, we often find multi-persona user journeys or complex multistep domain-specific processes to be some of the more complex to breakdown, design and describe. We find that in these cases, running the cycles in very short increments and iterating rapidly helps accelerate the design process and build enough of a “backlog of designed stories” for a team to “get ahead” of development.
Many teams will also define what success looks like in the Discovery track — typically to be one to two sprints ahead or in some cases a release or milestone ahead. The goal is to avoid “just-in-time” delivery of Discovery artifacts.
The ideal scenario is that design artifacts for an increment is completed at least one sprint ahead of when they will be implemented in the normal development process. Again, it is up to the team to decide what is “Ready to develop.”
In common UX terms, we practice and operationalize “Design Thinking” through this Discovery process. So using this model, let’s describe how our teams work together in this agile Discovery/ Design track.
Building a shared understanding
Though most of what we are describing can work for any agile software team (some term the concept “dual track agile”) this approach is particularly relevant and aligned to concepts in life sciences. We are “experimenting,” creating and validating our “hypotheses,” running “experiments,” and conducting “peer reviews.” We are working together to Build, Measure, and Learn (from Lean UX) how to solve the market, user, and technical challenges of our project.
In short, the goal of this agile Design and Discovery process is to learn together as a team.
As teams and projects grow, additional roles may expand the group of Discovery contributor like Business analysts, Facilitator / Planner, and UX Researcher, and QA team members. The key question to ask when deciding who should be involved and avoid endless debate and slow progress is:
“What are the artifacts that best will help the team achieve the outcome of the sprint and who will be responsible to produce them?”
For example a QA lead should be involved to produce a persona-driven test plan for workflow testing. Or a UX Researcher may help add insight based on recent interviews or added by the product owner when a particularly risky feature that may require user interviews and testing is being proposed.
During the Discovery process, this core group from the team work together through the prioritized list of user stores or ideas identified and prioritized by the product owner using whatever time box is effective. Some teams have workshops and do it all at once, others meet weekly, daily or every few days. Again, it’s agile – so whatever the team decides will be the most productive and yield the best results.
Exercises we’ve found to be particularly effective in the discovery process to help the team continue to get better at “designing together”:
- Service Blueprint,
- Lean UX Canvas,
- Value Matrix,
- Card Sorting,
- Impact mapping,
- Collaborative Journey Mapping,
- Co-Creation Sessions,
- Paper prototyping,
- … and of course good old Usability Testing
Here the UX team is critical in facilitating these sessions and helping guide the team in deciding what exercises might be helpful in a given situation. Create experiences that encourage the team to learn how to learn. And remember the goal is to produce “just enough documentation” that the team what it needs to make progress and remove blockers and obstacles to action.
Science is about ideas, experimentation and invention
Hopefully the concepts we’ve shared here help you see beyond the agile “hype” and help your teams in life science add experimentation and invention to every sprint.
We’ve found refreshing agile with Discovery / Design sprints gets better ideas from more of the team faster and provides a mechanism to get more real users involved in shaping products and solutions. So go create some great experiences with your agile team!
Acknowledgments: We would like to thank our UXLS project members for the healthy discussion and contributions to this article in particular our reviewers Joseph Rossetto and Sven Neumeyer.